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

"Aijun Wang" <wangaijun@tsinghua.org.cn> Mon, 13 January 2020 08:39 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448C212008B for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 00:39:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZBZd-of4s82 for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 00:39:15 -0800 (PST)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF97120072 for <lsr@ietf.org>; Mon, 13 Jan 2020 00:39:13 -0800 (PST)
Received: from WangajPC (unknown [219.142.69.77]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id D759D6638FB; Mon, 13 Jan 2020 16:39:04 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: tony.li@tony.li
Cc: 'Les Ginsberg' <ginsberg@cisco.com>, 'Robert Raszuk' <robert@raszuk.net>, lsr@ietf.org
References: <CAOj+MMHAbGo+0qd+xwTmymx4MYXGWmHe0p+d2ychQLQWUZ78wA@mail.gmail.com> <FC0F3982-2182-4CFB-8D60-A702C72BB87F@tsinghua.org.cn> <006901d5c75c$c24ad360$46e07a20$@org.cn> <BCA056AC-76B2-45B6-9FD0-61A5EBFC740C@tony.li> <00bb01d5c785$483d91b0$d8b8b510$@org.cn> <32D6BF50-90F8-40C1-81B3-4DA6646F3F6E@tony.li>
In-Reply-To: <32D6BF50-90F8-40C1-81B3-4DA6646F3F6E@tony.li>
Date: Mon, 13 Jan 2020 16:39:05 +0800
Message-ID: <00eb01d5c9ec$ea8112d0$bf833870$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01D5CA2F.F8A452D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdXHh1SHwjOw+EhvRP2BsPEzoDZf6QCZG8VA
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VJS0xLS0tJTk5OQ09MSkxZV1koWU FKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZNTQpNjo3JCkuNz5ZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MCo6ARw6Ajg0AxM3KS0TTxxJ L0NPChZVSlVKTkxDQktPTE5KSU9MVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxMWVdZCAFZQUpOT0pINwY+
X-HM-Tid: 0a6f9e0e742e9373kuwsd759d6638fb
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_rUUgy5Fk20U86EivR5ROA-yvbE>
Subject: [Lsr] 答复: Methods to label the passive interfaces within ISIS
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 08:39:18 -0000

Hi, Tony:

 

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?

 

Best Regards.

 

Aijun Wang

China Telecom

 

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

 

 

Hi Aijun,

 

 

For the link attributes that defined in RFC5029, as that stated in  <https://tools.ietf.org/html/rfc5029#section-2> 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> 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.  

 

 

Fair point. Given that there is an IP address and prefix on that link, it would be very reasonable to advertise the Extended IP Reachability TLV (135). We would then need to make the link attributes sub-TLV applicable to this TLV (and it’s MT brother).

 





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?

 

 

It would seem to me that what you’re describing is an attribute of a link, not of a prefix, thus I would favor it remaining a link attribute.

 

But that’s just me.  :-)

 

Tony