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

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 13 January 2020 23:35 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 0CA00120020 for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 15:35:06 -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 cuUucXKDPKmI for <lsr@ietfa.amsl.com>; Mon, 13 Jan 2020 15:35:00 -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 A9EA612001B for <lsr@ietf.org>; Mon, 13 Jan 2020 15:34:58 -0800 (PST)
Received: from [240.0.0.1] (unknown [45.88.43.117]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id A4753661E27; Tue, 14 Jan 2020 07:34:49 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-E12C2098-FB83-415B-8BC9-A551BB0C0C3A"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 14 Jan 2020 07:34:46 +0800
Message-Id: <71D49830-B207-403E-BAF2-B74A7D4E03EC@tsinghua.org.cn>
References: <2775D10C-CBD1-44EB-BBD8-8A3DD93AD5E9@cisco.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>, Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
In-Reply-To: <2775D10C-CBD1-44EB-BBD8-8A3DD93AD5E9@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: iPhone Mail (17C54)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZSlVNSEhCQkJCT0hMSEhJSVlXWShZQU pMS0tKN1dZLVlBSVdZCQ4XHghZQVk1NCk2OjckKS43PlkG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6M0k6HAw4KDgzSBMXSSsZAhoN HDcwChRVSlVKTkxDQk5DT0JNS05DVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlPTlVDQ1VPSFVKSkxZV1kIAVlBSUhOSko3Bg++
X-HM-Tid: 0a6fa142884c9373kuwsa4753661e27
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Za4tn7Knv7uI205fWLYjLmXHeKY>
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 23:35:06 -0000

Hi, Acee:
Actually, currently it arises from the inter-AS topology management needs. It is not sufficient for BGP-LS to report only the interior connections information.
To report the edge connection information, the router within the IGP domain that run BGP-LS needs first to distinguish the stub link from the normal link.
There maybe exists other usages for this information, we will add them if we get it. Also welcome more examples/solutions from interested LSR experts.


Aijun Wang
China Telecom

> On Jan 14, 2020, at 07:06, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> 
> Hi Aijun,
>  
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Date: Monday, January 13, 2020 at 5:48 PM
> To: Acee Lindem <acee@cisco.com>
> Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Tony Li <tony.li@tony.li>, Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
> 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) <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