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

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 15 March 2021 08:05 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 B1D3A3A0CB0 for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 01:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 pnR9sWRDKsX0 for <idr@ietfa.amsl.com>; Mon, 15 Mar 2021 01:05:25 -0700 (PDT)
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 12D3F3A0CAE for <idr@ietf.org>; Mon, 15 Mar 2021 01:05:22 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id B17791C03F5; Mon, 15 Mar 2021 16:05:13 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Jakob Heitz \(jheitz\)'" <jheitz@cisco.com>, "'Brian Dickson'" <brian.peter.dickson@gmail.com>
Cc: "'IETF IDR'" <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> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <000501d71940$e9b87420$bd295c60$@tsinghua.org.cn> <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com>
Date: Mon, 15 Mar 2021 16:05:13 +0800
Message-ID: <002901d71971$ed947f90$c8bd7eb0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01D719B4.FBBAF3E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQNN+BKM7DZoc4nruS59P2v8seAnrAIrgVqYAtljO/UBWl/ZSQFcDFRBAk3UB4gBcOGVSwGIefmcpy7FhxA=
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSxhJTkhOH0pMHh8ZVkpNSk5MQk5OSk9LSUJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Nio6TSo6Tj8PMVY#NS0xLgE9 A0IKCQNVSlVKTUpOTEJOTkpOS0xCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUxLSklONwY+
X-HM-Tid: 0a7834eae9e7d993kuwsb17791c03f5
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qw9cc5ekUFGH7GUuphTYUHcOKAM>
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: Mon, 15 Mar 2021 08:05:30 -0000

Hi, Jakob:

 

I think your purpose is to define 256 WKLC, each can has its own Data1/Data2/Data3 definition to carry some additional information for the specified WKLC.

To accomplish this, you should reserve  4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) 4-bytes AS number, which can’t be allocated for the legitimate usage by operators.  

 

The reason to get such results is that you want to define the additional “Data 1” field from the  “Global Administrator”, but there is no description to explain the necessary.  Brian gave some potential examples in this thread and I think expanding them more clearly in your draft maybe more convincible.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Jakob Heitz (jheitz) <jheitz@cisco.com> 
Sent: Monday, March 15, 2021 1:29 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>cn>; 'Brian Dickson' <brian.peter.dickson@gmail.com>
Cc: 'IETF IDR' <idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)).  

 

[JH] Aijun. I'm glad you agree that there is still abundant space to allocate ASNs.

The reason to reserve space is explained in the introduction.

It is to prevent WKLCs from having the same Global Administrator field as a legitimate AS trying to distribute its LC.

 

Regards,

Jakob.

 

From: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > 
Sent: Sunday, March 14, 2021 7:14 PM
To: 'Brian Dickson' <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com> >
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> >; 'IETF IDR' <idr@ietf.org <mailto:idr@ietf.org> >
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

Hi, Brian:

 

Based on your intention, I think you should consider to redefine the encoding of LC, not only well-known LC.

Even for the redefinition of LC encoding, you should also state clearly the potential advantages.

 

More detail replies are inline below.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Brian Dickson <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com> > 
Sent: Saturday, March 13, 2021 2:14 AM
To: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> >; IETF IDR <idr@ietf.org <mailto:idr@ietf.org> >
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

 

 

 

On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> > wrote:

Hi, Jakob:

 

From: Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com> > 
Sent: Friday, March 12, 2021 3:45 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >
Cc: idr@ietf.org <mailto: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.

 

The range of reserved ASNs occupies two bits of the upper 8 bits, plus the entirety of the the next 24 bits in its range.

This represents a single value from the 6-bit portion of the ASN space, or exactly 1/64 of the 32-bit ASN space.

Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or about 1/1000.

This still leaves well over 31/32 of the potential ASN space, so I believe your worry is unjustified.

[WAJ] Yes, there are abundant range for the 32 bit ASN space, but my main point is that your draft doesn’t state the reason to reserve 1/64 32-bit ASN space(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF)).  

 

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.

 

The logic for this is as follows:

The initial use case is to establish a structured value of TBD1:TBD2:ASN for the route-leak-detection-mitigation (as that draft explains).

The TBD2 is a single value out of a 32-bit range which will be in its own (new) registry. Having a registry allows for future uses in the context of TBD1, allowing new kinds of LC's in this bigger registered range.

[WAJ] You should state also the reason that such sub-registry under one well-known LC.  Describe some examples may be helpful.  DO community is one example, but there still also no more explanation.

 

However, the router implementations, for the most part, permit filtering of LCs on the basis of 3 32-bit values, where either literal values or wildcards can be used.

Having the elements be aligned on the 32-bit boundary, and having TBD1 and TBD2 be fixed values, permits LC matching using a patterns of either TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).

In other words, this structure choice is forced by router implementations, and really not appropriate to second-guess. It isn't up for negotiation, as this is a necessary requirement for the first use case.

 

BTW: Both of these patterns (fixed single value and wild-card of lower 32-bit value) are required to implement the GROW draft you referenced.

 

Having said that, this is the first out of up to 255 WKLCs, and the maximum benefit to other potential uses for WKLC is achieved by making the maximum (reasonable) number of octets available for those other WKLCs, specifically 10 octets of undefined structure.

 

In particular, it is possible that other WKLCs require two ASN data values in their encoding (such as a source ASN and a destination ASN), and additional values (single bits or ranges of values) beyond that. Limiting the WKLC to having only single Global Administrator values and 8 octets of data, would be insufficient in that case.

 

This would require re-design of WKLCs at a later date, and it may not be possible due to existing usage or reservations of WKLCs.

 

By providing more octets to EACH WKLC, this problem is prevented. Making data allocations on power-of-two boundaries at the highest order is necessary up front. Attempting to expand ranges after allocations is possible, but may not be compatible with the power-of-two alignment required by future use cases of WKLC.

 

You cannot aggregate that which was not initially allocated in a fashion suitable for aggregation. This was one major outcome of the IP allocation strategies prior to CIDR addressing for IPv4 address space. We would do well to learn from the mistakes of others, particularly when those mistakes were effectively repeated in the ASN space already (16 bits to 32 bits, because the initial assumption was 16 bits would be sufficient).

[WAJ] If you want to accomplish this, I think you should propose to change the encoding of LC, not only the well-known LC.   And, the community is not used to packet forwarding, what’s the necessary to aggregate?

 

So, in summary, the reservation of the range of ASNs is specifically to permit applying structure to the LC values within that range. 

The original LC definition is only applicable to "actual" ASNs as Global Administrator. RFC8092 says only "intended", and that the value "SHOULD" be an ASN.

This is a new use case, and is the reason RFCs use "SHOULD" instead of "MUST".

(What RFC8092 really says is, LCs where the Global Administrator value corresponds to an actual assigned ASN, are reserved exclusively for the operator of that ASN.)

Since this proposal sets aside a range of ASNs as a group, the structure of LCs covering that range can be redefined accordingly, as long as that redefinition is scoped to that range of ASNs.

[WAJ] This is different from the structure of LC defined in RFC8092, in which only the Local part 1/local part 2 of one Global Administrator is operator-defined.

 

This is EXACTLY what this WKLC proposal is doing, and nothing more.

The other draft is for the use of the first assigned WKLC values (single ID plus the Transitive Bit values).

 

Hope this clarifies the usage and compatibility with other RFCs.

 

Brian

 

 

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.

 

_______________________________________________
Idr mailing list
Idr@ietf.org <mailto:Idr@ietf.org> 
https://www.ietf.org/mailman/listinfo/idr