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

[Greg Mirsky <[e-mail]>]

Hi Xiao Min,
I've reviewed the new version of the draft. Thank you for thoroughly
addressing all my comments. I support progressing this document.

Regards,
Greg

On Thu, May 9, 2024 at 6:07 PM <[e-mail]> wrote:

> Thank you Greg!
>
> I'll upload a new version to address your WGLC comments.
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *肖敏10093570;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> *Date: *2024年05月09日 23:35
> *Subject: **Re: [mpls] WG last call:
> draft-ietf-mpls-inband-pm-encapsulation*
> 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
>>>>>
>>>>
>>>>
>>>
>>
>