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

[Greg Mirsky <[e-mail]>]

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.

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

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