Return-Path: X-Original-To: idr@mail2.ietf.org Delivered-To: idr@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0A77CAE05E01; Tue, 27 Jan 2026 17:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBBVk8OYdvXz; Tue, 27 Jan 2026 17:11:07 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 70D80AE05DF8; Tue, 27 Jan 2026 17:11:07 -0800 (PST) Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4f142X2njgzJ467F; Wed, 28 Jan 2026 09:10:28 +0800 (CST) Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id ECD6D40570; Wed, 28 Jan 2026 09:11:04 +0800 (CST) Received: from dggpemf200008.china.huawei.com (7.185.36.39) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 28 Jan 2026 09:11:03 +0800 Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf200008.china.huawei.com (7.185.36.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 28 Jan 2026 09:11:03 +0800 Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.036; Wed, 28 Jan 2026 09:11:02 +0800 From: "Dongjie (Jimmy)" To: 'idr' Thread-Topic: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-derived-community (December 11, 2025 to January 5, 2026) Thread-Index: AQHcbgg4L9H/uCPBSUGg1dSznPwKa7VK4s4wgBwmeJA= Date: Wed, 28 Jan 2026 01:11:02 +0000 Message-ID: References: <834bfae9b2854393a028459f9a8601fb@huawei.com> <004701dc6da7$1593dc50$40bb94f0$@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.122] Content-Type: multipart/alternative; boundary="_000_ae264e0030f64b9aa93bfa51042a7de7huaweicom_" MIME-Version: 1.0 Message-ID-Hash: 674B6FQAMUB77RYTC46DH32MUTZCJF6U X-Message-ID-Hash: 674B6FQAMUB77RYTC46DH32MUTZCJF6U X-MailFrom: jie.dong@huawei.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: 'idr-chairs' , "Zhang, Zhaohui" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_WG_last_call_and_IPR_call_for_draft-ietf-idr-rt-de?= =?utf-8?q?rived-community_=28December_11=2C_2025_to_January_5=2C_2026=29?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_ae264e0030f64b9aa93bfa51042a7de7huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The WG LC for draft-ietf-idr-rt-derived-community is closed. After the disc= ussion among the document shepherd and the IDR chairs, the conclusion is th= is document passed the WG LC. The authors should provide a new revision to = address the comments received during this last call. All the authors have replied to the IPR call. Since this document mainly introduces a new sub-type/type value for a serie= s of extended communities, and its usage will be specified in the documents= of specific use cases, it is considered implementation report for this doc= ument is not needed. Once an update version of this document is provided, the document shepherd = will update the shepherd report and work with the chairs on the publication= request. Best regards, Jie From: Dongjie (Jimmy) Sent: Saturday, January 10, 2026 11:21 AM To: Zhang, Zhaohui ; slitkows.ietf@gmail.com; 'idr' = Cc: 'idr-chairs' Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-deri= ved-community (December 11, 2025 to January 5, 2026) Dear all, The IDR chairs have received limited comments on the WG LC for draft-ietf-i= dr-rt-derived-community in the WG LC call. See the call at: https://mailarc= hive.ietf.org/arch/msg/idr/_51JdiKO37tSfBjkVHd3UXOIHFc/ After reviewing the draft and the comments, the IDR chairs and shepherd fee= l this draft is ready for publication. However, due to the holiday period, = the WG LC for draft-ietf-idr-rt-derived-community is extended on 1/16/2026. Please comment quickly if you do not think this draft is ready for publicat= ion. Best regards, Jie (as document shepherd) From: Zhang, Zhaohui > Sent: Tuesday, December 16, 2025 5:17 AM To: slitkows.ietf@gmail.com; Dongjie (Jimmy= ) >; 'idr' > Cc: 'idr-chairs' > Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-deri= ved-community (December 11, 2025 to January 5, 2026) Hi Stephane, Thanks for your review and comments. I've made some changes in my local sou= rce file. Please see zzh> below. From: slitkows.ietf@gmail.com > Sent: Monday, December 15, 2025 4:42 AM To: 'Dongjie (Jimmy)' >; 'i= dr' > Cc: 'idr-chairs' > Subject: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-derived-= community (December 11, 2025 to January 5, 2026) HI Jie, Few comments: Section 3: * Two typos: s/Subt-Types/Sub-Types/g Zzh> Thanks! Fixed. Section 4: * The fact that we consider the type being the first byte for most of t= he ext comms expect for IPv6 ones where we consider the two first bytes is = really confusing (subtype is within type). I know that it's following how i= t's defined at IANA, but this is really creating confusion while RFC5701 st= ill needs "subtype" field properly. Maybe at least for the example given ab= out Type 0x0011, we could mention that we talk about sub-type 0x11 used for= RT vs the general 0x02. Otherwise, we try to compare things that are not d= irectly comparable. * "When a new type is defined and registered, the corresponding...", it= 's not clear what we are talking about, I guess we talk about new types of = RT derived EC. The entire paragraph does not sound super clear to me. Can w= e simplify ? Previous paragraph says that we cannot guarantee subtype 0x02 = for any new RT created, then we can say that similarly we cannot guarantee = that new RT derived ECs, will get sub-type 0x15. BTW, wouldn't it be someth= ing we would like to enforce to simplify operation/understanding ? (so sub-= type 0x02 is always RT, 0x15 always for RT-derived EC) Zzh> Indeed, it would be nice if we could enforce 0x02 for RT and 0x15 for = RT-derived, but my understanding is that we can't - I'll defer this to the = IDR experts. Zzh> I deleted the entire paragraph and added some texts to the previous an= d next paragraph to address the two comments: While it may be desired to follow the unwritten convention and assign sub-type 0x02 for future Route Targets of future types of ECs, there is no guarantee of that. For example, Type 0x0011 (which can be interpreted as with a sub-type 0x11) is assigned for UUID-based Route Target that imposes as an IPv6 Address Specific EC (even though UUID is not an IPv6 address). When a new type of extended community is defined and registered, and a sub-type under this new type is registered for Route Target purposes, it is suggested to also register a sub-type for derivation purposes, preferably with the same value 0x15. However, there is no guarantee of that either. Section 6 (Security): I agree that this document is not defining how these ECs are used, however,= as they could potentially influence some indirect behaviors (not defined i= n this document), it should be good to mention that user should pay attenti= on to stripping unintended received ECs from external peers. Zzh> How about adding a sentence to the paragraph? ... Any potential security concerns need be addressed by documents that specify the actual usage. Additionally, in general one should pay attention to stripping unintended received ECs from external peers. Thanks! Jeffrey From: Dongjie (Jimmy) > Sent: Thursday, December 11, 2025 2:35 AM To: idr > Cc: idr-chairs > Subject: [Idr] WG last call and IPR call for draft-ietf-idr-rt-derived-comm= unity (December 11, 2025 to January 5, 2026) This begins the working group last call for the draft on "Extended Communit= ies Derived from Route Targets": https://datatracker.ietf.org/doc/draft-iet= f-idr-rt-derived-community/ Due to the holiday season in the end of the year, this last call ends on Ja= nuary 5th, 2026 so as to give the working group time to review and comment. For purposes of the shepherd's report and according to IETF BCP 78/79, the = authors are requested to declare whether they are aware of any undisclosed = IPR covering this draft. Members of the working group are similarly obligat= ed to report any IPR they are aware of as well. Best regards, Jie (as WG secretary & document shepherd) --_000_ae264e0030f64b9aa93bfa51042a7de7huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The WG LC for draft-ietf-idr-rt-derived-community is close= d. After the discussion among the document shepherd and the IDR chairs, the= conclusion is this document passed the WG LC. The authors should provide a new revision to address the comments r= eceived during this last call.

 

All the authors have replied to the IPR call.

 

Since this document mainly introduces a new sub-type/type = value for a series of extended communities, and its usage will be specified= in the documents of specific use cases, it is considered implementation report for this document is not needed.

 

Once an update version of this document is provided, the d= ocument shepherd will update the shepherd report and work with the chairs o= n the publication request.

 

Best regards,

Jie

 

From: = Dongjie (Jimmy) <jie.dong=3D40huawei.com@dmarc.ietf.org>
Sent: Saturday, January 10, 2026 11:21 AM
To: Zhang, Zhaohui <zhaohui.zhang@hpe.com>; slitkows.ietf@gmai= l.com; 'idr' <idr@ietf.org>
Cc: 'idr-chairs' <idr-chairs@ietf.org>
Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-= rt-derived-community (December 11, 2025 to January 5, 2026)

 

Dear all,

 

The IDR chairs have received limited comments on the WG LC= for draft-ietf-idr-rt-derived-community in the WG LC call. See the call at= : https://mailarchive.i= etf.org/arch/msg/idr/_51JdiKO37tSfBjkVHd3UXOIHFc/

 

After reviewing the draft and the comments, the IDR chairs= and shepherd feel this draft is ready for publication. However, due to the= holiday period, the WG LC for draft-ietf-idr-rt-derived-community is extended on 1/16/2026.

 

Please comment quickly if you do not think this draft is r= eady for publication.

 

Best regards,

Jie (as document shepherd)

 

From: = Zhang, Zhaohui <zhaohui.zhang@h= pe.com>
Sent: Tuesday, December 16, 2025 5:17 AM
To: slitkows.ietf@gmail.c= om; Dongjie (Jimmy) <jie.dong= @huawei.com>; 'idr' <idr@ietf.org= >
Cc: 'idr-chairs' <idr-chai= rs@ietf.org>
Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-= rt-derived-community (December 11, 2025 to January 5, 2026)

 

Hi Stephane,

 

Thanks for your review and comments. I’ve made some cha= nges in my local source file.

 

Please see zzh> below.

 

From: slitkows.ietf@gmail.com <= slitkows.ietf@gmail.com>
Sent: Monday, December 15, 2025 4:42 AM
To: 'Dongjie (Jimmy)' <jie= .dong@huawei.com>; 'idr' <idr@iet= f.org>
Cc: 'idr-chairs' <idr-chai= rs@ietf.org>
Subject: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-d= erived-community (December 11, 2025 to January 5, 2026)

 

HI Jie,

 

Few comments:

 

Section 3:

  • Two= typos: s/Subt-Types/Sub-Types/g

 

Zzh> Thanks! Fixed.


Section 4:

  • The= fact that we consider the type being the first byte for most of the ext co= mms expect for IPv6 ones where we consider the two first bytes is really confusing (subtype is within type). I know t= hat it’s following how it’s defined at IANA, but this is really= creating confusion while RFC5701 still needs “subtype” field p= roperly. Maybe at least for the example given about Type 0x0011, we could mention that we talk about sub-type 0x11 used for RT vs t= he general 0x02. Otherwise, we try to compare things that are not directly = comparable.

 

  • = 220;When a new type is defined and registered, the corresponding…R= 21;, it’s not clear what we are talking about, I guess we talk about new types of RT derived EC. The entire paragraph does not sound= super clear to me. Can we simplify ? Previous paragraph says that we canno= t guarantee subtype 0x02 for any new RT created, then we can say that simil= arly we cannot guarantee that new RT derived ECs, will get sub-type 0x15. BTW, wouldn’t it be somethin= g we would like to enforce to simplify operation/understanding ? (so sub-ty= pe 0x02 is always RT, 0x15 always for RT-derived EC)
    • =

 

Zzh> Indeed, it would be = nice if we could enforce 0x02 for RT and 0x15 for RT-derived, but my unders= tanding is that we can’t – I’ll defer this to the IDR experts.

Zzh> I deleted the entire= paragraph and added some texts to the previous and next paragraph to addre= ss the two comments:

 

   While it may be desired to follow the unw= ritten convention and assign

   sub-type 0x02 for future Route Targets of= future types of ECs, there

   is no guarantee of that.  For exampl= e, Type 0x0011 (which can be

   interpreted as with a sub-type = 0x11) is assigned for UUID-based Route

   Target that imposes as an IPv6 Address Sp= ecific EC (even though UUID

   is not an IPv6 address).

 

   When a new type of extended community is = defined and registered, and

   a sub-type under this new type is registe= red for Route Target

   purposes, it is suggested to also registe= r a sub-type for derivation

   purposes, preferably with the same value = 0x15.  However, there is no

   =             &nb= sp; guarantee of that either.

 

Section 6 (Security):

I agree that this document is not defining how these ECs are = used, however, as they could potentially influence some indirect behaviors = (not defined in this document), it should be good to mention that user should pay attention to stripping unintended = received ECs from external peers.

 

Zzh> How about adding a sentence to the paragraph?

 

   … Any potential security concerns need

   be addressed by documents that specify the actua= l usage.

   Additionally, in general one should pay attention= to stripping

   unintended received ECs from external = peers.

 

Thanks!

Jeffrey

 

From: = Dongjie (Jimmy) <jie.dong=3D40huawei.com@dmarc.ietf.org>
Sent: Thursday, December 11, 2025 2:35 AM
To: idr <idr@ietf.org>
Cc: idr-chairs <idr-chairs= @ietf.org>
Subject: [Idr] WG last call and IPR call for draft-ietf-idr-rt-deriv= ed-community (December 11, 2025 to January 5, 2026)

 

This begins the working group l= ast call for the draft on “Extended Communities Derived from Route = Targets”: https://datatracker.ietf.org/doc/draft-ietf-idr-rt-derived-community/

 

Due to the holiday season in th= e end of the year, this last call ends on January 5th, 2026 so a= s to give the working group time to review and comment.

 

For purposes of the shepherd's = report and according to IETF BCP 78/79, the authors are requested to declar= e whether they are aware of any undisclosed IPR covering this draft. Member= s of the working group are similarly obligated to report any IPR they are aware of as well.

 

Best regards,=

Jie (as WG secretary & docu= ment shepherd)

 

--_000_ae264e0030f64b9aa93bfa51042a7de7huaweicom_--