[mpls] Re: Poll: IOAM and PSD

[Greg Mirsky <[e-mail]>]

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]> 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]>
> *Sent:* Thursday, August 8, 2024 5:03 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tony Li <[e-mail]>; mpls <[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]>
> wrote:
>
> Hi Tony,
>
>
>
> My response is inline.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Tony Li <[e-mail]> *On Behalf Of *Tony Li
> *Sent:* Tuesday, July 30, 2024 8: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?
>
>
>
> [HS] I’d like MNA to support IOAM DEX and Trace option as specified in
> RFC9326 and RFC9197 using PSD. The reasons are:
>
>    1. Comply with existing standards, can be directly used without any
>       hassle
>       2. Support potential cross-domain interoperation (e.g., cross the
>       boundary of MPLS domain and non-MPLS domain)
>       3. 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.
>
>
>
>    2. 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]
> To unsubscribe send an email to [e-mail]
>
>