Re: [mpls] Question regarding RFC8595

[Joel Halpern <[e-mail]>]

I would note in passing that one can also simply use MPLS as the 
transport between SFF, and carry NSH as the payload.  And use the NSH 
defined path identification.    And there are multiple variations on 
this which work.  See draft-ietf-spring-nsh-sr.

Yours,

Joel

On 4/19/2022 5:22 PM, John E Drake wrote:
>
> You’re right, so the NAI is probably not a no-op.
>
> Yours Irrespectively,
>
> John
>
> Juniper Business Use Only
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Tuesday, April 19, 2022 5:04 PM
> *To:* John E Drake <[e-mail]>
> *Cc:* Haoyu Song <[e-mail]>; 
> [e-mail]; [e-mail]
> *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 <[e-mail]> 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 <[e-mail]>
>     *Sent:* Tuesday, April 19, 2022 4:49 PM
>     *To:* John E Drake <[e-mail]>
>     *Cc:* Haoyu Song <[e-mail]>;
>     [e-mail]; [e-mail]
>     *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=[e-mail]> 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 <[e-mail]> *On Behalf Of *Haoyu Song
>         *Sent:* Tuesday, April 19, 2022 2:23 PM
>         *To:* [e-mail]
>         *Cc:* [e-mail]
>         *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
>         [e-mail]
>         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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls