[Idr] Choice of Large vs. Extended Community for Route Leaks Solution

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Sue,

Thanks for the detailed thoughts you have shared on the IDR list about the WKLC draft and route leaks solution draft (while also responding to Brian’s post).

At one point in the past, the route leaks solution needed 8 bytes of user data space to accommodate two ASNs but then there was a design change (more than a year ago) and the current draft [1] requires only 4 bytes of user data space (one ASN). So, it seems possible to use a Transitive Extended Community instead of WKLC.

We (authors of the WKLC draft) can continue working on creating an IANA WKLC registry for the future but I think the route leaks solution draft can switch to using Transitive Extended Community. Especially, if that could help expedite the route leaks draft and its deployment? I would like to seek advice regarding that (I'm cc'ing GROW also here). 

One question is… even after IANA allocation of a Transitive Extended Community for route leaks, there may still be additional effort needed to get the operators to truly treat the EC as *transitive* so that it propagates at least a few hops. How do we accomplish that? Write a BCP in GROW strongly recommending operators to implement default policy to ensure transitivity? We would like to hear people's thoughts about that? 

Thank you.

Sriram            

[1] Route leaks solution draft (in GROW): https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-04 

---------------------------------------------------------------------------------------

Susan Hares <[e-mail]> Fri, 26 March 2021 21:28 UTCShow header
Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23) - no consensus for adoption

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