On Wed, Nov 14, 2018 at 7:43 PM Yu Tianpeng <[email protected]> wrote:
> Thanks a lot, Sasha, Please check response inline. > Tim > > On Wed, Nov 14, 2018 at 11:17 PM Alexander Vainshtein < > [email protected]> wrote: > >> 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. * >> > [Tim]: Agree, but I find in "8.4.1. Multiple Colors" we are using color > comparing color as a tie-break. We are using color as SR Policy election. > I should mention the comment actually comes from 8.4.1, sorry for that:) > So we can have multipls colors with same destination. In such case color > actually becomes a "preference value" among SR policies. > > > 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>.* >> > [Tim]: SR-MPLS draft says SRGB MUST NOT cover reserved label space. But > in a SID list reserved label they can still be used with their original > usage. > This is also mentioned in Page 11 Type-1 : SR-MPLS Label: "Additionally, > reserved labels like explicit-null or in general any MPLS label may also > be used." > My question is if such case is already considered in the validation > process defined in 5.1 > >> 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
