[Note, commenting as an individual contributor...] On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote: > On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) < > kotikalapudi.sri...@nist.gov> wrote: > > 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 issue being faced here for WKLC is a few related items: - There needs to be some number of global admin (AS) reserved for generic use. - Since this was not done at the time the feature was shipped, there is no support in anyone's code to treat subsequently allocated ranges as "special". The two larger criticisms of the WKLC draft to date is that it wanted a LOT of the AS space to be used, and that its transitivity functionality would not fit well into an incremental deployment of the feature. If the transitivity requirements are removed and the space is narrowed, that at least moves it closer to existing community operational practices. E.g. a single AS allocated for the purpose that leaves two unstructured fields, or a small number of ASes. This then would require implementations that want to treat the new well-known fields as "special" to have code to do so. So, we're already looking at some level of new code. Absent that new code, what we have is generic policy, along with the implementation's normal propagation behavior - which is behind a knob for some implementations. > 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*. If the state can fit into an extended community, that similarly can be done NOW. A significant portion of the extended community space is available on first-come, first-serve basis. https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml But it doesn't change the above issues. > 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. I question your conclusion. The desire is to have an attribute that is used for route leak mitigation purposes. This thread illustrates that it's very easy for such a control community in any flavor (regular, extended, large) to be stripped because the service provider hasn't proactively acted to permit it. Does this really solve the problem? -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
