[mpls] Re: Poll: IOAM and PSD

[Rakesh Gandhi <[e-mail]>]

Hi Tony,

Ok, sure. Please see inline replies with <RG> with the top posting the
poll…

---------------------------------------------------------------------------------------------------------------------------

*From: *Tony Li <[e-mail]> on behalf of Tony Li <
[e-mail]>
*Date: *Tuesday, July 30, 2024 at 11:26 AM
*To: *mpls <[e-mail]>
*Subject: *[mpls] Poll: IOAM and PSD

[WG chair hat: on]

Hi all,



We’ve had many discussions about IOAM and PSD over the last few years. We
need to reach consensus on the problems that need to be addressed in these
areas. Therefore, we would like to hear from everyone, especially
independent operators:



   1. There are many flavors of IOAM.  Which ones would you like to
   deploy/implement with MNA?



<RG>

·         We have interest in implementing the IOAM passport method
with the Pre-allocated option defined in RFC 9197 using MNA with
Post-Stack Data.

·         We have interest in implementing the IOAM postcard method with
direct-export option defined in RFC 9326 using MNA with Post-Stack Data.



   2. Do you have other applications of MNA that have not been proposed yet?



<RG>

·         We have interest in implementing Path Tracing as described in
draft-filsfils-spring-path-tracing-srmpls-04 with Pre-allocated option
using MNA with Post-Stack Data.

·         There have been proposals for Generic Delivery Functions
[draft-zzhang-intarea-generic-delivery-functions-03] and for Enhanced
DETNET [draft-sx-mpls-detnet-bounded-latency-01] that can benefit from MNA
with Post-Stack Data.

·         Further discussions with operators may result in us implementing
proof-of-transit and E2E IOAM option types defined in RFC 9197 in future
using MNA with Post-stack Data.



I believe MNA with PSD will open doors for many new use-cases in MPLS
(similar to IPv6 extension headers in IPv6).



P.S. FWIW, IPv6 extension headers already support IOAM option-types:
Pre-allocated
trace, Proof of Transit, Edge-to-Edge and Direct Export (DEX) in RFC 9486.



Thanks,

Rakesh



This poll will close in two weeks, at 9am PDT, Aug 13.



Regards,

MPLS chairs

On Mon, Aug 5, 2024 at 6:39 PM Tony Li <[e-mail]> wrote:

> [WG chair hat: on]
>
> Hi Rakesh,
>
> Thank you for responding, but we need responses that directly address the
> question in the poll as stated.
>
> Regards,
> Tony
>
>
> On Aug 5, 2024, at 3:30 PM, Rakesh Gandhi <[e-mail]> wrote:
>
> Hi Tony,
>
>
> Although not directly related to the question in the poll but since PSD is
> mentioned in the title of this email for poll, like to highlight the
> certain advantages of adding IOAM data fields in Post-Stack Network Action
> for both post-card based and passport-based methods.
>
>
>
>    1. IOAM E2E/POT/TRACE/DEX option-types contain various data fields as
>    defined in RFC 9197 and RFC 9326
>    <https://datatracker.ietf.org/doc/html/rfc9326>.
>    2. Data fields such as 32-bit Sequence Number or 32-bit Timestamp in
>    In-Stack LSE can lead to undesired ECMP behavior on nodes that use labels
>    for ECMP hashing
>       - Data fields in Post-Stack are not included in ECMP hashing
>    3. 32-bit data fields do not fit into 30-bit data in In-Stack LSE,
>    limited to 11-bit as variable or mutable data
>    - RFC standard IOAM format data fields fit well into 32-bit Post-Stack
>       Network Action Data
>       4. IOAM option types support extensibility to optionally add many
>    data fields
>       - Node can easily skip In-Stack network action and process the next
>       one even when Data in Post-Stack is outside RLD
>    5. IOAM-DEX data fields can be seen as metadata in the received
>    packets that data plane exports
>       - Metadata could easily be in Post-Stack
>
>
> P.S. The IOAM network action and offset for the data fields for both IOAM
> methods would be in-stack. The above points are for the data fields.
>
> Thanks,
> Rakesh
>
>
> On Tue, Jul 30, 2024 at 11:27 AM Tony Li <[e-mail]> wrote:
>
>> [WG chair hat: on]
>>
>>
>> Hi all,
>>
>>
>> We’ve had many discussions about IOAM and PSD over the last few years. We
>> need to reach consensus on the problems that need to be addressed in these
>> areas. Therefore, we would like to hear from everyone, especially
>> independent operators:
>>
>>
>>
>>    1. There are many flavors of IOAM.  Which ones would you like to
>>    deploy/implement with MNA?
>>    2. Do you have other applications of MNA that have not been proposed
>>    yet?
>>
>>
>>  This poll will close in two weeks, at 9am PDT, Aug 13.
>>
>>
>> Regards,
>> MPLS chairs
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>