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

[Greg Mirsky <[e-mail]>]

Hi Haoyu,
thank you for your response. Please find my follow-up notes in-lined below
under the GIM>> tag.

Regards,
Greg

On Thu, Mar 31, 2022 at 1:01 PM Haoyu Song <[e-mail]> wrote:

> 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.
>
GIM>> I may use RFC 5880 and RFC 5884 as an example. RFC 5880 defines two
BFD modes, Asynchronous and Demand, and BFD Echo function. RFC 5884
describes applicability only of the Asynchronous BFD mode while leaving
Demand and BFD Echo undefined. I think that a similar approach excluding
some IOAM options can be applied to IOAM over MPLS data plane.

>
>
> 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.
>
GIM>> If this operation follows principles of hierarchical LSP (RFC 4206
<https://datatracker.ietf.org/doc/html/rfc4206>), then the node that
imposes ADIs is the ingress LER.

>
>
> 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]>
> 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]> *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Thursday, March 31, 2022 8:00 AM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* mpls <[e-mail]>; DetNet WG <[e-mail]>;
> [e-mail]; [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]>
> *Date: *Friday, 4 March 2022 at 00:15
> *To: *Bocci, Matthew (Nokia - GB) <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, mpls <[e-mail]>,
> spring <[e-mail]>, DetNet WG <[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]> 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]>
> *Date: *Tuesday, 15 February 2022 at 20:18
> *To: *[e-mail] <
> [e-mail]>
> *Cc: *mpls <[e-mail]>, spring <[e-mail]>, DetNet WG <
> [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
>
>