+1

Regards,
Jeff

> On May 10, 2019, at 05:22, Ketan Talaulikar (ketant) <[email protected]> wrote:
> 
> +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
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to