+spring On Wed, Nov 14, 2018 at 1:58 AM Yu Tianpeng <[email protected]> wrote:
> Dear authors, > I have read the document and some comments as below, hope will help. > > 2.1 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.1>. > Identification of an SR Policy > > [Tim]: I suggest we define a default color value 0x00000000 as “default > behavior” or “best effort”. This value will help further interoperability > between vendors. The other values are left user-defined. > > Or we can say if the color is not specified, we should use 0x00000000 as > default one. Also, I suggest we mention the higher value is, the higher SLA > it indicates. > > > > 2.12 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.12>. > Priority of an SR Policy > > [Tim]: Suggest to change the title to Re-compute priority to avoid > confusing with preference defined previously. > > > > 2.13 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.13>. > Summary > > [Tim]: Priority defined in 2.12 is not listed in the example. > > > > In addition, a Segment-List MAY be declared invalid when: > > [Tim]: Another case is: Its last label is not explicit-null neither. If I > understand correctly, the logic of the two criteria is “AND” instead of > “OR” right? I suggest we mention the logic here. > > > > 2.9 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-2.9>. > Active Candidate Path > > [Tim] [I-D.filsfils-spring-sr-policy-considerations] The reference link of > this part does not work. > > > > 6.2.1 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2.1>. > Frequent use-case: unspecified BSID > > [Tim]: Suggest we change the title to “SR Policy specified BSID” > > The BSID of all candidate paths are empty in such case, I don’t think we > should use the word “unspecified BSID” which looks like a reserved BSID. > > > > > > 6.2.3 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2.3>. > Specified-BSID-only > > [Tim]: An implementation MAY support the configuration of the > Specified-BSID-only restrictive behavior on the headend for all SR Policies > or individual SR Policies. > > It should be as below right? > > An implementation MAY support the configuration of the Specified-BSID-only > restrictive behavior on the headend for all SR candidate paths or > individual SR candidate paths. > > > > > > 8.6 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-8.6>. > Per-Flow Steering > > [Tim]: I have concerns that BSID is programmed into the forwarding plane > as in “6.2 > <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02#section-6.2>. > BSID of an SR Policy” it is mentioned that “the BSID SHOULD NOT be used as > an identification of an SR Policy.” > > I suppose we at least mention if we use per-flow steering, we should not > use Specified-BSID-only which lead to inpersistent BSID. > > Thanks. > Regards, > Tim >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
