Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-entropy-label-13
Mach Chen <mach.chen@huawei.com> Mon, 18 December 2023 01:41 UTC
Return-Path: <mach.chen@huawei.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064A8C14F5E0; Sun, 17 Dec 2023 17:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 DDH8Ct6YOICC; Sun, 17 Dec 2023 17:41:23 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6144CC14EB19; Sun, 17 Dec 2023 17:41:23 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4StjD70r41z67RYs; Mon, 18 Dec 2023 09:39:19 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 925281400CA; Mon, 18 Dec 2023 09:41:20 +0800 (CST)
Received: from dggpemm500004.china.huawei.com (7.185.36.219) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Dec 2023 01:41:19 +0000
Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500004.china.huawei.com (7.185.36.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 18 Dec 2023 09:41:17 +0800
Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2507.035; Mon, 18 Dec 2023 09:41:17 +0800
From: Mach Chen <mach.chen@huawei.com>
To: John Scudder <jgs@juniper.net>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-entropy-label.all@ietf.org" <draft-ietf-idr-entropy-label.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-idr-entropy-label-13
Thread-Index: AQHaLEfhROlHeaIdJkSP/ydnGeZEKbCk7eQAgAUKJ4CABFS2gA==
Date: Mon, 18 Dec 2023 01:41:17 +0000
Message-ID: <d6479a413fdf4c1d9c0ccbf4f3f87227@huawei.com>
References: <170227888120.50196.10725850950080040677@ietfa.amsl.com> <8B5A8C42-4BC4-47C5-BD6C-3A8520B1E036@juniper.net> <1f18beb5982d48ce88b9e6754c2d0d83@huawei.com> <A020DC01-A867-447D-A70C-63E85AE5E53A@juniper.net>
In-Reply-To: <A020DC01-A867-447D-A70C-63E85AE5E53A@juniper.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.110.46.250]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ltONL7sjYo_l8SmXsBMALcU6FCY>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-entropy-label-13
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2023 01:41:26 -0000
Hi John, Please see my replies inline below... > -----Original Message----- > From: John Scudder <jgs@juniper.net> > Sent: Friday, December 15, 2023 11:29 PM > To: Mach Chen <mach.chen@huawei.com> > Cc: rtg-dir@ietf.org; draft-ietf-idr-entropy-label.all@ietf.org; idr@ietf.org > Subject: Re: Rtgdir early review of draft-ietf-idr-entropy-label-13 > > Hi Mach, > > A few replies are below (edited for brevity). > > > On Dec 11, 2023, at 9:56 PM, Mach Chen <mach.chen@huawei.com> > wrote: > > > > Hi John, > > > > Thanks for your prompt response! > > > > Some replies inline... > > […] > > >>> Comments and Questions > >>> In Section 1 > >>> It says: > >>> "An NHC carried in a given BGP UPDATE message conveys information > >>> that relates to all Network Layer Reachability Information > >>> (NLRI)..." Does the NLRI include the MP_REACH_NLRI case? If so, how? > >>> If not, it's better to clarify this in the document. > >> > >> I don't understand this point. Surely, MP_REACH_NLRI is the dominant > >> way of advertising reachable NLRI in BGP updates, the only other way > >> is the legacy encoding for AFI/SAFI 1/1. So, I'm not sure what to clarify > here. > > I am thinking about that if the NHC can also apply to MP_REAH_NLRI, then > is the "match" checking process based on the NEXT_HOP attribute or the > Network Address of Next Hop of MP_REACH_NLRI? > > I see your point. At the same time, if we can avoid having this document get > into the business of defining exactly what a "next hop" means for a BGP > route, I think that would be better. The Section 1 text we are currently > discussing is only descriptive, not normative, here is what Section 2.3 has as > the normative text: "When a BGP speaker receives a BGP route that includes > the NHC, it MUST compare the address given in the header portion of the > NHC and illustrated in Figure 1 to the next hop of the BGP route.” Oh, that's intended to be written like this, I am OK with it. > > […] > > >>> In Section 3.3, > >>> OLD: > >>> "When a BGP speaker receives a labeled route that includes the > >>> ELCv3, it indicates the associated LSP supports entropy labels." > >>> NEW: "When a BGP speaker receives a labeled route that includes the > >>> ELCv3, it indicates the egress LSR of associated LSP supports entropy > labels." > >> > >> I think this isn't quite right, because of the midpoint case covered > >> in "Is re-advertising a BGP route it received with a valid ELCv3 > >> capability, and is changing the next hop that it has received to N, > >> and knows (for example, through configuration) that the new next hop > >> (normally itself) even if not EL-capable will simply swap labels > >> without popping the BGP-advertised label stack and processing the label > below, as with a transit LSR”. > > > > But what does it mean that an LSP supports entropy labels? Maybe we > could change the way of expressing, for example: > > "When a BGP speaker receives a labeled route that includes the ELCv3, it > indicates that it can safely insert an entropy label into the label stack of the > associated LSP. > > I think that's good, I've made the change in my working copy. OK Now, all my comments are addressed! Thanks, Mach > > Thanks, > > --John
- [RTG-DIR] Rtgdir early review of draft-ietf-idr-e… Mach Chen via Datatracker
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-i… John Scudder
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-i… Mach Chen
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-i… John Scudder
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-i… Mach Chen