[mpls] Re: Poll: IOAM and PSD

["Zafar Ali (zali)" <[e-mail]>]

Dear WG chairs and the WG,

Sorry for the late response to the email; it was due to post-IETF Summer PTO (I wonder if other participants will be in a similar boat).

Like Loa, I also need clarification about the intended use of the poll.
If the intended use of this poll is to close the door on the future use of PSD in MNA, then I must say that the poll is unclear.
I also agree with Toerless that it is too early and premature to make any such decisions.

For the technical reasons Toerless mentioned, I am interested in implementing PSD for the proof of transit use case. However, I am sure things will evolve, and my and the industry’s interest in the other use cases (not covered by the poll) will grow/ emerge.

Thanks

Regards … Zafar

From: Toerless Eckert <[e-mail]>
Date: Tuesday, August 6, 2024 at 12:14 PM
To: Tony Li <[e-mail]>
Cc: mpls <[e-mail]>
Subject: [mpls] Re: Poll: IOAM and PSD
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]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]