Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 21 June 2022 23:20 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368FC14CF1A for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 16:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzvHVz9Tic0p for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 16:20:45 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7029EC14CF14 for <idr@ietf.org>; Tue, 21 Jun 2022 16:20:42 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.97.163]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id A40201C00F0; Wed, 22 Jun 2022 07:20:39 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-6AE2F47F-B4CF-4FE7-A765-79D9CF0F19C7"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 22 Jun 2022 07:20:38 +0800
Message-Id: <5B5BC7AC-9B56-4497-8572-C6FCA95803C5@tsinghua.org.cn>
References: <BY5PR11MB4337C1704EE6D3A9F889798CC1B39@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Sue Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <BY5PR11MB4337C1704EE6D3A9F889798CC1B39@BY5PR11MB4337.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (19F77)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZSEpIVkxMTh8ZQklNSUJNHVUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVQkxVSk1IWVdZFhoPEhUdFFlBWU9LSFVKSktITk9VS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Nww6KDo6IT09MUMUCkMcLgEf MTUwCRZVSlVKTU5OQ05ITU9LSkpPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUJMVUpNSFlXWQgBWUFJSU5ITDcG
X-HM-Tid: 0a81889167fad993kuwsa40201c00f0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DsX4F_o0qyEX5xPQlqLZAlexqBk>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2022 23:20:49 -0000

Hi, 

Before starting such discussion, should someone write one draft first to summarize their through thoughts on the points that listed by Jeff? Or else, the discussion will end in nothing.
I think the reason that why the adoption call this draft incur such wider discussions for the future/fate of BGP-LS is the following:

If this draft can be accepted, is there any other LSR extensions cannot be put into BGP-LS?

There is no application scenarios description for the extension in the draft, no impediment deployments for the corresponding LSR solution.


Aijun Wang
China Telecom

> On Jun 22, 2022, at 07:00, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> Jeff –
>  
> Let me first say – with a tip of my cap to you – that I very rarely find anything objectionable in any of your posts.
>  
> But, this case is an exception. 😊
>  
> WG meeting time is an extremely limited resource and there are many more substantive and interesting topics that would benefit from a live discussion. Please do not consume this limited resource on such a mundane topic.
> If folks are interested in commenting on the points you make below, I think the mailing list is both appropriate and sufficient.
>  
> If someone wants to present an alternative to BGP-LS, I certainly think that could merit a live presentation slot – though I hasten to add that I am not interested in a summary of BGP-LS shortcomings. Those are well known.
> If someone actually has an alternative proposal with some detail – that would be interesting.
>  
> Thanx.
>  
>     Les
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 21, 2022 3:20 PM
> To: Sue Hares <shares@ndzh.com>
> Cc: idr@ietf.org
> Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
>  
> Sue,
>  
> I'd suggest one of the IETF session discussions should be "how to optimize the path from LSR feature to BGP-LS encoding".
>  
> While BGP-LS has a number of sins I'm not terribly fond of, it has a number of good properties as well.
>  
> This conversation, and similar ones, is partially around how do we deal with new LSR features and not add a lot of overhead to the process of getting a BGP-LS encoding for them.  A small number of items related to this:
>  
> - Is the encoding identical between IS-IS and OSPF?
> - Are the code points common between those two protocols and could that be leveraged for BGP-LS?
> - What encodings in IS-IS and OSPF are inappropriate to carry in BGP-LS, if any?
>  
> While I'm not an active participant in LSR, my observations over recent years since the two technologies were merged into the new LSR WG have been that more cooperation to avoid doing the work twice has been beneficial.  I suspect there's room to do the work well so it doesn't have to be done twice: LSR and BGP-LS.
>  
> -- Jeff
>  
> 
> 
> On Jun 21, 2022, at 5:48 PM, Susan Hares <shares@ndzh.com> wrote:
>  
> [IDR Chair hat on]
>  
> There are three streams of discussion:
>  
> 1. Whether we should consider alternatives to BGP-LS for BGP [Robert Raszuk, Tony P. , and others)
> 2.  Whether operators will deploy this addition to BGP-LS  (Operators should/will not (Aijun and Gert), Customers requesting (Tony P))
> 3.  Comments on the document (Ketan, Acee).
>  
> On #1:
> For the alternative to BGP-LS,  I welcome short presentations for IETF-114.   
> IDR will probably only get 1 time slot at IETF.  If IDR WG chairs receive multiple
> Presentations requests,  I’ll host an interim on the topic.
>  
> On #2, I ask that operators let me know if they are awaiting this addition.
> On #3, I’m going to let the conversation between Ketan and the Jordan go a few more days.
>  
> I’ll close this call on 6/24.
>  
> Cheers, Sue
>  
>  
> From: Acee Lindem (acee) <acee@cisco.com> 
> Sent: Tuesday, June 7, 2022 8:32 AM
> To: Susan Hares <shares@ndzh.com>; idr@ietf.org
> Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
>  
>  
>  
> I support WG adoption – the corresponding LSR draft has completed WG last call and is awaiting AD review.
>  
> Thanks,
> Acee
>  
> From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
> Date: Monday, June 6, 2022 at 5:28 PM
> To: IDR List <idr@ietf.org>
> Subject: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
>  
> This begins a 2 week WG adoption call for draft-head-idr-bgp-ls-isis-fr-01.txt
>  
> https://datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/
>  
>   This document defines one new BGP-LS (BGP Link-State) TLV for
>    Flood Reflection to match the ISIS TLV for flood reduction.
>  
>    The draft is short (5 total pages). 
>  
> Since this BGP-LS feature has been adopted by IS-IS,
> Please consider
>  
> 1.       Is there any technical difficulty with adding this to the BGP-LS code points?
> 2.   Is this draft ready for publication?
> 3.   Does this addition help operational networks.
>  
> Cheers, Sue Hares
>  
>  
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr