Re: [mpls] Question regarding RFC8595

[John E Drake <[e-mail]>]

This is discussed in RFC 9015.

Yours Irrespectively,

John



Juniper Business Use Only
From: Joel Halpern <[e-mail]>
Sent: Thursday, April 28, 2022 9:39 PM
To: John E Drake <[e-mail]>; Greg Mirsky <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] Question regarding RFC8595

[External Email. Be cautious of content]


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]><mailto:[e-mail]>
Sent: Tuesday, April 19, 2022 5:04 PM
To: John E Drake <[e-mail]><mailto:[e-mail]>
Cc: Haoyu Song <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, April 19, 2022 4:49 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: Haoyu Song <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Haoyu Song
Sent: Tuesday, April 19, 2022 2:23 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!RwpjDI93dMedofbI7v9Ay5PpJvSbOSPTe-kSDU_RKf8TiBPHb0kXS_dfVfp5Dec$>