Re: [Detnet] Comments on draft-bocci-mpls-miad-adi-requirements

[Haoyu Song <[e-mail]>]

Greg,

Once a feature is specified in the standard, it implies a possibility we can't ignore and preclude the use of it. Also, there could be other HBH headers defined in the future. We don't know if it's necessary for them to retain the capability to insert/remove data on the way. On the safe side, we should keep the option open rather than close.

The more critical question is the second part of my comment. Should we limit that only LER can add/remove headers? I'd like to see more discussion on pros and cons before we make any decision. I think more flexibility is good unless some serious issues prohibit us from having it.

Best,
Haoyu

From: Greg Mirsky <[e-mail]>
Sent: Thursday, March 31, 2022 12:33 PM
To: Haoyu Song <[e-mail]>
Cc: Bocci, Matthew (Nokia - GB) <[e-mail]>; mpls <[e-mail]>; DetNet WG <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Comments on draft-bocci-mpls-miad-adi-requirements

Hi Haoyu,
I have several questions about the IOAM-related scenarios and hope you can clarify them for me.
Firstly, how I understand the scenario we're discussing:

  *   A packet already has the IOAM Option Header as PSD
  *   An IOAM encapsulating node set IOAM Trace Option to IOAM Incremental Trace Option-Type
Is my understanding correct? If it is, I think that we need to explain to our colleagues that do not follow closely IOAM how the IOAM Incremental Trace Option-Type expected to work:

  *   with this IOAM Trace Option type, every transit IOAM node is expected to increase the size of IOAM Data Space in PSD to accommodate IOAM data types requested in the 24 bit-long IOAM Trace Type field.
I consider this IOAM Trace Option type undesirable, particularly in an MPLS network because it may easily create MTU exceeded situations. IOAM offers other trace options that are more suitable for MPLS data plane. For example, in an operator prefers transporting IOAM data within a data packet, one can use the IOAM Pre-allocated Trace-Option where the IOAM encapsulating node pre-allocates space for the IOAM Data field in PSD. Transit node writing into the pre-allocated space in PSD, in my opinion, is not "the insertion of the ancillary data" as the space already has been pre-allocated by the ingress LER. But I see more benefits in separating processes of generating telemetry from collecting and transporting information to a collector function. That can be achieved using , for example, IOAM Direct Export<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca1cad479d5384a99a65a08da134d3dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637843519739512695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Tjm%2FdLUUz9vs%2B57ICieBxnH%2BdBikqkHvdalwA06rWc0%3D&reserved=0> or Hybrid Two-step<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-ippm-hybrid-two-step%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca1cad479d5384a99a65a08da134d3dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637843519739512695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kNcBU3BOV5DXeVtpDQr8BuLOC8lBcAPJNAoBNItxy%2Bw%3D&reserved=0>.

Regards,
Greg

On Thu, Mar 31, 2022 at 9:33 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:

  *   bullet 4 receives two notes:

     *   I think it should be a requirement, not a recommendation
     *   I think that an LSR must not be able to insert any ancillary data. Only ingress LER inserts data.
Why? IOAM trace will need to add data on LSR for sure.
I guess here you actually mean new headers.  For this case, I think we need to discuss why we want to prohibit LSR to add new header. If we allow LSR to add new header, what principles of MPLS are violated? Does this add more flexibility or functionality to the network? I'd like to see more discussions before making such decisions which could have profound subsequence.

Thanks,
Haoyu

From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Thursday, March 31, 2022 8:00 AM
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>; DetNet WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Comments on draft-bocci-mpls-miad-adi-requirements

Hi Greg

Thank you for your comments. Please see below.

Matthew

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Friday, 4 March 2022 at 00:15
To: Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, mpls <[e-mail]<mailto:[e-mail]>>, spring <[e-mail]<mailto:[e-mail]>>, DetNet WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: Comments on draft-bocci-mpls-miad-adi-requirements
Hi Matthew and Stewart,
thank you for your work addressing my comments; much appreciated. I have several follow-up questions and comments to the new version of the draft, mostly to the new Section 3.1.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-bocci-mpls-miad-adi-requirements%23section-3.1.2&data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca1cad479d5384a99a65a08da134d3dbd%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637843519739512695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sZt0dWsf9j%2FnjEfT0hn8biezvhtE7ssqjUiXL2oDl0o%3D&reserved=0>:

  *   I may suggest an editorial update to bullet 2
OLD TEXT:
   2.   A common mechanism for ancillary data MUST be defined so that a
        node receiving the ancillary data can determine whether to
        process, ignore or discard it.
NEW TEXT:
   2.   A common mechanism for ancillary data MUST be defined so that a
        node receiving the ancillary data can act according to the local policies.

MB> OK

  *   bullet 4 receives two notes:

     *   I think it should be a requirement, not a recommendation
     *   I think that an LSR must not be able to insert any ancillary data. Only ingress LER inserts data.
MB> OK

  *   it would be good if bullet 6 can be split into two
MB> The second part is a consequence of the first part, so they should probably stay together but we will rephrase to make this clearer.

  *   RE: bullet 7, I don't think that MPLS is the appropriate layer to guarantee in-order delivery. Should that be left to an application?
MB> This is not intended to be about MPLS guaranteeing in-order delivery, but rather whether the application can withstand out of order or "off line" or "slow path" processing or whether it requires in-line or fast path processing of ancillary data.

  *   it appears that bullet 8 is specific to the PSD case. If that is the case, should it refer to the BoS instead of "as close to the label stack as possible"?
MB> OK

  *   I think that having a requirement for the use of a common ancillary data header will help the discussion.
MB> We have modified the second requirement in "Ancillary Data Requirements" to reflect this.

Couple nits:

  *   "an/or" -> "and/or"
  *   s/lath/path/
Regards,
Greg

On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg

Thank you for your detailed review and comments. We have tried to address these in the updated draft that we just posted.

In answer to your question below about whether the ancillary data needs a common format, I agree that it at least needs a common header format.

Regards

Matthew


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 15 February 2022 at 20:18
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>, spring <[e-mail]<mailto:[e-mail]>>, DetNet WG <[e-mail]<mailto:[e-mail]>>
Subject: Comments on draft-bocci-mpls-miad-adi-requirements
Hi Stewart and Matthew,
thank you for organizing this document in a very clear and concise manner. I enjoyed reading it.
Attached, please find a copy of the draft with my notes, comments, and suggestions. The most important, in my view, the question I have Should we add the requirement to have a common format for ancillary data defined?

Looking forward to your feedback.

Regards,
Greg