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://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>
or Hybrid
Two-step
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>.

Regards,
Greg

On Thu, Mar 31, 2022 at 9:33 AM Haoyu Song <[email protected]> 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 <[email protected]> *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Thursday, March 31, 2022 8:00 AM
> *To:* Greg Mirsky <[email protected]>
> *Cc:* mpls <[email protected]>; DetNet WG <[email protected]>;
> [email protected]; [email protected]
> *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 <[email protected]>
> *Date: *Friday, 4 March 2022 at 00:15
> *To: *Bocci, Matthew (Nokia - GB) <[email protected]>
> *Cc: *[email protected] <
> [email protected]>, mpls <[email protected]>,
> spring <[email protected]>, DetNet WG <[email protected]>
> *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%7C504e867fb73e471bab2f08da1327d14c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637843359007401955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=1ZNs8jU3O2RgVsGU3zD8ftkqbxsDLyUr0YQPLZQV390%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) <
> [email protected]> 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 <[email protected]>
> *Date: *Tuesday, 15 February 2022 at 20:18
> *To: *[email protected] <
> [email protected]>
> *Cc: *mpls <[email protected]>, spring <[email protected]>, DetNet WG <
> [email protected]>
> *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
>
>

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals