[mpls] Re: Poll: IOAM and PSD

[Haoyu Song <[e-mail]>]

Hi Greg,

Even though the interoperation between MPLS and IPvx is not currently considered in MNA, we cannot rule out the possibility and make it difficult or impossible for the future. As you mentioned, overlay, VPN, and SFCs are all practical scenarios. We eventually need to tackle these issues.

Regards,
Haoyu

From: Greg Mirsky <[e-mail]>
Sent: Sunday, August 11, 2024 8:31 AM
To: Haoyu Song <[e-mail]>
Cc: Tony Li <[e-mail]>; mpls <[e-mail]>
Subject: Re: [mpls] Re: Poll: IOAM and PSD


Hi Haoyu,

as I understand, examples of a limited domain listed in RFC 8799<https://datatracker.ietf.org/doc/html/rfc8799>, although a VPN service or a Service Function Chain are presented as examples of a limited domain network, on the data plane level, it is always a single technology, i.e., either MPLS or IPvX. Hence, IOAM's domain will be either MPLS or IPv6 network. Of course, IOAM may be applied at the overlay layer, which, in turn, spans over underlay that may use different techniques. However, as I understand our discussion about the MNA, I think it is outside its scope.



Regards,

Greg

On Sat, Aug 10, 2024 at 5:07 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

I think a limited domain or controlled environment can contain networks with different protocols, as long as they are under the same administration. I couldn’t find anything against this possibility.

Best,
Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 8, 2024 5:03 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Poll: IOAM and PSD

Hi Haoyu,
could you help me understanding how you envision using IOAM across several domains. As I understand RFC 9197, IOAM domain follows the definition of a limited domain (RFC 8799) and the decapsulating IOAM node is in the same administrative domain as the corresponding encapsulating IOAM node. AFAICS, RFC 9197 precludes scenario where IOAM encapsulating packet crosses from one administrative domain into another. Am I missing something?

Regards,
Greg

On Thu, Aug 8, 2024 at 4:35 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Tony,

My response is inline.

Regards,
Haoyu

From: Tony Li <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Tuesday, July 30, 2024 8:26 AM
To: mpls <[e-mail]<mailto:[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?



[HS] I’d like MNA to support IOAM DEX and Trace option as specified in RFC9326 and RFC9197 using PSD. The reasons are:

     *   Comply with existing standards, can be directly used without any hassle
     *   Support potential cross-domain interoperation (e.g., cross the boundary of MPLS domain and non-MPLS domain)
     *   IOAM trace (i.e., the passport mode) is very useful in many realtime measurement/congestion control applications (e.g., HPCC and tons of published research papers), therefore it has great potential for future wider application.



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



[HS] I’d like to see a simple flag-based action to support the postcard mode telemetry.

I’d like also see the support of application level ID and metadata to better support the application-aware networking.



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



Regards,

MPLS chairs

_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>