Re: [mpls] Question regarding RFC8595

Hi John, Greg & Haoyu

So following this thread related extending RFC 8595 functionality.

So the question Haoyu asked is if we can support NSH natively in the MPLS
data plane directly in a PSD container.

So the answer is yes it’s possible.

In summary..

We would use PSD mechanism “post stack” to support the NSH context header
from RFC 8595, Base Header, Service Path Header and Context Headers.  As
Haoyu pointed out we would need NAI to indicate the presence of the NSH in
post/stack data as well to avoid redundancy.  As pointed out by Greg, the
NAI would be “not” no-op as there could be specific actions to perform on
the packet, including the context header in PSD, before it’s passed on to
the appropriate SFF.

As John mentioned the RFC 8595 mechanisms could be supplemented by carrying
the NSH context headers all as post-stack data, however the mechanisms
defined in RFC 8595 for carrying the SFC traversal information {SPI, SI}
should be retained for the case of post-stack data without NAI.

I think this would be a good extension to RFC 8595 mechanisms.

Kind Regards

Gyan

On Tue, Apr 19, 2022 at 5:23 PM John E Drake <jdrake=
40juniper.net@dmarc.ietf.org> wrote:

> You’re right, so the NAI is probably not a no-op.
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Tuesday, April 19, 2022 5:04 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,
>
> 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$>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*