Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Acee:
As Tony suggested also before, we can change the description for “passive” to “stub” later.
Is that more acceptable then?

Aijun Wang
China Telecom

> On Jan 14, 2020, at 06:40, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> 
> Hi Aijun,
>  
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Date: Monday, January 13, 2020 at 5:37 PM
> To: Jeff Tantsura <jefftant.ietf@gmail.com>
> Cc: Acee Lindem <acee@cisco.com>, Tony Li <tony.li@tony.li>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, Robert Raszuk <robert@raszuk.net>
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>  
> Hi, Acee, Les and Jeff:
> IGP is used to transfer the topology information within the domain, and the stub/passive interface is the important part of one network, especially for the inter-AS topology.
> Currently, we have not figured out other use cases to distinguish other interfaces type. But for stub/passive interfaces, it will be useful to flooding such information to other internal routers.
>  
> A stub interface is not necessarily a passive interace.
>  
> OSPF has already the corresponding consideration and specifications, isn’t it reasonable for ISIS to have such capabilities also?
>  
> OSPF doesn’t advertise that an interface is a passive interface. Others routing can’t distinguish a passive interface from any other stub link.
>  
> Thanks,
> Acee
>  
> 
> Aijun Wang
> China Telecom
> 
> 
> On Jan 14, 2020, at 02:41, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> 
> Agree with Acee and Les
>  
> Cheers,
> Jeff
> On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) <ginsberg@cisco.com>, wrote:
> 
> I agree with Acee that there is no requirement to identify an interface as passive – or (as suggested in this thread) as loopback or tunnel or stub…
>  
> Before debating the best encoding for information, it would be sensible to define the use case/requirements.
> Simply having an advertisement that identifies an interface type isn’t sufficient to do anything useful IMO.
>  
>    Les
>  
> From: Acee Lindem (acee) <acee@cisco.com>
> Sent: Monday, January 13, 2020 8:03 AM
> To: tony.li@tony.li; Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Robert Raszuk <robert@raszuk.net>; lsr@ietf.org
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>  
> Hi Aijun,
> I guess the external use case for this is advertisement in BGP-LS for Network Management purposes?? There really isn’t IS-IS requirement to know whether or not an interface is a passive interface.
> Thanks,
> Acee
>  
> From: Lsr <lsr-bounces@ietf.org> on behalf of Tony Li <tony.li@tony.li>
> Date: Monday, January 13, 2020 at 11:00 AM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
> Subject: Re: [Lsr] Methods to label the passive interfaces within ISIS
>  
>  
> Hi Anjun,
>  
>  
> 
> Is it reasonable to put the link attribute information into the “IP Reachability TLV”?
> IMHO, such stub link is not the normal links within IGP domain.  Label the related prefix is coming from the passive/stub link seems also acceptable?
>  
>  
> Well, a passive interface is really configured so that you advertise the interface’s prefix.  Attaching the data that you want to the associated data seems reasonable to me.
>  
> There’s no good IS Neighbor advertisement to attach the sub-TLV to because there is no neighbor.
>  
> Tony
>  
>  
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr