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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 16 Feb 2021 02:38:09 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-mpls-lsp-ping-registries-update-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

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?

(2) I find the "updates" tag for RFCs to be somewhat ambiguous as to what it
means.  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.

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?

Regards,
Rob

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Feb 2021 14:16:37 -0000

Hi Rob,

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

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

> 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

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.

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 17 Feb 2021 10:23:30 +0000

Hi Adrian,

Thanks for the comments.

The background of wanting to remove private use because it is considered harmful is helpful, and certainly explains why my last proposal isn't a viable solution.

I can also accept that it seems unlikely that there is significant usage of the private use space today, given that the RFC that is being updated isn't very old, and the major vendors are authors of the RFC or have been involved in the review.

Nor can I reasonably ask that this RFC is respun as an 8611-bis RFC now, although I don't in the general case see why bis drafts should necessarily be significantly more work than an update draft, given that tooling can be used to just review the diff.

But that still leaves my concern that the update is ambiguous, and readers might miss or choose to ignore the update.

Perhaps a pragmatic path forward would be to make sure draft-ietf-mpls-lsp-ping-registries-update-08 is a bit more explicit in how it is updating 8611:

1) It might be helpful if the abstract and introduction makes it clear that the update is redefining the 'private use' registry to FCFS.

2) I think that it would be useful for the introduction to provide some text to explain the background of why the 'private use' to 'FCFS' registry change is being made.  This might also help encourage folks to follow the update.

Re: clarifying the updates rules, yes, I think that Mirja and Suresh were trying to do this (draft-kuehlewind-update-tag), but it seems that these sorts of process changes seem to take a lot more effort in IETF than arguably they should.

Regards,
Rob

> -----Original Message-----
> From: Adrian Farrel <[email-masked]>
> Sent: 16 February 2021 14:17
> To: Rob Wilton (rwilton) <[email-masked]>; 'The IESG' <[email-masked]>
> Cc: [email-masked]; mpls-
> [email-masked]; [email-masked]
> Subject: RE: Robert Wilton's Discuss on draft-ietf-mpls-lsp-ping-
> registries-update-08: (with DISCUSS)
> 
> Hi Rob,
> 
> Document shepherd speaking here. Thanks for the review and thoughtful
> comments. They definitely merit discussion.
> 
> 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]
> 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.
> 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 😊
> 
> 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.
> 
> 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/
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Feb 2021 18:36:36 +0800

Bob, Adrian, et.al.,

I have nothing much to add to what Adrian wrote. We are from time to 
time talking to people implementing this. To the best of our knowledge 
there are no codes points from the registries that we are changing 
assigned by any other registration procedure than "Standards Action".

I hope that with this information this discuss could be cleared.

/Loa

On 16/02/2021 22:16, Adrian Farrel wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Feb 2021 10:40:49 -0000

Hi Rob,

That looks like a reasonable set of requests.

I leave it to the authors to fix the text.

Cheers,
Adrian

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 17 February 2021 10:24
To: [email-masked]; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Robert Wilton's Discuss on draft-ietf-mpls-lsp-ping-registries-update-08: (with DISCUSS)

Hi Adrian,

Thanks for the comments.

Regards,
Rob

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Feb 2021 19:04:00 +0800

All,

I will work on text for the Abstract and the Introduction.

/Loa

--