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

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 3 Mar 2022 11:58:43 +0000

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-masked]>
Date: Tuesday, 15 February 2022 at 20:18
To: [email-masked] <[email-masked]>
Cc: mpls <[email-masked]>, spring <[email-masked]>, DetNet WG <[email-masked]>
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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Mar 2022 08:08:04 -0800

Hi Matthew,
thank you for the heads-up. I'll review the updated draft and be back with
my notes.

Regards,
Greg

On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> 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-masked]>
> *Date: *Tuesday, 15 February 2022 at 20:18
> *To: [email-masked] <
> [email-masked]>
> *Cc: *mpls <[email-masked]>, spring <[email-masked]>, DetNet WG <
> [email-masked]>
> *Subject: *Comments on draft-bocci-mpls-miad-adi-requirements
>
> Hi Stewart and Matthew,
>
> 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?
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Mar 2022 16:15:14 -0800

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://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements#section-3.1.2>
:

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

   - 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.
   - it would be good if bullet 6 can be split into two
   - 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?
   - 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"?
   - I think that having a requirement for the use of a common ancillary
   data header will help the discussion.

Couple nits:

   - "an/or" -> "and/or"
   - s/lath/path/

Regards,
Greg

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 31 Mar 2022 14:59:59 +0000

Hi Greg

Thank you for your comments. Please see below.

Matthew

From: Greg Mirsky <[email-masked]>
Date: Friday, 4 March 2022 at 00:15
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: [email-masked] <[email-masked]>, mpls <[email-masked]>, spring <[email-masked]>, DetNet WG <[email-masked]>
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://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements#section-3.1.2>:

  *   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-masked]<mailto:[email-masked]>> wrote:
Hi Greg

Regards

Matthew

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 15 February 2022 at 20:18
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, DetNet WG <[email-masked]<mailto:[email-masked]>>
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?

Regards,
Greg

---

From: Haoyu Song <[email-masked]>
Date: Thu, 31 Mar 2022 16:33:42 +0000

*   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-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Thursday, March 31, 2022 8:00 AM
To: Greg Mirsky <[email-masked]>
Cc: mpls <[email-masked]>; DetNet WG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments on draft-bocci-mpls-miad-adi-requirements

Hi Greg

Matthew

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, 4 March 2022 at 00:15
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, DetNet WG <[email-masked]<mailto:[email-masked]>>
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>:

MB> OK

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

  *   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

Regards

Matthew

Regards,
Greg

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 09:46:54 -0700

> On Mar 31, 2022, at 9:33 AM, Haoyu Song <[email-masked]> 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.
> 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.
>  

I concur.

Generality and hierarchy suggest that we should be able to inject data and functions at arbitrary places.

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 12:32:34 -0700

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-masked]> wrote:

>       - I think that an LSR must not be able to insert any ancillary
>       data. Only ingress LER inserts data.
>
> 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-masked]> *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Thursday, March 31, 2022 8:00 AM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* mpls <[email-masked]>; DetNet WG <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Comments on draft-bocci-mpls-miad-adi-requirements
>
>
>
> Hi Greg
>
>
>
> *Date: *Friday, 4 March 2022 at 00:15
> *To: *Bocci, Matthew (Nokia - GB) <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>, mpls <[email-masked]>,
> spring <[email-masked]>, DetNet WG <[email-masked]>
> *Subject: *Re: Comments on draft-bocci-mpls-miad-adi-requirements
>
> Hi Matthew and Stewart,
>
> <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 think that an LSR must not be able to insert any ancillary
>       data. Only ingress LER inserts data.
>
> MB> OK
>
> 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.
>
> 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.
>

---

From: Haoyu Song <[email-masked]>
Date: Thu, 31 Mar 2022 20:01:40 +0000

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 <[email-masked]>
Sent: Thursday, March 31, 2022 12:33 PM
To: Haoyu Song <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; mpls <[email-masked]>; DetNet WG <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Haoyu

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

Hi Greg

Matthew

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

MB> OK

Couple nits:

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

Regards

Matthew

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 13:19:58 -0700

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 <[email-masked]> 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 <[email-masked]>
> *Sent:* Thursday, March 31, 2022 12:33 PM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; mpls <
> [email-masked]>; DetNet WG <[email-masked]>;
> *Subject:* Re: Comments on draft-bocci-mpls-miad-adi-requirements
>
>
>
> Hi Haoyu,
>
>    - 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
> <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
>
>
>
> <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>
> :
>

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 13:28:43 -0700

> On Mar 31, 2022, at 1:19 PM, Greg Mirsky <[email-masked]> wrote:
> 
> 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.

And if you allow arbitrary nesting, then effectively any node can insert a sub-stack with ancillary data.

T

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 13:46:05 -0700

Hi Tony,
I think that the situation with an arbitrary LSR imposing ADIs is more
nuanced as we must understand where the particular ADI must be disposed of.
I am not certain how it, for example, applies to SR-MPLS. I can imagine
hierarchical LSP imposed between two adjacent SR nodes. If that is the
case, imposed ADIs must be disposed within that segment. Please let me know
if I'm missing anything.

Regards,
Greg

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 15:14:04 -0700

Greg,

> On Mar 31, 2022, at 1:46 PM, Greg Mirsky <[email-masked]> wrote:
> 
> I think that the situation with an arbitrary LSR imposing ADIs is more nuanced as we must understand where the particular ADI must be disposed of. I am not certain how it, for example, applies to SR-MPLS. I can imagine hierarchical LSP imposed between two adjacent SR nodes. If that is the case, imposed ADIs must be disposed within that segment. Please let me know if I'm missing anything.

As they say in aviation: taking off is optional, landing is mandatory. :)

Yes, while adding ADI can effectively be done anywhere, if you actually want to deliver useful payload, there must be adequate consideration given to where the ADI is removed.  In keeping with a hierarchical nature, I would hope that addition and removal would be coupled operations at either ends of a container LSP.

Tony