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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 1 Apr 2021 20:13:33 +0000

Brian,

>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 should have clarified. I am not opposed to staying on course with a WKLC based solution. I only thought transitivity readily came with Transitive Extended Community. Your proposal about one or a very small number of WKLC GA values seems fine and it is consistent with Sue’s advice.  Please see my next post (in this thread) which is about transitivity measurements of EC and LC that should be helpful in this discussion.

Sriram 
________________________________________
From: Brian Dickson <[email-masked]>
Sent: Wednesday, March 31, 2021 6:10 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Choice of Large vs. Extended Community for Route Leaks Solution

On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>> 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).

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

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

[Brian] 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.

[Brian] 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*.

[Brian] 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.

[Brian] 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.

[Brian] 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.

[Brian] 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