Re: [mpls] Question regarding RFC8595

Hi John,
many thanks for your expedient response. I imagine that a node interested
in that indicator has SFF functionality. From the point of view of the SFF,
there will be specific actions to perform on the packet, including Context
Header in PSD, before it can be passed to the appropriate SF.

Regards,
Greg

On Tue, Apr 19, 2022 at 1:53 PM John E Drake <jdrake@juniper.net> wrote:

> Greg,
>
>
>
> I completely agree.  As Haoyu pointed out, we would probably have to
> define a no-op NAI just to indicate the presence of the NSH in post-stack
> data.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Tuesday, April 19, 2022 4:49 PM
> *To:* John E Drake <jdrake@juniper.net>
> *Cc:* Haoyu Song <haoyu.song@futurewei.com>; draft-ietf-mpls-sfc@ietf.org;
> mpls@ietf.org
> *Subject:* Re: [mpls] Question regarding RFC8595
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi John,
>
> in the course of working on the draft-saad-mpls-miad-usecases, the authors
> agreed that the mechanism defined in RFC 8595 might need a further
> extension to support NSH Context Header, fixed-sized and variable-length.
> The next version of the draft reflects that. I agree that PSD seems a
> logical mechanism to support the NSH Context Header in the context of RFC
> 8595. Using PSD to carry the entire NSH, i.e., the combination of Base
> Header, Service Path Header, and Context Header(s), in the paradigm of RFC
> 8595 seems to be sub-optimal.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 19, 2022 at 12:40 PM John E Drake <jdrake=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Haoyu,
>
>
>
> I think RFC 8595 could be supplemented by carrying the NSH as post-stack
> data.  I think the existing mechanisms defined in RFC 8595 for carrying SFC
> traversal information should be retained, so we may have a case for
> post-stack data without an NAI.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of *Haoyu Song
> *Sent:* Tuesday, April 19, 2022 2:23 PM
> *To:* draft-ietf-mpls-sfc@ietf.org
> *Cc:* mpls@ietf.org
> *Subject:* [mpls] Question regarding RFC8595
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear RFC8595 authors,
>
>
>
> I have a question. RFC8595 provides a method to emulate NSH in MPLS data
> plane.
>
> Now we are working on defining a new framework to support network actions
> in MPLS data plane.
>
> Once we have that, do you think it’s possible and useful to support NSH
> natively in MPLS data plane? That is, to put NSH directly in post-stack
> data (PSD) container.
>
> What I see an advantage is NSH can carry metadata while the emulating
> approach can’t.
>
> I’m not an expert of NSH so I need your thoughts on this. Thank you very
> much!
>
>
>
> Best regards,
>
> Haoyu
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!TGvzeC7orsodMr0EPfFer2eHVLxT2JPLAraDom7ogmoi_Axd2ZaWQLAJx2txL-w$>
>
>