Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

From: [email-masked]
Date: Sun, 01 Nov 2020 16:57:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : Segment Routing Policy Architecture
        Authors         : Clarence Filsfils
                          Ketan Talaulikar
                          Daniel Voyer
                          Alex Bogdanov
                          Paul Mattes
	Filename        : draft-ietf-spring-segment-routing-policy-09.txt
	Pages           : 37
	Date            : 2020-11-01

Abstract:
   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path.  Intermediate per-flow states are eliminated thanks
   to source routing.  The headend node steers a flow into an SR Policy.
   The header of a packet steered in an SR Policy is augmented with an
   ordered list of segments associated with that SR Policy.  This
   document details the concepts of SR Policy and steering into an SR
   Policy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 2 Nov 2020 01:02:26 +0000

Hello All,

We have just posted an update for the draft and following is the summary of changes:

1) Introduction of the Composite Candidate Path construct to address a pending comment from the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/ and https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
2) Based on offline feedback received, updated SRv6 segment types to include optional SRv6 SID and behavior instead of the new type that was introduced for it in the v08.
3) Clarification of handling of colors and BGP multi-path scenarios based on offline feedback received.
4) Clarification on considerations for TI-LFA for SR Policy as discussed in the WG (Ref : https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)

Please let know your comments/feedback.

Thanks,
Ketan (on behalf of co-authors)

-----Original Message-----
From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: 02 November 2020 06:27
To: [email-masked]
Cc: [email-masked]
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 5 Nov 2020 19:14:47 +0000

Hi Ketan,

Thanks for this update / referencing the yang related question I had about multiple objective/constraints (1). Regarding composite candidate path, quickly thinking about it from a controller/pce point of view, it does seem like an elegant solution to re-use the entire SR Policy construct in a nested manner to achieve combination of TE constraint/objective patterns, avoiding a lot of complexity in yang/protocol modelling at the cost of more SR Policy headend/controller state to manage/deal/work with. I think it was a good idea to have that restriction of a depth of one. No other comments or feedback yet, will let this stew a bit.

Thanks again,
Andrew

On 2020-11-01, 8:02 PM, "spring on behalf of Ketan Talaulikar (ketant)" <[email-masked] on behalf of ketant=[email-masked]> wrote:

    Hello All,

    Thanks,

    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of [email-masked]
    Sent: 02 November 2020 06:27
    To: [email-masked]
    Cc: [email-masked]
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

    Abstract:

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 7 Nov 2020 15:34:19 +0000

Hi Andrew,

Thanks for your comments and it was indeed the motivation for this solution for the use-case brought forward.

Thanks,
Ketan

-----Original Message-----
From: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]> 
Sent: 06 November 2020 00:45
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Ketan,

Thanks again,
Andrew

    Hello All,

    Thanks,

    -----Original Message-----
    From: spring <[email-masked]> On Behalf Of [email-masked]
    Sent: 02 November 2020 06:27
    To: [email-masked]
    Cc: [email-masked]
    Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

    Abstract:

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 9 Nov 2020 12:38:03 -0600

Ketan,

Much Thanks for taking a stab at addressing the composite candidate path
use-case! We seem to be converging. However, I don’t understand why you
need to use additional SR policies (and unnecessarily burn additional
colors) to address this. Why can’t the composite candidate path just be a
grouping of explicit candidate paths and/or dynamic candidate paths?

Consider the following changes:

** Section 2.2

OLD:

   A composite candidate path acts as a container for grouping of SR

   Policies.  The composite candidate path construct enables combination

   of SR Policies, each with explicit candidate paths and/or dynamic

   candidate paths with potentially different optimization objectives

   and constraints, for a load-balanced steering of packet flows over

   its constituent SR Policies.  The following criteria apply for

   inclusion of constituent SR Policies using a composite candidate path

   under a parent SR Policy:

   o  the endpoints of the constituent SR Policies and the parent SR

      Policy MUST be identical

   o  The colors of each of the constituent SR Policies and the parent

      SR Policy MUST be different

   o  the constituent SR Policies MUST NOT use composite candidate paths

   Each constituent SR Policy of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11>
for details).  The default weight is 1.

NEW:

   A composite candidate path acts as a container for grouping of

   explicit candidate paths and/or dynamic candidate paths with

   potentially different optimization objectives and constraints.

   The composite candidate path construct enables load-balanced

   steering of packet-flows over a set of constituent candidate

   paths. The following criteria apply for constituent candidate

   paths under a composite candidate path:

   o  the preference of the constituent candidate path MUST be

      ignored.

   o  the constituent candidate path MUST NOT be a composite candidate

      path

   Each constituent candidate path of a composite candidate path is

   associated with a weight for load-balancing purposes (refer

   Section 2.11
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11>
for details).  The default weight is 1.

**

** Section 2.11

OLD:

   When a composite candidate path is active, the fraction of flows

   steered into each constituent SR Policy is equal to the relative

   weight of each constituent SR Policy.  Further load balancing of

   flows steered into a constituent SR Policy is performed based on the

   weights of the Segment-List of the active candidate path of that

   constituent SR Policy.

NEW:

   When a composite candidate path is active, the fraction of flows

   steered into each constituent candidate path is equal to the relative

   weight of each constituent candidate path.  Further load balancing of

   flows steered into a constituent candidate path is performed based on

   the weights of each associated Segment-List.

**

** Section 2.13

OLD:

   The information model of SR Policy POL100 having a composite

   candidate path is the following:

   SR policy POL100 <headend = H1, color = 100, endpoint = E1>

        Candidate-path CP1 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 1>

            Preference 200

            Weight W1, SR policy <color = 1>

            Weight W2, SR policy <color = 2>

   The constituent SR Policies POL1 and POL2 have information model as

   described at the start of this section.  They are referenced only by

   color in the composite candidate path since their headend and

   endpoint are identical to the POL100.  The valid Segment-Lists of the

   active candidate path of POL1 and POL2 are installed in the

   forwarding.  Traffic steered on POL100 is flow-based hashed on POL1

   with a ratio W1/(W1+W2).  Within the POL1, the flow-based hashing

   over its Segment-Lists are performed as described earlier in this

   section.

NEW:

   The information model of SR Policy POL100 having a composite

   candidate path is the following:

   SR policy POL100 <headend = H1, color = 100, endpoint = E1>

        Candidate-path Comp-CP <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 1>

            Preference 200

            Weight W1, Candidate-path CP1

            Weight W2, Candidate-path CP2

        Candidate-path CP1 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 2>

             Weight W11, SID-List1 <SID11...SID1i>

             Weight W12, SID-List2 <SID21...SID2j>

        Candidate-path CP2 <protocol-origin = 20, originator =

   100:1.1.1.1, discriminator = 3>

             Weight W21, SID-List3 <SID31...SID3i>

             Weight W22, SID-List4 <SID41...SID4j>

   Comp-CP is a composite candidate path with two constituents, CP1

   and CP2. The preference is ignored for each of the two constituent

   candidate paths. The valid Segment-Lists of the two constituent

   candidate paths are installed in the forwarding. Traffic steered

   on Comp-CP is flow-based hashed on to CP1 and CP2 with a ratio of

   W1/(W1+W2) and W2/(W1+W2) respectively. Within each constituent

   candidate path, the flow-based hashing over its Segment-Lists are

   performed as described earlier in this section.

**

** Section 5.3

OLD:

   A composite candidate path is specified as a group of its constituent

   SR Policies.

   A composite candidate path is valid when it has at least one valid

   constituent SR Policy.

NEW:

   A composite candidate path is specified as a group of its constituent

   candidate paths.

   A composite candidate path is valid when it has at least one valid

   constituent candidate path.

**

Regards,

-Pavan

On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> 1) Introduction of the Composite Candidate Path construct to address a
> pending comment from the WG (Ref :
> https://mailarchive.ietf.org/arch/msg/spring/fEqE5TOwdh2vEyFm_MEjiXyP2ws/
> and
> https://mailarchive.ietf.org/arch/msg/spring/d9oSSbgp0jCExRx0SXyBY0CyqXU/)
> 2) Based on offline feedback received, updated SRv6 segment types to
> include optional SRv6 SID and behavior instead of the new type that was
> introduced for it in the v08.
> 4) Clarification on considerations for TI-LFA for SR Policy as discussed
> in the WG (Ref :
> https://mailarchive.ietf.org/arch/msg/spring/EV1ytUsd5ZgkMHDN0IvFhw9id40/)
>
> Subject: [spring] I-D Action:
> draft-ietf-spring-segment-routing-policy-09.txt
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 10 Nov 2020 10:04:16 +0000

Hi Pavan,

Please check inline below.

From: Vishnu Pavan Beeram <[email-masked]>
Sent: 10 November 2020 00:08
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Ketan,

Much Thanks for taking a stab at addressing the composite candidate path use-case! We seem to be converging.
[KT] Thanks for that feedback and confirmation that the proposal in the draft does address the use-case. I believe we are now discussing the mechanics of how this is achieved within the current SR Policy framework.

However, I don’t understand why you need to use additional SR policies (and unnecessarily burn additional colors) to address this.
[KT] I do not follow what you mean by “burn additional colors”. Color is just a 32 bit number that indicates the “intent” and is not really a scarce resource. Assigning a color to “a composite intent” seems like a seamless way to integrate with existing mechanisms for Steering over SR Policies. This gives the flexibility for say some BGP services to be steered over the constituent explicit/dynamic intent while others can steer over a composite intent that includes those individual explicit/dynamic intents.

Why can’t the composite candidate path just be a grouping of explicit candidate paths and/or dynamic candidate paths?
[KT] This is because in the SR Policy framework, there is only a single active CP – it may be explicit or dynamic. Now we’ve added another Composite CP type to cover this specific use-case. Your proposal will result in 3 candidate paths being active within the same SR Policy – one each of the explicit and dynamic CP and then additionally the Composite CP. This breaks the existing rules for selection of CP based on preference and mechanisms like fallback between CPs. While the current proposal in the draft provides a way to address the new use-case with a backwards compatible extension to the SR Policy framework.

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

   Section 2.11<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.

NEW:

      ignored.

      path

   Section 2.11<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

On Sun, Nov 1, 2020 at 7:02 PM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hello All,

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 10 Nov 2020 12:56:22 -0600

Ketan, Hi!

Please see inline for responses (prefixed VPB).

Regards,
-Pavan

On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> *From:* Vishnu Pavan Beeram <[email-masked]>
> *Sent:* 10 November 2020 00:08
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [spring] I-D Action:
> use-case! We seem to be converging.
>
> *[KT] Thanks for that feedback and confirmation that the proposal in the
> draft does address the use-case. I believe we are now discussing the
> mechanics of how this is achieved within the current SR Policy framework.*
>
>

>
> However, I don’t understand why you need to use additional SR policies
> (and unnecessarily burn additional colors) to address this.
>
> *[KT] I do not follow what you mean by “burn additional colors”. Color is
> just a 32 bit number that indicates the “intent” and is not really a scarce
> resource. Assigning a color to “a composite intent” seems like a seamless
> way to integrate with existing mechanisms for Steering over SR Policies.
> This gives the flexibility for say some BGP services to be steered over the
> constituent explicit/dynamic intent while others can steer over a composite
> intent that includes those individual explicit/dynamic intents.*
>

[VPB] The “flexibility” that you are referring to is undesirable for this
use-case. For the traffic-split use-case, we don’t want any other services
to be directly steered over the constituents when they are part of a
composite candidate path. The current proposal in the draft would have been
acceptable if the constituent SR Policies were uncolored – but that would
violate the current rules imposed by the draft.

>
> Why can’t the composite candidate path just be a grouping of explicit
> candidate paths and/or dynamic candidate paths?
>
> *[KT] This is because in the SR Policy framework, there is only a single
> active CP – it may be explicit or dynamic. Now we’ve added another
> Composite CP type to cover this specific use-case. Your proposal will
> result in 3 candidate paths being active within the same SR Policy – one
> each of the explicit and dynamic CP and then additionally the Composite CP.
> This breaks the existing rules for selection of CP based on preference and
> mechanisms like fallback between CPs. While the current proposal in the
> draft provides a way to address the new use-case with a backwards
> compatible extension to the SR Policy framework.*
>

[VPB] The proposal in my previous email is backwards compatible and does
not intend to break any existing rules for deeming a candidate path active.
As per the rules that are outlined in Section 2.9, only the composite
candidate path is “active” given its preference. The constituent candidate
paths will never be active on their own. If it is necessary, we can add a
statement in Section 2.9 to explicitly state that the candidate path
selection criteria does not apply to the constituent candidate paths.

> *Thanks,*
> *Ketan*
>    Section 2.11 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.
>
>
>
> NEW:
>
>    Section 2.11 <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-2.11> for details).  The default weight is 1.
>
>
>
> **
>
>
>
> ** Section 2.11
>
>
>
> OLD:
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 11 Nov 2020 03:33:09 +0000

Hi Pavan,

From: Vishnu Pavan Beeram <[email-masked]>
Sent: 11 November 2020 00:26
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Ketan, Hi!

Regards,
-Pavan

On Tue, Nov 10, 2020 at 4:04 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pavan,

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Sent: 10 November 2020 00:08
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Ketan,

[VPB] The “flexibility” that you are referring to is undesirable for this use-case. For the traffic-split use-case, we don’t want any other services to be directly steered over the constituents when they are part of a composite candidate path.
[KT] I believe the use-case that you are referring to was for splitting some traffic for a service over a blue plane and the rest over a red plane. At the same time, there may be other services that utilize only a single plane. The flexibility that I was referring to was to enable/allow for either of the two scenarios and there may be other/more use-cases for which we need a more generic framework.

The current proposal in the draft would have been acceptable if the constituent SR Policies were uncolored – but that would violate the current rules imposed by the draft.

[VPB] The proposal in my previous email is backwards compatible and does not intend to break any existing rules for deeming a candidate path active. As per the rules that are outlined in Section 2.9, only the composite candidate path is “active” given its preference. The constituent candidate paths will never be active on their own. If it is necessary, we can add a statement in Section 2.9 to explicitly state that the candidate path selection criteria does not apply to the constituent candidate paths.
[KT] When a CP is “active” it is actually the one that is being used for forwarding.

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 11 Nov 2020 23:15:47 +0000

Hi Ketan, Pavan,

Good discussion. Just going to chip in some thoughts…

One of the elements I personally like of the SR Policy model is that many Candidate Paths may exist, but only one may be active and a candidate path contains 1 or many SID lists. It’s a simple parent/child - root/leaf tree with very clear rules within the SR policy context instance. From my point of view, what is being proposed in the -09 document still follows those rules and the general top-down tree behaviour. Despite the composite CP pointing to a different SR Policy, that SR Policy still follows all of the same rules top down in its own isolated context. Compare that to say, having a candidate path contain a child that points to other candidate paths within the same SR Policy context: within the same context a child is pointing to a sibling of its parent. The rules now have to bend slightly. As noted below, some of the rules around what is considered an active candidate path would need to change, since the constituents essentially are active (they’re installed) despite not being thought of as being active. Note that the proposed new text below says “The preference is ignored for each of the two constituent candidate paths" which is also a new rule, however one could perhaps work around that by just requiring the preference on the constituents be less preferred than any other standard or composite CP – but that raises its own troubles with multiple sources of provisioning – which leads to a rule asking to ignore the preference. In summary, from my p.o.v new rules in the hierarchy would need to be introduced.

Regarding steering into an SR Policy, yes, you burn colors in doing this (32bits...) and it would require deploying an entirely dedicated SR Policy construct, and run the risk of steering ‘other’ traffic into that policy. If this is a concern, would the composite SR Policies not be engineered in a way where the color block used is designed to not be used elsewhere in the network for other purposes? Is there not a different but kind of similar problem with Binding SIDs, in that they’re eligible for use by other consumers even if not directly intended? (although at least BSIDs are optional and not mandatory). In addition to the split TE cases, being able to have an SR Policy steer into another SR Policy might also have some value in a backup candidate scenario when one has multiple SR Policies with the same endpoint, but can share a common fallback/best effort candidate path. The entity (I'm thinking PCE) managing that would only need to maintain the fallback/best effort CP SID list(s), instead of one for each N * CPs.

Something I haven’t concluded to myself yet are questions such as:

  *   does having a candidate path steer into another SR Policy satisfy the ability to do various sub-path specific TE/constraint/object combinations sufficiently?
  *   is the model relatively straight forward to map into yang/bgp/pcep etc..?
  *   does using an additional SR Policy create too much overhead or state burn to configure, deploy, manage, track etc.. ?

Cheers
Andrew

From: spring <[email-masked]> on behalf of "Ketan Talaulikar (ketant)" <ketant=[email-masked]>
Date: Tuesday, November 10, 2020 at 10:33 PM
To: Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Nov 2020 04:44:58 +0000

Hi Andrew,

Thanks for your inputs and feedback. Please check inline below.

From: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
Sent: 12 November 2020 04:46
To: Ketan Talaulikar (ketant) <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Ketan, Pavan,

One of the elements I personally like of the SR Policy model is that many Candidate Paths may exist, but only one may be active and a candidate path contains 1 or many SID lists. It’s a simple parent/child - root/leaf tree with very clear rules within the SR policy context instance. From my point of view, what is being proposed in the -09 document still follows those rules and the general top-down tree behaviour. Despite the composite CP pointing to a different SR Policy, that SR Policy still follows all of the same rules top down in its own isolated context. Compare that to say, having a candidate path contain a child that points to other candidate paths within the same SR Policy context: within the same context a child is pointing to a sibling of its parent. The rules now have to bend slightly. As noted below, some of the rules around what is considered an active candidate path would need to change, since the constituents essentially are active (they’re installed) despite not being thought of as being active. Note that the proposed new text below says “The preference is ignored for each of the two constituent candidate paths" which is also a new rule, however one could perhaps work around that by just requiring the preference on the constituents be less preferred than any other standard or composite CP – but that raises its own troubles with multiple sources of provisioning – which leads to a rule asking to ignore the preference. In summary, from my p.o.v new rules in the hierarchy would need to be introduced.
[KT] Agree and this would be a far more intrusive and change to the model. That too for a very specific use-case while the current proposal supports not just that use-case but many others as well in a more generic way.

Regarding steering into an SR Policy, yes, you burn colors in doing this (32bits...) and it would require deploying an entirely dedicated SR Policy construct, and run the risk of steering ‘other’ traffic into that policy. If this is a concern, would the composite SR Policies not be engineered in a way where the color block used is designed to not be used elsewhere in the network for other purposes? Is there not a different but kind of similar problem with Binding SIDs, in that they’re eligible for use by other consumers even if not directly intended? (although at least BSIDs are optional and not mandatory). In addition to the split TE cases, being able to have an SR Policy steer into another SR Policy might also have some value in a backup candidate scenario when one has multiple SR Policies with the same endpoint, but can share a common fallback/best effort candidate path. The entity (I'm thinking PCE) managing that would only need to maintain the fallback/best effort CP SID list(s), instead of one for each N * CPs.
[KT] This was exactly one the main considerations for the proposal in the draft currently. In that it provides the flexibility to support not just the very specific use-case for splitting service flows with b/w granularity across different planes, but it enables/allows other use-cases like what you mention. There is also the use-case where there is really no b/w considerations but where  Service R needs to be steered over the red-plane, Service B needs to be steered over the blue-plane while Service A needs to be load-balanced over both red and blue planes. Here, the coloring on the service route will dictate whether the planes are to be used individually or not. This is just one example use-case.

  *   does having a candidate path steer into another SR Policy satisfy the ability to do various sub-path specific TE/constraint/object combinations sufficiently?
  *   is the model relatively straight forward to map into yang/bgp/pcep etc..?
[KT] I believe this is straightforward and we can work these aspects out.

  *   does using an additional SR Policy create too much overhead or state burn to configure, deploy, manage, track etc.. ?
[KT] The unit of signaling being the CP, I don’t think this makes a difference either way.

Thanks,
Ketan

Cheers
Andrew

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Ketan Talaulikar (ketant)" <ketant=[email-masked]<mailto:ketant=[email-masked]>>
Date: Tuesday, November 10, 2020 at 10:33 PM
To: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: Tarek Saad <[email-masked]>
Date: Thu, 12 Nov 2020 19:22:05 +0000

Hi all,

See inline for some comments..

From: spring <[email-masked]> on behalf of "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wednesday, November 11, 2020 at 6:16 PM
To: "Ketan Talaulikar (ketant)" <ketant=[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Ketan, Pavan,

Regarding steering into an SR Policy, yes, you burn colors in doing this (32bits...) and it would require deploying an entirely dedicated SR Policy construct, and run the risk of steering ‘other’ traffic into that policy. If this is a concern, would the composite SR Policies not be engineered in a way where the color block used is designed to not be used elsewhere in the network for other purposes?
[TS]: Today colors of SR Policies that are instantiated “on-demand” or instantiated via PCEP from a PCE are derived from the intent/service. With the hierarchical SR policies proposal, a PCE may need to instantiate the colored child SR policies on-demand too, but it is not clear where the colors of those child SR policies would be derived from. As Andrew suggests, a block of colors could be carved from every headend’s space -- specifically for this purpose and be managed by the PCE. Alternatively, one could consider creating such SR Policies with a special/reserved color that would simplify their creation. My understanding is that there are other cases where SR Policies may be instantiated (e.g. for tactical TE – e.g. on P nodes) that would not require color resolution, and creation of those could benefit from a reserved color too.

Regards,
Tarek

Is there not a different but kind of similar problem with Binding SIDs, in that they’re eligible for use by other consumers even if not directly intended? (although at least BSIDs are optional and not mandatory). In addition to the split TE cases, being able to have an SR Policy steer into another SR Policy might also have some value in a backup candidate scenario when one has multiple SR Policies with the same endpoint, but can share a common fallback/best effort candidate path. The entity (I'm thinking PCE) managing that would only need to maintain the fallback/best effort CP SID list(s), instead of one for each N * CPs.

1.       does having a candidate path steer into another SR Policy satisfy the ability to do various sub-path specific TE/constraint/object combinations sufficiently?

2.       is the model relatively straight forward to map into yang/bgp/pcep etc..?

3.       does using an additional SR Policy create too much overhead or state burn to configure, deploy, manage, track etc.. ?

Cheers
Andrew

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 12 Nov 2020 23:12:07 +0000

Hi Tarek,

Thanks for the comments. Small reply below.

Thanks
Andrew

From: Tarek Saad <[email-masked]>
Date: Thursday, November 12, 2020 at 2:22 PM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>, "Ketan Talaulikar (ketant)" <ketant=[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi all,

Hi Ketan, Pavan,

[Andrew] Good point indeed. The P node is what I was pointing at with the BSID example, where, for example, we’ll have to burn a color to deploy a SR Policy on a transit node when the consumer intent is simply for the BSID. That color selection would need to be considered ‘special’ and taken from a unique block if one wants to avoid using it for head-end steering on that P node.  Noting that color is part of what uniqueness, to define the “not for steering” behaviour, it would need to be a reserved block or bit encoded in color as opposed to a single special value. I’m not sure a special range needs to be IETF standardized or simply left to implementations/PCE / network design to allocate and enforce. It seems that the model to steer an SR Policy candidate path into another SR Policy with either color or the concept of a special color still seems feasible in the present document. It might be worth having text describing that a constituent candidate path may be used for steering on the headend, and if intention is to avoid that then the user/pce/network design should allocate a block of values for constituent candidate paths and select only from that block, not to be used on any other routes in the network.

Regards,
Tarek

Cheers
Andrew

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 13 Nov 2020 08:43:54 +0000

Hi Andrew/Tarek,

Thanks again for this discussion and your inputs.

I concur with Andrew that color is something that is left to the operator as part of their network design and not something to reserve or define a special range for. This is what would give the operator to choose the various steering mechanisms and how and where to use them in their networks.

Thanks,
Ketan

From: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
Sent: 13 November 2020 04:42
To: Tarek Saad <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Tarek,

Thanks
Andrew

From: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2020 at 2:22 PM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>, "Ketan Talaulikar (ketant)" <ketant=[email-masked]<mailto:ketant=[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi all,

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 11, 2020 at 6:16 PM
To: "Ketan Talaulikar (ketant)" <ketant=[email-masked]<mailto:ketant=[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Ketan, Pavan,

Regards,
Tarek

Cheers
Andrew

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract:

---

From: Tarek Saad <[email-masked]>
Date: Fri, 13 Nov 2020 15:31:26 +0000

Hi Andrew/Ketan,

It’s fine to suggest a static allocation of such block of colors for use in (example) dynamic instantiation of hierarchical SR policies – but this needs to be configured on all potential headends to ensure device/controller consistency (or signaled via PCEP/other). In any case, I think the draft can benefit of a statement to this matter.

Regards,
Tarek

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Friday, November 13, 2020 at 3:43 AM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>, Tarek Saad <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Hi Andrew/Tarek,

Thanks,
Ketan

Hi Tarek,

Thanks
Andrew

Hi all,

Hi Ketan, Pavan,

Regards,
Tarek

Cheers
Andrew

Hi Pavan,

Ketan, Hi!

Regards,
-Pavan

Ketan,

Thanks,
Ketan

Thanks,
Ketan

** Section 2.2
OLD:

      Policy MUST be identical

NEW:

      ignored.

      path

**

** Section 2.11

OLD:

NEW:

**

** Section 2.13

OLD:

NEW:

**

** Section 5.3

OLD:

NEW:

**

Regards,

-Pavan

Thanks,

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 02 November 2020 06:27
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-09.txt

Abstract: