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

[Greg Mirsky <[e-mail]>]

Hi Xiao Min,
thank you for your consideration of my notes. I believe that given the
state of the implementations that demonstrated their interoperability,
requesting allocation of the specific eSPL is a reasonable step that
benefits the networking.

Regards,
Greg

On Wed, May 8, 2024 at 11:09 PM <[e-mail]> wrote:

> Hi Greg,
>
>
> Thank you for the prompt response.
>
> Please see inline.
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> *Date: *2024年05月09日 11:43
> *Subject: **Re: [mpls] WG last call:
> draft-ietf-mpls-inband-pm-encapsulation*
> Hi Xiao Min,
> thank you for your response. Please find my follow-up notes below tagged
> GIM2>>.
>
> Regards,
> Greg
>
> On Wed, May 8, 2024 at 1:41 AM <[e-mail]> wrote:
>
>> Hi Greg,
>>
>>
>> Thank you for the reply.
>> Please see inline.
>> Original
>> *From: *GregMirsky <[e-mail]>
>> *To: *肖敏10093570;
>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
>> [e-mail] <[e-mail]>;
>> *Date: *2024年05月08日 03:09
>> *Subject: **Re: [mpls] WG last call:
>> draft-ietf-mpls-inband-pm-encapsulation*
>> Hi Xiao Min,
>> thank you for your expedient response. Please find my notes below tagged
>> GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Sun, May 5, 2024 at 7:30 PM <[e-mail]> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>> Thanks for your review and comments.
>>>
>>> Please see inline.
>>> Original
>>> *From: *GregMirsky <[e-mail]>
>>> *To: *Tony Li <[e-mail]>;
>>> *Cc: *mpls <[e-mail]>;mpls-chairs <[e-mail]>;
>>> *Date: *2024年05月04日 03:38
>>> *Subject: **Re: [mpls] WG last call:
>>> draft-ietf-mpls-inband-pm-encapsulation*
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>> 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?
>>>
>>>    [XM]>>> That applies to a flow of MPLS packets in a network. In the
>>>    Abstract of RFC 9341 it says "This document describes the
>>>    Alternate-Marking technique to perform packet loss, delay, and jitter
>>>    measurements on live traffic".
>>>
>>> GIM>> Thank you for the reference to RFC 9341. Although I am one of th
>> co-authors of that RFC, thinking of it now, I find the characterization
>> "live traffic" ambigious. Is there in the network traffic other than
>> "live"? I cannot find an example of such case. If you agree, perhaps
>> finding a more technical term or removing "live" altogether is possible.
>>
>> [XM-2]>>> To my understanding, one reason why RFC 9341 emphasize "*live *traffic"
>> is to differentiate the "Alternate-Marking technique" from "Inerred
>> measurement", which performs performance measurement on dedicated LM/DM
>> packets. Anyway, I can remove "live" altogether if no objection from other
>> WG participants.
>>
> GIM2>> I hope that WG Chairs will help in determining the WG position on
> this update.
>
>>
>>
>>>    -
>>>
>>>    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.
>>>
>>>    [XM]>>> Note that the text means the SFL method mainly aims at
>>>    edge-to-edge processing, not hop-by-hop. And you're right that the method
>>>    described in this document can be used for both hop-by-hop and
>>>    edge-to-edge, although the main application scenario is hop-by-hop.
>>>
>>> GIM>> How "the SFL method mainly aims" is determined? Is that stated in
>> any of SFL documents? At the same time, if the proposed mechanism is aimed
>> for the particular use case, extending it to support anything else adds, in
>> my opinion, is an unecessary complexity. If, as you've stated, supporting
>> the Alternate Marking method in the MPLS network is not intended with
>> edge-to-edge scope, then it seems that the T-bit is not needed and can be
>> changed to R(eserved). Even more reason to do that, in my view, is that the
>> scope of the PM supported by the Alternate Marking method (and on-path
>> telemetry in general) can be easily controled via the management plane by
>> controling the appropriate configuration parameters.
>>
>> [XM-2]>>> I said the method described in this document can be used for
>> both hop-by-hop and edge-to-edge. For edge-to-edge, both the method
>> described in this document and SFL can be used. For hop-by-hop, the method
>> described in this document is preferred, and there exists interoperable
>> implementations.
>>
> GIM2>> Can you point out what prevents someone from using SFL in a
> hop-by-hop manner? Also, what importance do you see in that comparison of
> SFL-based and AMM-based methods for the document? Personally, I think that
> that comparison can be removed from the draft without any loss of technical
> clarity.
>
> [XM-3]>>> I agree to remove this paragraph if no objection from other WG
> participants.
>
>>
>>
>>>    -
>>>
>>>    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.
>>>
>>>    [XM]>>> Can the ISD be seen as a new header? I personally don't
>>>    think so. If you have any text change proposal, it's much appreciated. :-)
>>>
>>> GIM>> Sorry, but I don't understand your question. IOAM can be supported
>> by ISD MNA (draft-mb-mpls-ioam-dex
>> <https://datatracker.ietf.org/doc/draft-mb-mpls-ioam-dex/>), and AFAICS,
>> the impact of supporting IOAM-DEX using ISD MNA is comparable with the
>> solution proposed in this document or draft-cx-mpls-mna-inband-pm
>> <https://datatracker.ietf.org/doc/draft-cx-mpls-mna-inband-pm/>. I would
>> consider removing this subjuective comparison altogether from the document.
>>
>> [XM-2]>>> I agree to remove this paragraph if no objection from other WG
>> participants.
>>
> GIM2>> Thank you. That could be another modification that the WG Chairs
> might ask the WG's position.
>
>>
>>
>>>    -
>>>
>>>    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).
>>>
>>>    [XM]>>> I agree with Tony and Loa on this point. To be clear, it's
>>>    preferred to publish this document as a Standards Track RFC.
>>>
>>>
>>>    -
>>>
>>>    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?
>>>
>>>    [XM]>>> It's my fault not requesting an early allocation. Anyway, I
>>>    believe allocating a permanent code point for this feature is optimal for
>>>    the existing and potential implementers and deployers.
>>>
>>> GIM>> Perhaps you can help understanding the state of the existing
>> implementations that, as I look at the issue, is confusing. On one hand,
>> some of implementations have demonstrated their interoperability. And, one
>> can assume, that that is achieved using a value from the Unassigned range
>> of Extended Special-Purpose MPLS Label Values
>> <https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml#extended>.
>> On the other hand, a new value is requested and there's non-zero
>> propbability that the assigned value would not be the one already used in
>> the existing implementations. If implemeters squatted (using Tony's term)
>> on the IANA registry, would it be better to identify that value and request
>> it to be assigned to the solution described in this document?
>>
>> [XM-2]>>> To my understanding, the existing implementations can be
>> updated if requested by their customers, and the future implementations can
>> follow the published RFC.
>>
> GIM2>> I have to admit that your response confused me and raised more
> concerns. As I understand it, the intention of publishing this
> specification as a Standard is to bring the IANA registry in sync with the
> deployed implementations. As I understand your response, that would not
> happen because the allocated eSPL value would be different from the value
> already used by the existing implementations. If my understanding is what
> the authors of the draft have planned, then I see the request for IANA to
> allocate yet another eSPL value that is not currently used by any existing
> implementation as unreasonable and damaging. Unless the authors disclose
> which eSPL value is used in the existing implementations and insist on
> requesting a new eSPL value be allocated by IANA, I cannot find any reason
> for publishing this document as Standard.
>
> [XM-3]>>> Does it resolve your concern if the authors recommend a value of
> code point to be assigned by IANA?
>
>
> Best Regards,
>
> Xiao Min
>
>>
>> Cheers,
>>
>> Xiao Min
>>
>>>
>>> Best Regards,
>>>
>>> Xiao Min
>>>
>>>
>>> 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]> 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]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>
>>>
>>
>