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
