[mpls] Re: Poll: IOAM and PSD

[Toerless Eckert <[e-mail]>]

On Tue, Jul 30, 2024 at 08:25:55AM -0700, Tony Li 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:
>  
> There are many flavors of IOAM.  Which ones would you like to deploy/implement with MNA?

I have no specific preference for flavor at this time as i have not
investigated this topic sufficiently. In doubt, i would love to see
an option investigated which was brought up very early in the MNA discussion
by i think Lenny or Jeffrey - trying to use a common PSD format that would
make support/implementation across both MPLS and IPv6 as easy as possible,
so that we minimize unnecessary design differences.

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

I don't have applications ready to propose because IMHO of the difficult
chicken & egg problem between the use-case and the necessary encapsulation
for MPLS and IP. Specifically i think that there is a wide range of mostly
per-hop QoS mechanisms that each have their interested community, but none
sufficiently strong to ask for their own MPLS or IP header format.

I have started to collect a few example of such QoS mechanisms, most of them
from bounded-latency mechanisms proposed to the DetNet WG, and summarized them
in draft-eckert-6man-qos-exthdr-discuss. 

I would hope that we could generate a future MNA ask for siuch QoS use-cases
in the future, if/when we come to the conclusion that we would accellerate
adoption of such QoS mechanisms if we do not re-invet headers for each of them,
but just deal with them in a manner of "TC/DSCP on steroids" - aka: define
configurable header fields so that we'd ultimately end up with one header and
the rest would be per-machanism overloaded/configured parameters in such header
(same as DSCP/TC are  overloaded by various per-hop QoS mechansism).

At this point in time, i would be happy of more participants would show interest
in such an evolution, and if MNA would not close the door for future PSD work.
And ideally also considering PSD work that does not unnecessarily introduce
ISD overhead when it is not needed, because the PSD data would be sufficiently
well self-identifying, especially when defined such that it would be as much as
possible consistenty with an IPv6 extension header.

Cheers
    Toerless


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


-- 
---
[e-mail]