[mpls] Re: Poll: IOAM and PSD

[IJsbrand Wijnands <[e-mail]>]

+1

> On 13 Aug 2024, at 08:09, Zafar Ali (zali) <zali=[e-mail]> wrote:
> 
> 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]
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]