Hi Tim, Please see in-line.
Thanks, Siva From: spring <[email protected]> On Behalf Of Yu Tianpeng Sent: Wednesday, November 14, 2018 3: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. 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. <SIVA> Such a restriction is unnecessary. Color and end-point define an SR policy, and traffic steering mechanism (local behavior) at head-end dictates how a given SR policy is used to transport service. 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. <SIVA> We shall consider this suggestion in the next revision. 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. <SIVA> Noted. 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. <SIVA> We will add more clarity w.r.t explicit-null in the next revision, and yes logic is “OR”. 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. <SIVA> Thanks for catching it. We will fix it. 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. <SIVA> I fail to understand the confusion. The text is also explanatory. 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. <SIVA> The text refers to applying restrictive behavior for some or all SR policies on a head-end. 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. <SIVA> The point since BSID for an SR policy may change, it cannot be used a unique identifier of an SR policy. Thanks.. Regards, Tim
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
