Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 12 March 2021 08:31 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 E90A03A1025 for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 00:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 N-8RXKo4CdWq for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 00:30:59 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F8E3A1024 for <idr@ietf.org>; Fri, 12 Mar 2021 00:30:57 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 62E421C0242; Fri, 12 Mar 2021 16:30:52 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Jakob Heitz (jheitz)'" <jheitz@cisco.com>
Cc: idr@ietf.org
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com>
Date: Fri, 12 Mar 2021 16:30:52 +0800
Message-ID: <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0157_01D7175D.11912040"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQNN+BKM7DZoc4nruS59P2v8seAnrAIrgVqYAtljO/UBWl/ZSadfPmqQ
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSh9ISxoaTR0dGUoYVkpNSk5OSExDTklNT0pVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ogg6FRw5Tj8THwEYPh8xHiwN IjcwFEpVSlVKTUpOTkhMQ05ITUtPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUhITE5NNwY+
X-HM-Tid: 0a78258f5038d993kuws62e421c0242
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/EyLbccem233qxKfhff5U6B2UfR8>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Mar 2021 08:31:03 -0000

Hi, Jakob:

 

From: Jakob Heitz (jheitz) <jheitz@cisco.com> 
Sent: Friday, March 12, 2021 3:45 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: idr@ietf.org
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

1.      It is small, not huge as explained in the draft.

[WAJ] When compared to the 22 well-known community, “67,108,864 AS numbers” is too large.  I am worrying the unnecessary reservation may prevent the allocation of the unallocated AS-number for other purposes.

2. It got updated and I missed it when I updated my draft. Thanks for catching it.

3. I don't understand your question. Can you expand?

[WAJ] why not take the approach directly as that descried in  https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04. ?

That is to say, for each potential well-known large community, reserve one value for the “Global Administrator” part of the large community, and defined the associated data for the other two local parts. Transitive or non-transitive can be defined accordingly. 

Currently, you define “WKLC ID” as the large community type. From the definition of large community(RFC8092), the “Global Administrator” part will be divided into 256 groups, each group will have 2^16 number, that is 2^16 well-known large communities? 

I know you want to leave some field to the data part, but this arises some confusion when your proposed encoding is different from the original definition of RFC8092.

 

Regards,

Jakob.

 

From: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > 
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> >
Cc: idr@ietf.org <mailto:idr@ietf.org> 
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

Hi, Jakob:

 

More questions for your draft:

1.     Do we need to reserve such huge range(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) as you described in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-6 for the countable well-known large communities?
2.     There is some inaccurate description for the current reserved AS number space in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4.  You can check it at https://www.iana.org/assignments/as-numbers/as-numbers.xhtml. The unallocated AS range is 401309-4199999999, not at described in your draft “The range of AS numbers currently unallocated by IANA is 399,261 to 4,199,999,999.”
3.     What’s the necessary to group such WKLC via the WKLC ID? 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: idr-bounces@ietf.org <mailto:idr-bounces@ietf.org>  <idr-bounces@ietf.org <mailto:idr-bounces@ietf.org> > On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> >
Cc: idr@ietf.org <mailto:idr@ietf.org> 
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

Yes, if we reserve some 4-bytes AS range, then your concerns will not happen.

The well-known large community need just be allocated from this reserved range. That’s all.

Do we need other definitions in your draft then?

Aijun Wang

China Telecom

 

On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> > wrote:

 

Consider if there is a real AS that uses 4,093,640,704 as its ASN.

And if this AS were to send a large community of its own.

It would put its ASN into the Global Administrator field of the LC.

This ASN is 11110100000000000000000000000000 in binary.

Then another AS sends a WKLC with WKLC ID 0, Transitivity 0 and Data 1 = 0.

This has the same bit pattern.

To avoid the clash, we need to reserve the ASNs that would clash.

 

Regards,

Jakob.

 

From: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > 
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> >; 'Susan Hares' <shares@ndzh.com <mailto:shares@ndzh.com> >; idr@ietf.org <mailto:idr@ietf.org> 
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

And, what the reason to assign the “111101”value in the first 6bit your encoding? It is not conformed to general definition of large community, in which the first 4-bytes is to identify the Global Administrator.