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

Brian and co-authors: 

As I typed my response to Brian’s questions, I found it was turning into a copy of my chair’s response to the WG adoption call.   Therefore, I have just included my review as the shepherd to Brian’s request. 

Cheers, Sue 

<WG chair hat on> 

Summary: 

There is no consensus on adoption this draft in its current form.   The IDR co-chairs remain committed to the route-leak mitigation work and large communities. 

<WG chair hat on> 

Would 255 ASNs instead of  original request:

Even requesting 255 ASNs needs substantial justification.  For the route leaks, we  anticipated 2-8 would be sufficient.  As you recall when we started this approach,  I talked with Alvaro (our AD) and IANA to determine if IDR could request these special ASNs. 

However, asking for 255 ASNs you would need: 

a) a draft indicating the request for the ASNs, 

b) support of the draft from grow (WG adoption, WG LC) 

c) support of the draft from IDR (WG adoption, WG LC) 

255 ASNs should be vetted IDR, grow, and operator community.  If you go this way, I would suggest the Grow chairs also ask the *NOGs (NANOG, RIPE, JANOG..) if allocating 255 ASNs is ok. 

Route leaks: 

As you indicated, the route-leaks needs a small amount of ASNs.  As you recall from our discussion the IDR chairs at the time (John Scudder and myself) felt would could use the drafts in IDR and Grow to push for 2-4 special purpose ASNs.   My current co-chairs agree to support this initial allocation. 

Large community changes: 

I quietly listened to the WG adoption call on this draft because it mattered what the ISPs and implementers said.  The Large communities (RFC8092) had overwhelming support from the operation community for 12 octet value with simple encoding.  

The RFC8092 encoding does not have support for transitive nature because the operator community wished to have a simple encoding.  After placing the WG LC during IETF and immediately after I did not hear an outcry from the operations community to change the simple nature of Large communities.  

Well know community registry: 

The original large community (RFC8092) creation did not take the time to create a “well-known community” registry.  My reading of the community effort that time was a “well-known community” registry was acceptable to the community, but not at the cost of slowing down deployment of large communities.  The hard work of getting consensus on the size and range for large communities needs to happen prior to asking IANA to create the registry. 

Possible next steps: 

1. Break the -4 ASNs away from the draft and append the request to existing grow drafts.   Section 6 of (draft-grow-route-leak-detection-mitigation-04.txt) could request specific ASNs.  

2.  Working with IDR/Grow to create a well-known Large Community registry discussing whether well-known community are just values registered or a range.   

3.  Work to get 255 ASNs approved through IDR/GROW

4.  Use a BGP attribute to solve the transitivity. 

The authors can contact the idr co-chairs as a group or grab one of the IDR co-chairs for a chat.   The IDR co-chairs meet weekly.   Let us know what we can do to help you. 

 <WG co-chair hat off> 

<WG participant hat on> 

In my personal opinion, GROW is a good place to discuss the large community registry as operations people know the requirements for the size of registry.   

Cheers, Sue 

From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] 
Sent: Friday, March 26, 2021 3:42 PM
To: Susan Hares
Cc: Aijun Wang; IETF IDR
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

On Fri, Mar 26, 2021 at 12:18 PM Susan Hares <shares@ndzh.com> wrote:

Brian: 

<WG chair hat on> 

This brief justification for the ASN space even for 4-byte AS is not sufficient.   A separate draft will need to specify why so much ASN space that is managed by IANA. 

In the original work with route-leaks, John Scudder and I agreed to help the route-leaks folks obtain 2-8 ASNs specifically for the route leaks.  Modifying your grow draft will obtain approval for a small amount of special ASNs.   I have discussed your need with IANA so that we had a sense of whether it would be approved. 

Asking for 1/64 of the address space requires substantial justification as it significantly limits the future uses of 4 byte-AS.    

The IDR WG allotted private ASN space for uses within an AS (or a Confederation AS) that spans multiple uses.   If you can make use of this space + 2-8 AS, your proposal can go forward.  If not, a separate proposal will be needed to justify that amount of address space. 

Would a request for reserving 255 ASNs for WKLC and establishing an WKLC registry (which would maintain parity with the original WKC reservation) be a reasonable compromise?
Our GROW draft would then request something on the order of 2-4 of those values for the needs of the route-leaks draft.

Thanks for your consideration.

Brian

(The only hats I wear are the ones to keep the sun out of my eyes and off my head. :-) )

Thank you for being clear in this discussion with Aijun. 

Sue 

<WG Chair hat off> 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Friday, March 12, 2021 1:14 PM
To: Aijun Wang
Cc: IETF IDR
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> wrote:

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.

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.

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.

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).

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.

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> 
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr@ietf.org
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

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