Tim, Please see some comments inline below. Regards, Sasha
Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: spring <[email protected]> On Behalf Of Yu Tianpeng Sent: Wednesday, November 14, 2018 10:06 AM To: [email protected] Subject: [spring] draft-ietf-spring-segment-routing-policy Dear authors, I have read the document and have 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. [[Sasha]] I do not see why this is necessary. To the best of my understanding, color values are used for selection of policies that resolve BGP NH of routes that carry color of their destinations in Extended Color Communities attached to them. Such usage is controlled by a suitable BGP policy as explained in Section 8.4 of the draft: Let us assume that headend H: o learns a BGP route R/r via next-hop N, extended-color community C and VPN label V. o has a valid SR Policy P to (color = C, endpoint = N) of Segment- List <S1, S2, S3> and BSID B. o has a BGP policy which matches on the extended-color community C and allows its usage as SLA steering information. If all these conditions are met, H installs R/r in RIB/FIB with next- hop = SR Policy P of BSID B instead of via N. From my POV, there is nothing in the draft that makes any color value special in any way. Or we can say if the color is not specified, we should use 0x00000000 as default one. [[Sasha]] How can color be not specified? It must be specified for a policy (if your management system uses some default value, this is a local matter). Or do you mean that a BGP route with no Extended Color Communities attached should be treated as if its color is 0? Also, I suggest we mention the higher value is, the higher SLA it indicates. [[Sasha]] I am not sure you can really compare different SLAs as being higher or lower. 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. [[Sasha]] A Segment-List is a list of segments. And reserved labels cannot be used as Segment IDs – this is explicitly specified in the SR-MPLS draft<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-15>. 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 ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
