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
<gregimir...@gmail.com> 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=40cisco....@dmarc.ietf.org> 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.
-----Original Message-----
From: Joel M. Halpern <j...@joelhalpern.com>
Sent: Friday, November 12, 2021 10:53 PM
To: Mike Koldychev (mkoldych) <mkold...@cisco.com>; SPRING WG <spring@ietf.org>
Cc: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>; Chengli (Cheng Li)
<c...@huawei.com>
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:
> 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#sect
> ion-4.5
> <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.
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
