Re: [Lsr] Methods to label the passive interfaces within ISIS
Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 13 January 2020 22:37 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 0A1D8120909 for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 14:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 KyONZUxagQaU for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 14:37:06 -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 728F412001B for <lsr@ietf.org>; Mon, 13 Jan 2020 14:37:04 -0800 (PST)
Received: from [240.0.0.1] (unknown [45.88.43.117]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 5CFD066120E; Tue, 14 Jan 2020 06:36:56 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-4CE1D671-2847-4D3D-B822-CB75024F993F"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 14 Jan 2020 06:36:52 +0800
Message-Id: <DD58CAA4-EB8A-4008-A96C-ED1FFE2FD5A8@tsinghua.org.cn>
References: <52685ed7-f7e8-4828-82b1-234f78a8fc39@Spark>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, Robert Raszuk <robert@raszuk.net>
In-Reply-To: <52685ed7-f7e8-4828-82b1-234f78a8fc39@Spark>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (17C54)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZSlVMQkxCQkJMSEJNT01CSllXWShZQU pMS0tKN1dZLVlBSVdZCQ4XHghZQVk1NCk2OjckKS43PlkG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MSI6KQw5Djg*SBMPFU0#TEg0 SDJPChRVSlVKTkxDQk5OS0lJSU9NVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlPTlVDQ1VPSFVKSkxZV1kIAVlBSkpMSko3Bg++
X-HM-Tid: 0a6fa10d88bf9373kuws5cfd066120e
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/jo2Ypk2pmM-zY_SYdeuln--qvKY>
Subject: Re: [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 22:37:11 -0000
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. OSPF has already the corresponding consideration and specifications, isn’t it reasonable for ISIS to have such capabilities also? 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
- Re: [Lsr] Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… Robert Raszuk
- [Lsr] 答复: Is it necessary to expand the IS-IS lev… Aijun Wang
- [Lsr] Methods to label the passive interfaces wit… Aijun Wang
- [Lsr] Is it necessary to expand the IS-IS level t… Aijun Wang
- Re: [Lsr] Is it necessary to expand the IS-IS lev… Les Ginsberg (ginsberg)
- [Lsr] 答复: Is it necessary to expand the IS-IS lev… Aijun Wang
- Re: [Lsr] 答复: Is it necessary to expand the IS-IS… Robert Raszuk
- Re: [Lsr] Is it necessary to expand the IS-IS lev… Les Ginsberg (ginsberg)
- [Lsr] 答复: Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… tony.li
- [Lsr] 答复: Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… tony.li
- Re: [Lsr] Methods to label the passive interfaces… Robert Raszuk
- Re: [Lsr] Methods to label the passive interfaces… tony.li
- [Lsr] 答复: Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… tony.li
- Re: [Lsr] Methods to label the passive interfaces… Acee Lindem (acee)
- Re: [Lsr] Methods to label the passive interfaces… Les Ginsberg (ginsberg)
- Re: [Lsr] Methods to label the passive interfaces… Jeff Tantsura
- Re: [Lsr] Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… Acee Lindem (acee)
- Re: [Lsr] Methods to label the passive interfaces… Aijun Wang
- Re: [Lsr] Methods to label the passive interfaces… Acee Lindem (acee)
- Re: [Lsr] Methods to label the passive interfaces… Aijun Wang