Subject: [spring] draft-ietf-spring-segment-routing-policy

From: Yu Tianpeng <[email-masked]>
Date: Wed, 14 Nov 2018 08:05:37 +0000

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.

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Nov 2018 15:17:25 +0000

Tim,
Please see some comments inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring <[email-masked]> On Behalf Of Yu Tianpeng
Sent: Wednesday, November 14, 2018 10:06 AM
To: [email-masked]
Subject: [spring] draft-ietf-spring-segment-routing-policy

Dear authors,

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]: 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

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.

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.
___________________________________________________________________________

---

From: Yu Tianpeng <[email-masked]>
Date: Wed, 14 Nov 2018 21:00:13 +0800

On Wed, Nov 14, 2018 at 7:43 PM Yu Tianpeng <[email-masked]>
wrote:

> Thanks a lot, Sasha, Please check response inline.
> Tim
>
> On Wed, Nov 14, 2018 at 11:17 PM Alexander Vainshtein <
> [email-masked]> wrote:
>
>> Tim,
>>
>> Please see some comments *inline below*.
>>
>>
>>
>> Regards,
>>
>> Sasha
>>
>>
>>
>> Office: +972-39266302
>>
>> Cell:      +972-549266302
>>
>> *From:* spring <[email-masked]> *On Behalf Of *Yu Tianpeng
>> *Sent:* Wednesday, November 14, 2018 10:06 AM
>> *To:* [email-masked]
>> *Subject:* [spring] draft-ietf-spring-segment-routing-policy
>>
>>
>>
>> Dear authors,
>>
>> *[[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:*
>>
>> *From my POV, there is nothing in the draft that makes any color value
>> special in any way. *
>>
>> 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? *
>>
>> *[[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
>>  *[[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-6.2..1>.
>> 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
>> [Tim]: I have concerns that BSID is programmed into the forwarding plane
>> as in “6.2

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Sun, 18 Nov 2018 21:43:41 +0000

Hi Tim,

Please see in-line.

Thanks,
Siva

From: spring <[email-masked]> On Behalf Of Yu Tianpeng
Sent: Wednesday, November 14, 2018 3:06 AM
To: [email-masked]
Subject: [spring] draft-ietf-spring-segment-routing-policy

Dear authors,

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.

 <SIVA> We shall consider this suggestion in the next  revision.

 <SIVA> Noted.

 <SIVA> We will add more clarity w.r.t explicit-null in the next revision, and yes logic is “OR”.

 <SIVA> Thanks for catching it. We will fix it.

 <SIVA> I fail to understand the confusion. The text is also explanatory.

<SIVA> The text refers to applying restrictive behavior for some or all SR policies on a head-end.

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

---

From: "Tianpeng.Yu" <[email-masked]>
Date: Sun, 18 Nov 2018 22:15:41 +0800

Thanks Siva, please check inline
Regards,
Tim
On 2018\11\19 星期一 5:43:43, Siva Sivabalan (msiva) <[email-masked]> wrote:
Hi Tim,
 
Please see in-line.
 
Thanks,
Siva

Dear authors,
 
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]: 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