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

[Loa Andersson <[e-mail]>]

All,

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

/Loa

On 17/02/2021 18:40, Adrian Farrel wrote:
> 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) <[e-mail]>
> Sent: 17 February 2021 10:24
> To: [e-mail]; 'The IESG' <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Robert Wilton's Discuss on draft-ietf-mpls-lsp-ping-registries-update-08: (with DISCUSS)
> 
> 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 <[e-mail]>
>> Sent: 16 February 2021 14:17
>> To: Rob Wilton (rwilton) <[e-mail]>; 'The IESG' <[e-mail]>
>> Cc: [e-mail]; mpls-
>> [e-mail]; [e-mail]
>> 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.
>>
>>> 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/
>>
>>
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]