Thanks everybody for your answer. It is clear that Adj-SID is linked to the existence of an IS-IS adjacency with a neighbour, thus it is not usable for passive interface or inter-domain link.
Regards Olivier Le 10/05/2019 à 14:22, Ketan Talaulikar (ketant) a écrit : > +1 > > Hi Oliver, > > Technically Adj-SID refers to an IGP adjacency between two nodes as per > RFC8402 semantics. I don't think a passive (stub) link falls under that > category. It would be better to define a passive link separately (somewhat on > lines of what was done for inter-AS TE) so that it does not get mixed up with > the classical IGP links. I would think a new draft would be apt for such an > extension. > > Thanks, > Ketan > > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) > Sent: 10 May 2019 17:39 > To: Christian Franke <[email protected]>; > [email protected]; SPRING <[email protected]>; LSR <[email protected]> > Subject: Re: [Lsr] Adjacency SID and Passive Interface > > Hi Chris, Olivier, > > On 5/10/19, 4:41 AM, "Lsr on behalf of Christian Franke" > <[email protected] on behalf of [email protected]> wrote: > > On 5/10/19 9:58 AM, [email protected] wrote: > > In the current state of Segment Routing drafts, do you think it is > possible to advertise > > Adjacency SID on such passive or inter-domain interfaces or do we need > to specify this behaviour > > in a new draft ? > > > > For me I don't see anything in the drafts that prohibits this kind of > advertisement, but perhaps I'm wrong. > > My understanding is that the SID is specific to an adjacency and > advertised in IS-IS in either TLV 22, 222, 23, 223. > > As adjacencies will not be formed on a passive interface, an adjacency > SID should not be advertised for the passive interface. > > I agree with Chris. We shouldn't reuse the existing Adj-SID when there will > never be an adjacency and the current semantics require this. If we need > advertisement of SIDs for passive interfaces, it would definitely be a new > draft that clearly articulates the use case and designates a new type of SID > that has different semantics. Also note that while passive interfaces are > very useful in order to include a stub network in the topologies, they are > not part of the OSPF specifications. I haven't done an exhaustive search on > IS-IS. > > Thanks, > Acee > > > I might also be wrong here, though. > > All Best, > Chris > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
