Subject: [Idr] Moving forward with draft-ietf-idr-bgp-ext-com-registry ExtCommunity Registry Cleanup

From: Christoph Loibl <[email-masked]>
Date: Wed, 3 Feb 2021 11:25:19 +0100

Hi,

The state of draft-ietf-idr-bgp-ext-com-registry is unchanged since WG adoption. Are there any objections to move forward?

During WG adoption John Scudder noted that the suggested change of the registration procedure of the "BGP Transitive Extended Community Types" 0x80, 0x81, 0x82 from Experimental to FCFS may have issues, if there are any experimental implementations already using code points from this space [1]. 

There was a lot of feedback during WG adoption to John’s comment but no one actually responded with an example of such an experimental implementation using CP 0x80, 0x81, 0x82 nor do I remember any objections to the change. Is it save to assume that the suggested change to the registration procedure should remain in the draft?

I want to point out that these code-points have actual non experimental implementations in shipping products of all larger vendors. I think it has an advantage to “protect” these CPs from future experimental use.

Cheers Christoph

[1] https://mailarchive.ietf.org/arch/msg/idr/W7ykrmr3CqHOUU9vQotr5Cly8rQ/

> John Scudder <[email-masked]> Mon, 29 June 2020 19:25 UTC

> I will note that it would be possible to carve out just the three mis-assigned code points without changing the registration procedures for the entire registry, i.e. we could leave the Experimental ranges as experimental, save for those three code points. However, as most of you know I’m not a big fan of Experimental for BGP protocol allocations, it doesn’t seem to be worth much, so I’m just as happy to see the change made. In any case, the WG should adopt the draft either way, since no matter what, the three code points in question should be clarified.
> 
> I do want to raise one potential concern about the reclassification of the ranges: since Experimental is completely ungoverned (see 
> https://tools.ietf.org/html/rfc8126#section-4.2
> ), there could in theory be implementations in the field already using code points from this space. I think it’s not very likely that there ARE such, but there could be. (If someone knows of an example of one, they should say so right now of course.)

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Job Snijders <[email-masked]>
Date: Wed, 3 Feb 2021 23:41:27 +0000

Hi Christoph,

On Wed, Feb 03, 2021 at 11:25:19AM +0100, Christoph Loibl wrote:
> I want to point out that these code-points have actual non
> experimental implementations in shipping products of all larger
> vendors. I think it has an advantage to “protect” these CPs from
> future experimental use.

Yup, indeed a nice advantage.

One comment:

In the "BGP Transitive Extended Community Types" registry the
'Registration Procedures" for 0x80-0x8f	list 'Reserved for Experimental Use'

However, when we zoom in on for example the 'Generic Transitive
Experimental Use Extended Community Sub-Types' registry, the listed
'Registration Procedures' are either 'FCFS' or 'IETF Review'.

To me this appears as an internal inconsistency, where I'd assume the
'most specific' procedure to take precedence? (but ... assumptions ...)

I think your draft makes sense and should proceed, but it is not clear
to me whether it would materially changes the currently listed
procedures.

Is there an internal inconsistency or am I reading it wrong?

Kind regards,

Job

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 23 Feb 2021 12:33:18 +0100

Hi Job,

Thanks for your response. 

AFAIK the mentioned registries do not have any structural dependencies in the sense that registration procedures get propagated from Extended-Community-Types to Sub-Types. 

The draft fixes the documentation of some of the Extended-Community-Types (this includes changing the registration procedure for those Community-Types ). The sub-type registries are only renamed. Changes are kept to a minimum required to solve the misleading-documentation.

Cheers Christoph

> On 04.02.2021, at 00:41, Job Snijders <[email-masked]> wrote:
> 
> Hi Christoph,
>