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

[Brian Dickson <[e-mail]>]

On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
[e-mail]> wrote:

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


Sorry to argue in public, but I disagree very strongly on the second part
here.

We would like to continue proceeding with use of a LC range for
implementation, using a single (or small number) of Global Administrator
values.

I think we should request that a small block of GAs surrounding the initial
assignments be tentatively marked something like Reserved for IANA
assignment.
That is different from actually establishing a registry or assigning them
specifically for WKLCs, but would be compatible with subsequent WKLC work.

The move to using LC values was precipitated by the observation that the
path for getting attributes deployed would be very long, and that operators
(actual network operators) are looking for a solution which can be deployed
*now*.

Nothing has changed in this regard; the WKLC draft is IMHO still the right
path, and only the size of the initial allocation is problematic.

Having 1-4 GA values (from the 32-bit range of potential values) is not
burdensome IMNSHO, and is a lot less of a concern than the 1/64 (or 1/16)
of the range of 32-bit ASNs originally requested/suggested.

If we can all agree that 1-4 GA values assigned for this is acceptable, I
suggest a revised version of the draft and assessment of consensus on the
revised draft for adoption and last call.

LC is the ONLY viable path, given the nebulous state of implementation and
use for EC/WC or attributes. LC is already deployed, and assigning a few
GAs by IDR is the only roadblock to the draft in GROW getting approved.

Brian


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