Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 2 Mar 2019 17:57:19 +0000

Peter,
Lots of thanks for a prompt and hivhly informative response.

It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local.
The relevant use case could be a protected local Adj-SID that is used in a SR-TE LSP that has been set up with some constraints in mind. These constraints would be preserved when the protected adjacency in question is UP, but could be violated when it fails and the shortest path to the node at the remote end of adjacency is used.

Local protected Adj-SIDs for sure have bern implemented, so this looks like a more relevant use case than global adjacencies to me.

What do you think?

Regards, and lots of thanks in advance,

Thumb typed by Sasha Vainshtein

________________________________
From: Peter Psenak <[email-masked]>
Sent: Thursday, February 28, 2019 9:56:49 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs

Hi Alexander,

On 28/02/2019 19:19 , Alexander Vainshtein wrote:
> Dear colleagues,
>
> I have a question regarding global Adj-SIDs in
> draft-ietf-isis-segment-routing-extensions.
>
>
>
> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  defines
> definition and handling of global Adj-SIDs.
>
> The relevant text is given below:
>
>
>
> <quote>
>
>    Similarly, when using a global Adj-SID, a packet injected anywhere
>
>    within the SR domain with a segment list {SNL}, where SNL is a global
>
>    Adj-SID attached by node N to its adjacency over link L, will be
>
>    forwarded along the shortest path to Nand then be switched by N,
>
>    without any IP shortest-path consideration, towards link L.
>
> ...
>
>    The use of global Adj-SID allows to reduce the size of the segment list
>
>    When expressing a path at the cost of additional state (i.e., the global
>
>    Adj-SID will be inserted by all routers within the area in their
>
>    forwarding table).
>
> <end quote>
>
>
>
> The definition of the Adjacency Segment Identifier Sub-TLV in Section
> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it
> allows advertisement of global Adj-SIDs.
>
> These advertisements can be associated with a specific IGP adjacency
> and, in multi-topology scenarios, a specific topology. But it is not
> associated with any specific algorithm since the default algorithm for
> reaching the advertising node is implicitly assumed in full alignment
> with RFC 8402.
>
>
>
> My question is about the situation in which multiple algorithms are
> supported by the routers in the SR domain, so that each node advertises
> a dedicated Node SID for each of these algorithm.
>
> In this scenario, the operator can set up a SR-TE LSP that meets
> specific constraints (incorporated in one of these algorithms, see IGP
> Flexible Algorithm
> <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-01> draft) by
> using Node SIDs that have been advertised with the corresponding
> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used
> (e.g., for reducing the label stack depth) in this situation.
>
> I wonder if the possibility to advertise global Adj-SID (that can be
> considered as replacing a combination of the Node SID of the advertising
> node and one of its local Adj-SIDs) as associated with a specific
> algorithm has ever been considered?

to be honest, it has been not.

The usage of the global Adj-SID has not been widely considered due to
the additional forwarding entries it requires on rest of the routers in
the area. Not sure if there are implementations of the global ADj-SID
out there.

If you believe this is important, we can certainly addressed that in a
small draft.

thanks,
Peter

>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   [email-masked]
>
>
>
>
> ___________________________________________________________________________
>
> 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.
> ___________________________________________________________________________
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

___________________________________________________________________________

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: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 16:28:28 +0100

Hi Sasha,

On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> The relevant use case could be a protected local Adj-SID that is used in
> a SR-TE LSP that has been set up with some constraints in mind. These
> constraints would be preserved when the protected adjacency in question
> is UP, but could be violated when it fails and the shortest path to the
> node at the remote end of adjacency is used.

yes, this is a possible use case. This would require a new Algo specific 
Adj-SID sub-TLV to be defined. This could be done.

thanks,
Peter

>
> Local protected Adj-SIDs for sure have bern implemented, so this looks
> like a more relevant use case than global adjacencies to me.
>
> What do you think?
>
> ------------------------------------------------------------------------
> *From:* Peter Psenak <[email-masked]>
> *Sent:* Thursday, February 28, 2019 9:56:49 PM
> *To:* Alexander Vainshtein;
> [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [spring] FlexAlgo and Global Adj-SIDs
>
> Hi Alexander,
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Mar 2019 16:28:32 +0000

Peter,
Lots of thanks for a prompt and very encouraging response.

Do you think that the new Algo specific Adj-SID sub-TLV could be added to the current IS-IS segment Routing Extensions draft, or should be handled in a small dedicated document?

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Tuesday, March 5, 2019 5:28 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs

Hi Sasha,

On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> The relevant use case could be a protected local Adj-SID that is used 
> in a SR-TE LSP that has been set up with some constraints in mind. 
> These constraints would be preserved when the protected adjacency in 
> question is UP, but could be violated when it fails and the shortest 
> path to the node at the remote end of adjacency is used.

yes, this is a possible use case. This would require a new Algo specific Adj-SID sub-TLV to be defined. This could be done.

thanks,
Peter

>> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  
>> defines definition and handling of global Adj-SIDs.
>>
>> associated with any specific algorithm since the default algorithm 
>> for reaching the advertising node is implicitly assumed in full 
>> alignment with RFC 8402.
>>
>>
>>
>> supported by the routers in the SR domain, so that each node 
>> advertises a dedicated Node SID for each of these algorithm.
>>
>> specific constraints (incorporated in one of these algorithms, see 
>> IGP Flexible Algorithm 
>> considered as replacing a combination of the Node SID of the 
>> advertising node and one of its local Adj-SIDs) as associated with a 
>> specific algorithm has ever been considered?
>
> the additional forwarding entries it requires on rest of the routers 
> in the area. Not sure if there are implementations of the global 
> ADj-SID out there.
>
>> 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.
> 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: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 17:31:09 +0100

Hi Sasha,

> Do you think that the new Algo specific Adj-SID sub-TLV could be added to the current IS-IS segment Routing Extensions draft, or should be handled in a small dedicated document?

it would have to be a new draft, existing ISIS SR draft is on its way to 
become an RFC and we do not want to return it back to the WG due to this.

thanks,
Peter

> .

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Mar 2019 16:37:24 +0000

Sasha -

draft-ietf-isis-segment-routing-extensions is currently in AD review - and the companion OSPF document has already been approved and is waiting for a dependent draft to progress before publication as an RFC.

It is too late to make significant changes.

Further, while I agree with both your description and Peter's response, agreeing that this "could" be done is not equivalent to having consensus that it "should" be done.
I think a more complete consideration of the deployment cases and the usefulness of such an extension should be discussed by the WG before we decide that we actually want to define such an extension.

  Les

> From: Alexander Vainshtein <[email-masked]>
> Sent: Tuesday, March 05, 2019 8:29 AM
> To: Peter Psenak (ppsenak) <[email-masked]>
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
> 
> Peter,
> Do you think that the new Algo specific Adj-SID sub-TLV could be added to
> the current IS-IS segment Routing Extensions draft, or should be handled in a
> small dedicated document?
> 
> > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Mar 2019 16:47:12 +0000

Les,
Lots of thanks for a prompt response.

I fully understand that the current SR extension drafts are too far advanced for any significant changes.

I also understand that Algo-specific Adj-SIDs require an update to RFC 8402 because today it does not recognize any such entities.
Therefore the discussion of use cases should probably start in the SPRING WG while effective the result would be "just" new Sub-TLV in IS-IS and OSPF with the actual work coming to the LSR WG. 

Any ideas as to what would be the best way to start this kind of discussions? 

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Tuesday, March 5, 2019 6:37 PM
To: Alexander Vainshtein <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [spring] FlexAlgo and Global Adj-SIDs

Sasha -

  Les

> Do you think that the new Algo specific Adj-SID sub-TLV could be added 
> to the current IS-IS segment Routing Extensions draft, or should be 
> handled in a small dedicated document?
> 
> Regards, and lots of thanks in advance, Sasha
> 
> Office: +972-39266302
> Cell:      +972-549266302

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Mar 2019 20:48:43 +0000

Sasha -

Although you raise a valid issue, I am not feeling any urgency here i.e., although the local protected use case is valid I don't see it as operationally critical.
However, that's just my opinion.

If you want to pursue this I think you could raise the issue in either LSR or SPRING (or both).
The gap in the architecture documents is less important than coming to consensus on the importance of the use case.  If there is consensus to address this then I think deciding what documents need updating will just follow logically.

Make sense to you?

   Les

> Sent: Tuesday, March 05, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-isis-segment-routing-
> [email-masked]; Peter Psenak (ppsenak) <[email-masked]>
> I also understand that Algo-specific Adj-SIDs require an update to RFC 8402
> because today it does not recognize any such entities.
> Therefore the discussion of use cases should probably start in the SPRING
> WG while effective the result would be "just" new Sub-TLV in IS-IS and OSPF
> with the actual work coming to the LSR WG.
> 
> draft-ietf-isis-segment-routing-extensions is currently in AD review - and the
> companion OSPF document has already been approved and is waiting for a
> dependent draft to progress before publication as an RFC.
> 
> Further, while I agree with both your description and Peter's response,
> agreeing that this "could" be done is not equivalent to having consensus that
> it "should" be done.
> I think a more complete consideration of the deployment cases and the
> usefulness of such an extension should be discussed by the WG before we
> decide that we actually want to define such an extension.
> 
>   Les
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 6 Mar 2019 06:01:35 +0000

Les,
Lots of thanks, makes sense to me.

________________________________
From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Tuesday, March 5, 2019 10:48:43 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; Peter Psenak (ppsenak)
Subject: RE: [spring] FlexAlgo and Global Adj-SIDs

Sasha -

Make sense to you?

   Les

> [email-masked]
> > [email-masked]
> > [email-masked]