Subject: [spring] SR Policy: per-SL reverse

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Sat, 13 Nov 2021 02:09:44 +0000

Hi SPRING WG,

During the PCE session there was a presentation about signaling per-SL (Segment List) reverse paths, see https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5. I received comments to bring this up in the SPRING WG.

In the simplest case, you have two SR Policies in opposite directions, something like this:

SR policy POL1 <headend = PE1, endpoint = PE2>
  Candidate-path CP1
    SID-List = <ABC>

SR policy POL2 <headend = PE2, endpoint = PE1>
  Candidate-path CP1
    SID-List = <CBA>

Where <ABC> and <CBA> are two segment lists that can be considered "opposites" of each other, maybe traversing the same links in reverse, or maybe just the same nodes, etc.

However, if the SR Policies have multiple segment lists, it gets more complicated:

SR policy POL1 <headend = PE1, endpoint = PE2>
  Candidate-path CP1
    SID-List = <ABC>
    SID-List = <DEF>

SR policy POL2 <headend = PE2, endpoint = PE1>
  Candidate-path CP1
    SID-List = <CBA>
    SID-List = <FED>

Where <ABC> and <CBA> are opposites, also <DEF> and <FED> are opposites.

REQ 1: It should be possible to express that multiple reverse SLs correspond to the same forward SL. For example, if the forward SL is using Node Segment(s) with ECMP and reverse SLs use Adjacency Segments to cover multiple ECMP paths in reverse.

REQ 2: It should be possible to express that SL 1 is a reverse of SL 2, but SL 2 is *not* a reverse of SL 1. I.e., not mutually reverse.

REQ 3: Having a set of reverse SL(s) associated to every forward SL is useful even if there is no actual SR Policy in the reverse direction. I.e., if there's just a unidirectional "forward" SR Policy that needs to know the return paths for each of its SLs.

Currently SR Policy Architecture does not talk about reverse SLs. I'm requesting the WG to review the proposal and decide if we should standardize this.

Thanks,
Mike.

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 13 Nov 2021 08:50:53 +0530

Hi Mike,

You are right that the SR Policy architecture draft does not talk about
reverse SLs. But it also doesn't talk about bidirectional paths or aspects
like the use of association objects for disjoint paths. At one point in
time, some of us (WG members) were of the view that these aspects may be
covered in the standards track draft but such topics were moved out to an
informational draft draft-filsfils-spring-sr-policy-considerations as these
were use-cases.

Specifically on the point of "reverse SL", I think that the term is
misleading. The SLs in a given SR Policy are always ordered in the forward
direction (head to tail). This is not being changed. That there is another
SR Policy with an SL having a reverse order of segment is more of a path
computation constraint. There is no change or update required for this to
the SR Policy architecture.

Today, we already have protocol mechanisms defined for various constraints
and their use-cases - those again are not covered by the SR Policy
architecture document (some are in the companion information document that
we stopped updating at a point).

In summary, there is nothing that I see in this new/proposed work that
changes what we have in the SR Policy document. Whether we need to start a
new document (not standards but informational in my view as this is a
use-case), I leave it to the WG and chairs. My preference would be to
incorporate such use-cases in the existing informational draft if the WG
does want to take up this work.

Thanks,
Ketan

On Sat, 13 Nov 2021 at 07:40, Mike Koldychev (mkoldych) <mkoldych=
[email-masked]> wrote:

> Hi SPRING WG,
>
>
>
> During the PCE session there was a presentation about signaling per-SL
> (Segment List) reverse paths, see
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5.
> I received comments to bring this up in the SPRING WG.
>
>
>
> Where <ABC> and <CBA> are two segment lists that can be considered
> “opposites” of each other, maybe traversing the same links in reverse, or
> maybe just the same nodes, etc.
>
>
>
> REQ 1: It should be possible to express that multiple reverse SLs
> correspond to the same forward SL. For example, if the forward SL is using
> Node Segment(s) with ECMP and reverse SLs use Adjacency Segments to cover
> multiple ECMP paths in reverse.
>
>
>
> REQ 2: It should be possible to express that SL 1 is a reverse of SL 2,
> but SL 2 is **not** a reverse of SL 1. I.e., not mutually reverse.
>
>
>
> REQ 3: Having a set of reverse SL(s) associated to every forward SL is
> useful even if there is no actual SR Policy in the reverse direction. I.e.,
> if there’s just a unidirectional “forward” SR Policy that needs to know the
> return paths for each of its SLs.
>
>
>
> Currently SR Policy Architecture does not talk about reverse SLs. I’m
> requesting the WG to review the proposal and decide if we should
> standardize this.
>
>
>
> Thanks,
>
> Mike.
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Nov 2021 22:52:53 -0500

I am missing something.  In what context is it important to say that 
policy 2 is intended to represent the reverse of policy 1?

Yours,
Joel

On 11/12/2021 9:09 PM, Mike Koldychev (mkoldych) wrote:
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5 
> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5>. 
> “opposites” of each other, maybe traversing the same links in reverse, 
> or maybe just the same nodes, etc.
> 
> correspond to the same forward SL. For example, if the forward SL is 
> using Node Segment(s) with ECMP and reverse SLs use Adjacency Segments 
> to cover multiple ECMP paths in reverse.
> 
> useful even if there is no actual SR Policy in the reverse direction. 
> I.e., if there’s just a unidirectional “forward” SR Policy that needs to 
> know the return paths for each of its SLs.
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 15 Nov 2021 07:20:47 +0000

Hi Ketan,

I think you are talking something very important.  Also I think describing this use case in an information draft will accelerate the progress.

But I think the key to address this problem is that we should sync up among SPRING, IDR and PCE, and even LSR WG.

Like SR policy, we have a architecture draft, and then we have a BGP extension draft for it. We also have an PCEP draft for it, but PCEP does not support multiple ERO/Path at that time. So everything defined in PCE is about LSP level/Candidate path level.

For instance, Path Segment, which is defined for identifying an SR path in data plane.  In BGP extension [1],  it is an Segment list level extension, while in PCEP, it is an LSP/CP level extension[2][3]. After  Mike proposed Multiple ERO/Multiple path draft, I think the all the LSP/CP level PCEP extensions should have a chance to sync up with BGP extension or SR policy architecture.

I have not known the difference between Reserved SL and bidirectional path, but I think a bidirectional path can have the SID list with reversed order. We can have more discuss of the use cases.

Thinking about Mike’s extension is mainly about control plane and the path ID will not be used in the packet, and the path segment will be used in the packet, I see good chances for us to cooperate.

Again, it is the time to sync up among SPRING, PCE, IDR, LSR and 6MAN WGs.

[1]. https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment-04#section-3
[2]. https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04
[3]. https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-08

From: spring [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Saturday, November 13, 2021 11:21 AM
To: mkoldych=[email-masked]
Cc: Rakesh Gandhi (rgandhi) <[email-masked]>; SPRING WG <[email-masked]>; Chengli (Cheng Li) <[email-masked]>
Subject: Re: [spring] SR Policy: per-SL reverse

Hi Mike,

You are right that the SR Policy architecture draft does not talk about reverse SLs. But it also doesn't talk about bidirectional paths or aspects like the use of association objects for disjoint paths. At one point in time, some of us (WG members) were of the view that these aspects may be covered in the standards track draft but such topics were moved out to an informational draft draft-filsfils-spring-sr-policy-considerations as these were use-cases.

Specifically on the point of "reverse SL", I think that the term is misleading. The SLs in a given SR Policy are always ordered in the forward direction (head to tail). This is not being changed. That there is another SR Policy with an SL having a reverse order of segment is more of a path computation constraint. There is no change or update required for this to the SR Policy architecture.

Today, we already have protocol mechanisms defined for various constraints and their use-cases - those again are not covered by the SR Policy architecture document (some are in the companion information document that we stopped updating at a point).

In summary, there is nothing that I see in this new/proposed work that changes what we have in the SR Policy document. Whether we need to start a new document (not standards but informational in my view as this is a use-case), I leave it to the WG and chairs. My preference would be to incorporate such use-cases in the existing informational draft if the WG does want to take up this work.

Thanks,
Ketan

On Sat, 13 Nov 2021 at 07:40, Mike Koldychev (mkoldych) <mkoldych=[email-masked]<mailto:[email-masked]>> wrote:
Hi SPRING WG,

Where <ABC> and <CBA> are two segment lists that can be considered “opposites” of each other, maybe traversing the same links in reverse, or maybe just the same nodes, etc.

REQ 3: Having a set of reverse SL(s) associated to every forward SL is useful even if there is no actual SR Policy in the reverse direction. I.e., if there’s just a unidirectional “forward” SR Policy that needs to know the return paths for each of its SLs.

Currently SR Policy Architecture does not talk about reverse SLs. I’m requesting the WG to review the proposal and decide if we should standardize this.

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

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Mon, 15 Nov 2021 16:26:03 +0000

Hi Joel,

The context could be Circuit-Style SR Policy, or even just sending OAM packets on a particular path and looping it back on the exact same path/paths in reverse, by putting both forward and reverse label stacks (with or without any SR Policy at the opposite end).

Note that I'm not talking about SR Policy POL1 being reverse of POL2. I'm talking about individual Segment Lists (SLs) being reverses of other SLs.

The meaning of "reverse SL" is simple when both SLs are expressed as adjacencies. But it's currently not well defined when Node SIDs are involved. For example, the reverse of one Node-SID SL may require multiple Adjacency-SID SLs to cover all ECMP paths.

So, I'm just bringing up this topic. I tend to agree with Cheng that we should sync this with PCE/IDR/SPRING/etc.

Thanks,
Mike.

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Friday, November 12, 2021 10:53 PM
To: Mike Koldychev (mkoldych) <[email-masked]>; SPRING WG <[email-masked]>
Cc: Rakesh Gandhi (rgandhi) <[email-masked]>; Chengli (Cheng Li) <[email-masked]>
Subject: Re: [spring] SR Policy: per-SL reverse

I am missing something.  In what context is it important to say that policy 2 is intended to represent the reverse of policy 1?

Yours,
Joel

On 11/12/2021 9:09 PM, Mike Koldychev (mkoldych) wrote:
> REQ 2: It should be possible to express that SL 1 is a reverse of SL 
> 2, but SL 2 is **not** a reverse of SL 1. I.e., not mutually reverse.
> 
> I.e., if there’s just a unidirectional “forward” SR Policy that needs 
> to know the return paths for each of its SLs.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Nov 2021 12:10:59 -0500

Thanks.  I had not understood that the point was to specify the 
"reverse" policy to the node that is being given the "forward" policy. 
So that the forward node can specify the reverse in the message it 
sends.  That is understandable.  And probably in the draft?  (I was 
asking based on the email.)

Again, thanks for explaining,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Nov 2021 09:24:51 -0800

Hi Mike,
I have a question about the possible use of the reverse SR path association
and much appreciate your help understanding its use in OAM.
In draft-ietf-spring-bfd
<https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/> we propose a new
Non-FEC TLV to specify the SR policy for the reverse direction of a BFD
session bootstrapped via LSP ping. Also, we propose that the same Non-FEC
TLV can be used to control the path of the LSP Echo Reply sent in response
to the LSP Echo Request that includes the Non-FEC TLV. What other use cases
for the SR reverse association do you see?

Regards,
Greg

On Mon, Nov 15, 2021 at 8:26 AM Mike Koldychev (mkoldych) <mkoldych=
[email-masked]> wrote:

> Hi Joel,
>
> The context could be Circuit-Style SR Policy, or even just sending OAM
> packets on a particular path and looping it back on the exact same
> path/paths in reverse, by putting both forward and reverse label stacks
> (with or without any SR Policy at the opposite end).
>
> Note that I'm not talking about SR Policy POL1 being reverse of POL2. I'm
> talking about individual Segment Lists (SLs) being reverses of other SLs.
>
> The meaning of "reverse SL" is simple when both SLs are expressed as
> adjacencies. But it's currently not well defined when Node SIDs are
> involved. For example, the reverse of one Node-SID SL may require multiple
> Adjacency-SID SLs to cover all ECMP paths.
>
> So, I'm just bringing up this topic. I tend to agree with Cheng that we
> should sync this with PCE/IDR/SPRING/etc.
>
> Thanks,
> Mike.
>
> > <
> >.

---

From: Boris Hassanov <[email-masked]>
Date: Tue, 16 Nov 2021 20:33:56 +0000 (UTC)

Hi Mike and all,
IMO, one of possible use cases of "reverse SL" could be a case of centralized control plane where controller (PCE) due to some input constrains/policy should take in account the calculation and usage of reverse SLs (paths) for some specific primary  SLs. For example when we have to match primary and reverse SLs due to some operations requirements.So I support Mike proposal. I think it can be mentioned in both places: draft-filsfils-spring-sr-policy-considerations and SR Policy architecture draft.
Thank you.
SY,Boris
    On Monday, November 15, 2021, 08:25:26 PM GMT+3, Greg Mirsky <[email-masked]> wrote:  
 
 Hi Mike,I have a question about the possible use of the reverse SR path association and much appreciate your help understanding its use in OAM.In draft-ietf-spring-bfd we propose a new Non-FEC TLV to specify the SR policy for the reverse direction of a BFD session bootstrapped via LSP ping. Also, we propose that the same Non-FEC TLV can be used to control the path of the LSP Echo Reply sent in response to the LSP Echo Request that includes the Non-FEC TLV. What other use cases for the SR reverse association do you see?
Regards,Greg
On Mon, Nov 15, 2021 at 8:26 AM Mike Koldychev (mkoldych) <mkoldych=[email-masked]> wrote:

Hi Joel,

Thanks,
Mike.

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Friday, November 12, 2021 10:53 PM
To: Mike Koldychev (mkoldych) <[email-masked]>; SPRING WG <[email-masked]>
Cc: Rakesh Gandhi (rgandhi) <[email-masked]>; Chengli (Cheng Li) <[email-masked]>
Subject: Re: [spring] SR Policy: per-SL reverse

Yours,
Joel