Thanks Siva, please check inline Regards, Tim On 2018\11\19 星期一 5:43:43, Siva Sivabalan (msiva) <[email protected]> wrote: 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. [Tim]: OK. It is only used in multiple color mode, it does not worth an explicit definition here. 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. [Tim]: Fine. I believe this part is understandable :)
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. [Tim]: Yes, BSID cannot be an identifier of SR policy, buy if you check per flow steering, BSID is directly downloaded in forwarding plane as an identifier. I suppose the proper way should be use SR-policy as NHP of entries instead of directly using BSID: E.g.: o N via a recursion on an array A (instead of the immediate outgoing link associated with the IGP shortest-path to N). o Entry A(0) set to the immediate outgoing link of the IGP shortest- path to N. o Entry A(1) set to SR Policy P1 of BSID=B1. ==>Entry A(1) set to SR Policy P1 o Entry A(2) set to SR Policy P2 of BSID=B2. ==>Entry A(2) set to SR Policy P2 In case BSID of SR pilicy changes, control plane can update BSID of the policy in forwarding plane directly. Another case would be as below a SR policy can have a candidate path as backup even. A(1) ---> P1 ---> B1 (primary) |-------->B1' (Backup) Thanks.. Regards, Tim
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
