Re: [mpls] WG last call: draft-ietf-mpls-inband-pm-encapsulation

[Tony Li <[e-mail]>]

[WG chair hat: on]

Hi Greg,

Yes, existing implementations that are using an experimental code point could continue to do so if the document were published as Experimental.  However, this would leave us in an awkward situation where an experimental code point is effectively allocated to the protocol but not documented in the registry.  This seems sub-optimal.  The whole point of experimental code points is that they do not become permanent.

I cannot speak to why there was no request for early allocation.  Sorry, I’m late ot the party here. If it was my proposal, I would have.

Regards,
Tony


> On May 3, 2024, at 1:13 PM, Greg Mirsky <[e-mail]> wrote:
> 
> Hi Tony,
> thank you for your prompt clarification of the eSPL value allocation. I assume that the listed implementations, or some of them, are already deployed. As I understand it, they all use some value as FLI, most likely the same one across all the implementations. As you've pointed out, using a value from the Unassigned or Reserved ranges of the Extended Special-Purpose MPLS Label Values registry <https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml#extended> would be squatting. 
> About potential squatting (that, as I believe, should not be encouraged). If I was considering an early implementation of this draft, I'd use a value from the Experimental range (240-255). If that is the case for this draft, moving it to the Experimental track, in my opinion, is reasonable. On the other hand, if the implementers of earlier version of the draft did use a value from Unassigned range without the early allocation, why wouldn't they ask for allocation of that specific value rather than letting IANA to pick one for them and be forced to change their implementations in case the two values turned to be different?
> 
> Regards,
> Greg
> 
> On Fri, May 3, 2024 at 1:00 PM Tony Li <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> [WG chair hat: on]
>> 
>> Hi Greg,
>> 
>> I will let the authors respond to the bulk of the comments here, but I do want to address some process concerns.
>> 
>> Currently, the registry action for the 'Extended Special-Purpose MPLS Label Values' registry is ’Standards Action’. If this document were to be published as Experimental, then it would not be allowed to allocate a permanent code point, resulting in the implementations squatting on a code point. This is sub-optimal.
>> 
>> It appears that there was no early allocation done for a code point, so the squatting is already obviously occurring. Also sub-optimal.
>> 
>> First publishing as Standards Track and then shifting to Historical allows for code point allocation.
>> 
>> Regards,
>> Tony
>> 
>> 
>>> On May 3, 2024, at 12:37 PM, Greg Mirsky <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi, Tony and All,
>>> I've read the latest version of the draft. Please find my comments below:
>>> The proposed mechanism, as stated in Abstract, applies to "MPLS live traffic". I couldn't find the definition of the term "live traffic" and appreciate it if you can clarify it for me. Does that apply to any MPLS packet or a particular class of MPLS packets in a network?
>>> I appreciate that the document mentions work on Synonymous Flow Labels. However, it is not clear to me why SFL-based application of the AMM is characterized as hop-by-hop, while the solution described in the draft - as edge-to-edge. I would appreciate it if the authors can clarify that characterization of measurement methods, particularly since the T-bit (defined in Figure 1) differentiates between edge-to-edge and hop-by-hop measurements using the proposed solution.
>>> Furthermore, it seems like the comparison of the impact on an MPLS packet of the proposed solution and IOAM is inaccurate. As I understand it, contrary to the statement in Introduction that "the former doesn't introduce any new header whereas the latter introduces a new In-situ OAM header", both introduce (unlike SFL-based application of AMM) extra ancillary data in an MPLS packet.
>>> And, on the last paragraph in Introduction. I believe that publishing a draft on Standard track and then moving it to Historic once another solution is standardized by IETF is sub-optimal. I recognize the value of the work put in by implementers of the described in the draft solution. The deployment experience is invaluable. On the other hand, there seems to be an agreement that the MNA is the preferred mechanism to support AMM in the MPLS networks. (Note that draft-ietf-mpls-mna-usecases is being updated to include AMM as another use cases of on-path telemetry in the MPLS networks, in addition of IOAM). Hence my proposal to switch this document to Experimental track (see my question about the requested IANA allocation below).
>>> The list of implementations is impressive and suggests that there are several deployments. If that is the case, which value of eSPL for Flow-ID Label Indicator is used?
>>> In conclusion, I don't support progressing this draft on the Standard track. I would support progressing it as Experimental or Informational (perhaps that means that the IANA section is removed).
>>> 
>>> Regards,
>>> Greg
>>> 
>>> On Thu, Apr 25, 2024 at 8:09 AM Tony Li <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> [WG chair hat: on]
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> This starts a 2 week working group last call on draft-ietf-mpls-inband-pm-encapsulation.
>>>> 
>>>> This last call ends at 12:01 PM PDT, Thurs. May 9, 2024.
>>>> 
>>>> Please send all comments to the mailing list.
>>>> 
>>>> Regards,
>>>> Tony
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>