Re: [mpls] Robert Wilton's Discuss on draft-ietf-mpls-lsp-ping-registries-update-08: (with DISCUSS)

[Adrian Farrel <[e-mail]>]

Hi Rob,

Document shepherd speaking here. Thanks for the review and thoughtful comments. They definitely merit discussion.

> I have a couple of concerns regarding the change from part of the registry from
> "Private Use" to "FCFS":
>
> (1) Am I right in thinking that this could, at least in theory, break existing
> deployments?  E.g., two separate implementations could both be using TLV value
> 31744 under "private use", whereas now they would both be expected to register
> that TLV with IANA under FCFS, and obviously only one of them would be able to
> get the registration?  Are the authors/WG/ADs aware with high confidence that
> no such deployments exist?

You're right that this is a theoretical possibility.
First point of note is that under the current "Private Use" scheme, two implementations could already be using 31744. " No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways." [RFC8126]  Furthermore, private use cases are not registered in the registry, so there is a risk that they will collide in the field. The only protection offered is that "It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use)." [RFC8126]

Now, we are aware that MPLS tends to be deployed widely and in large networks, so "Private Use" is a little risky. Moving to a mode where code points are registered is a step forward.

If, as is possible, two organisations discover they are both making private use of the same code point, it is actually better to discover this through the registry rather than in the field. The choice of FCFS or RFC Required was set according to the type of code point and the scarcity. And "First come, first served" is what it calls itself, so the second organisation to notice will need to change its code point. This is an encouragement to organisations to register early, and a reminder to us all to implement with configurable codepoints when using "Experimental" or "Private Use" registries.

Perhaps also note that if "Private Use" code points are in use in private (limited scope) domains, then these changes won't actually have any impact. That is, those domains can continue as they are today without anyone seeing any issues. This is not to encourage squatting on code points, but to observe the realities of deployments.

Now to the main point...
I raised this question on the MPLS list and specifically asked "I would, of course, also like to know if anyone is using any of the Private Use ranges for anything?" [1]
There was, of course, also a WG last call.
Maybe an additional mitigation is that there are co-authors from three large vendors, and that there are on-list review comments from people at other vendors.
None of this is conclusive proof of the absence of a problem, but maybe indicates that a problem, if it exists will be small.
Any problems are relatively easily reconciled.

> (2) I find the "updates" tag for RFCs to be somewhat ambiguous as to what it
> means. 

LOL
The definition of these tags has been ambiguous for a few years, and one might make a reasonable argument that it is the IESG's responsibility to define the meanings so that everyone else knows how to use them 😊

> Specifically, is someone who implements RFC 8611 obliged to also
> implement draft-ietf-mpls-lsp-ping-registries-update when this becomes an RFC? 
> Or are they allowed to take the previous interpretation of the "private use" in
> the IANA registries?  Probably too late to change this now, but I wonder if it
> would have been better to bis RFC 8611 instead so that RFC 8611 could have been
> formally obsoleted by draft-ietf-mpls-lsp-ping-registries-update instead.

It's a cost-benefit. Personally, I like the idea of fully revising (and therefore obsoleting) RFCs, but the community has historically baulked at this claiming the risks of "reopening documents" etc., etc., but also worried about the work-load.

> An alternative solution would be to keep the "Private Use" space as defined in
> RFC 8611, and allocate new space for FCFS (24 entries) from the 15,000 entry
> "RFC Required" section of the TLV Id space instead.  These would seem to make
> the new allocation scheme in draft-ietf-mpls-lsp-ping-registries-update
> entirely backwards compatible with any existing deployments.  Was this approach
> considered and dismissed for some reason?

I would have to do some archaeology to find emails on this, but my recollection is that the whole point of the change is based on the opinion that FCFS is good and Private Use is suspect. Thus the intention is not to enable *an* "RFC Required" range, but to reposition the ranges as described in the document.

At this point, I think this part of your Discuss might qualify as "I wouldn't have done it like this" or "I'm not sure why you did it like this". Those are fine comments, but I don't know what the authors can make of them given the lifecycle of the document.

Best,
Adrian

[1] https://mailarchive.ietf.org/arch/msg/mpls/ewEzqMkkwwOxdChj_NfF_G_CZKo/