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

["Acee Lindem (acee)" <[e-mail]>]

Hi Aijun,

From: Aijun Wang <[e-mail]>
Date: Monday, January 13, 2020 at 5:48 PM
To: Acee Lindem <[e-mail]>
Cc: Jeff Tantsura <[e-mail]>, "Les Ginsberg (ginsberg)" <[e-mail]>, Tony Li <[e-mail]>, Robert Raszuk <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: 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?

Yes – but I’d still like to know why this is needed.

Thanks,
Acee

Aijun Wang
China Telecom


On Jan 14, 2020, at 06:40, Acee Lindem (acee) <[e-mail]> wrote:
Hi Aijun,

From: Aijun Wang <[e-mail]>
Date: Monday, January 13, 2020 at 5:37 PM
To: Jeff Tantsura <[e-mail]>
Cc: Acee Lindem <[e-mail]>, Tony Li <[e-mail]>, "Les Ginsberg (ginsberg)" <[e-mail]>, "[e-mail]" <[e-mail]>, Robert Raszuk <[e-mail]>
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 <[e-mail]> wrote:
Agree with Acee and Les

Cheers,
Jeff
On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) <[e-mail]>, 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) <[e-mail]>
Sent: Monday, January 13, 2020 8:03 AM
To: [e-mail]; Aijun Wang <[e-mail]>
Cc: Les Ginsberg (ginsberg) <[e-mail]>; Robert Raszuk <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> on behalf of Tony Li <[e-mail]<mailto:[e-mail]>>
Date: Monday, January 13, 2020 at 11:00 AM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Cc: "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>, Robert Raszuk <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr