Hi Sasha,
On 05/03/2019 17:28 , Alexander Vainshtein wrote:
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?
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
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
-----Original Message-----
From: Peter Psenak <[email protected]>
Sent: Tuesday, March 5, 2019 5:28 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; [email protected];
[email protected]
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs
Hi Sasha,
On 02/03/2019 18:57 , Alexander Vainshtein wrote:
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.
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?
Regards, and lots of thanks in advance,
Thumb typed by Sasha Vainshtein
----------------------------------------------------------------------
--
*From:* Peter Psenak <[email protected]>
*Sent:* Thursday, February 28, 2019 9:56:49 PM
*To:* Alexander Vainshtein;
[email protected]
*Cc:* [email protected]; [email protected]
*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 protected]
_____________________________________________________________________
______
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 protected]
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.
______________________________________________________________________
_____
___________________________________________________________________________
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.
___________________________________________________________________________
.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
