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

Hi, Tony:

Thanks for your suggestions.

If the behavior of “stub link” is same as that “passive interface”, for example, not sending thing on that interface, but can receive, we can modify the description later in the updated version of this draft.

For the link attributes that defined in RFC5029, as that stated in https://tools.ietf.org/html/rfc5029#section-2, this sub-TLV is included in the TLV 22(Extended IS Reachability). 

As I read the IANA code point https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223, it notes this sub-TLV can be included in all of these TLVs (22,23,25,141,222,223). 

But, when the interface is configured as passive/stub, it seems that the above TLVs will not be advertised, because there is no IS neighbor on this passive link.  

TLV 141 “Inter-AS reachability information” seems be one appropriate TLV to include this sub-TLV, but it requires the IS-IS TE deployment, and is not suitable for describing the passive/stub link on edge router.

In summary, it seems put this attribute into the “Prefix Attribute Flags” sub-TLV which can be included in TLV 135,235,236 and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs) is more applicable?

Best Regards.

Aijun Wang

China Telecom

发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 tony.li@tony.li
发送时间: 2020年1月10日 12:00
收件人: Aijun Wang
抄送: Les Ginsberg; Robert Raszuk; lsr@ietf.org
主题: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi Aijun,

Thank you for your draft.

First off, a ‘passive interface’ is a particular user interface phrase used by one very particular vendor.  It’s not a particularly accurate description, either. For example, a ‘passive’ interface implies that it might

accept protocol packets, but would not be active and send things on that interface.  That might have been meaningful in the distance vector days, but we’re decades past that now. The ’stub link’ designation 

sounds more accurate.

But that’s just naming.

As to mechanism, it seems to me that we already have the mechanisms that you want. Specifically, RFC 5029 already gives us a way of capturing link attributes. It would seem to me that all you need is a code point from that registry and you’d be done.  I’d recommend you direct your draft in that direction.

Regards,

Tony

On Jan 9, 2020, at 6:22 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

Hi, Les, Robert and other experts within LSR:

We have submitted the draft that related to the passive interface attribute, please review it at   <https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00

If you are interested, we are also welcome you as the co-author to put forward it together.

Any comments are welcome.

Thanks in advance.

Best Regards.

Aijun Wang

China Telecom

发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 Aijun Wang
发送时间: 2020年1月7日 18:57
收件人: Robert Raszuk
抄送: Les Ginsberg (ginsberg); lsr@ietf.org
主题: Re: [Lsr] Methods to label the passive interfaces within ISIS

Hi, Robert:

There are situations that we want to distinguish the passive interfaces from the normal interfaces. I will try to write one draft in recent days to describe it and for further discussion.

Thanks in advance.

Aijun Wang

China Telecom

On Jan 7, 2020, at 18:14, Robert Raszuk < <mailto:robert@raszuk.net> robert@raszuk.net> wrote:

Hi Aijun,

Right .. I took your email as an attempt/request to actually advertise passive links in the first place. 

May we know what difference does it make to you if reachable prefix is part of an active vs passive interface from IGP point of view ? 

Thx,

R.

On Tue, Jan 7, 2020 at 2:08 AM Aijun Wang < <mailto:wangaijun@tsinghua.org.cn> wangaijun@tsinghua.org..cn> wrote:

Hi, Robert:

Thanks for your information.

TLV-22 is used to describe the IS neighbor and the link between them. As for the passive interfaces, there may be no neighbor. 

It seems the sub-TLV within this TLV is not the appropriate place to put this information?

P.S. I changed the thread to reflect the conversion topic.

Best Regards.

Aijun Wang

China Telecom

发件人:  <mailto:lsr-bounces@ietf.org> lsr-bounces@ietf.org [mailto: <mailto:lsr-bounces@ietf.org> lsr-bounces@ietf.org] 代表 Robert Raszuk
发送时间: 2020年1月6日 18:58
收件人: Aijun Wang
抄送: Les Ginsberg (ginsberg);  <mailto:lsr@ietf.org> lsr@ietf.org
主题: Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

Aijun,

We just want to distinguish the passive interfaces from other normal interfaces within ISIS domain.  It seems that the “Attribute Flags” that described in  <https://tools.ietf.org/html/rfc7794#section-2.1> https://tools.ietf.org/html/rfc7794#section-2.1 is the most appropriate place to extend to carry such information.

Really ?

IMO much better place is to define new sub-TLV of TLV-22 and mark it there as passive link.

Ref:  <https://tools.ietf.org/html/rfc5029> https://tools..ietf.org/html/rfc5029

Now more interesting perhaps is to find out how ISIS is supposed to react to such information. Or is the intention to carry it just as an opaque info say for show commands use only ? 

Thx,
R.

_______________________________________________
Lsr mailing list
 <mailto:Lsr@ietf.org> Lsr@ietf.org
 <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr