Hi Rebecca, This has been completed:
NSH 0x0 NSH Base Header, payload [RFC8300] Registry: https://www.iana.org/assignments/post-stack-first-nibble/ Thank you. Best regards, David Dong IANA Services Sr. Specialist On Tue Jul 01 17:36:31 2025, rvanrhee...@staff.rfc-editor.org wrote: > Hello IANA, > > Please update the Description column for NSH in the "Post-Stack First > Nibble" registry (https://www.iana.org/assignments/post-stack-first- > nibble) as follows: > > OLD: > NSH (Network Service Header) Base Header, payload > > NEW: > NSH Base Header, payload > > > If needed, here are the output files and the diff file: > > https://www.rfc-editor.org/authors/rfc9790.txt > https://www.rfc-editor.org/authors/rfc9790.pdf > https://www.rfc-editor.org/authors/rfc9790.html > https://www.rfc-editor.org/authors/rfc9790-alt-diff.html > > Thank you! > RFC Editor/rv > > > > > On Jul 1, 2025, at 10:33 AM, Rebecca VanRheenen > > <rvanrhee...@staff.rfc-editor.org> wrote: > > > > Kireeti and other authors, > > > > Kireeti - Thank you for confirming your approval! We have marked your > > approval on the AUTH48 status page for this document (see > > https://www.rfc-editor.org/auth48/rfc9790). > > > > All - All questions have been addressed, and we have received all > > author approvals. In a separate email, we will ask IANA to update the > > registry to match the edited document. Once that is complete, we will > > begin to prepare this document (and the other two documents in > > cluster 520) for publication. > > > > Best regards, > > RFC Editor/rv > > > > > > > > > >> On Jun 27, 2025, at 7:27 PM, Kireeti Kompella > >> <kireeti.i...@gmail.com> wrote: > >> > >> I do indeed approve of the doc in its current form. > >> > >> Kireeti. > >> > >>> On 26 Jun 2025, at 10:09, Rebecca VanRheenen > >>> <rvanrhee...@staff.rfc-editor.org> wrote: > >>> > >>> Hi Kireeti, > >>> > >>> Thank you for letting us know! We will retain Post-stack First > >>> Nibble/PFN. All questions have now been addressed. > >>> > >>> Can you let us know if you approve the document in its current > >>> form? > >>> > >>> Thank you, > >>> RFC Editor/rv > >>> > >>> > >>> > >>>> On Jun 26, 2025, at 5:30 AM, Kireeti Kompella > >>>> <kireeti.i...@gmail.com> wrote: > >>>> > >>>> Thank you, Rebecca. > >>>> > >>>> I’m fine with continuing to use Post-stack First Nibble/PFN. > >>>> > >>>> Kireeti. > >>>> > >>>>> On 23 Jun 2025, at 14:17, Rebecca VanRheenen > >>>>> <rvanrhee...@staff.rfc-editor.org> wrote: > >>>>> > >>>>> Hi Kireeti and Loa, > >>>>> > >>>>> Kireeti, thank you for your review and suggestions! We have > >>>>> updated the document accordingly, except for the following: > >>>>> > >>>>> Current: > >>>>> Post-stack First Nibble (PFN) > >>>>> > >>>>> Suggested: > >>>>> Post-Stack First Nibble (PFN) > >>>>> > >>>>> As Loa notes, the use of lowercase aligns the expansion with the > >>>>> chosen abbreviation, so we suggest leaving this as is. However, > >>>>> if all authors all agree to capitalize “-Stack” in this > >>>>> expansion, we suggest also adding “S” to the abbreviation (i.e., > >>>>> “PSFN”). Note that this would mean 31 updates of "PFN" to “PSFN”. > >>>>> Please let us know your thoughts. > >>>>> > >>>>> Note that once this is addressed, we will ask Jim (as AD) to > >>>>> review and approve the change in paragraph 3 of Section 2.5. > >>>>> > >>>>> — FILES (please refresh) — > >>>>> > >>>>> Updated XML file: > >>>>> https://www.rfc-editor.org/authors/rfc9790.xml > >>>>> > >>>>> Updated output files: > >>>>> https://www.rfc-editor.org/authors/rfc9790.txt > >>>>> https://www.rfc-editor.org/authors/rfc9790.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9790.html > >>>>> > >>>>> Diff file showing changes made during AUTH48: > >>>>> https://www.rfc-editor.org/authors/rfc9790-auth48diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html > >>>>> (side by side) > >>>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html > >>>>> (htmlwdiff diff between last version and this) > >>>>> https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html > >>>>> (rfcdiff between last version and this) > >>>>> > >>>>> Diff files showing all changes: > >>>>> https://www.rfc-editor.org/authors/rfc9790-diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html (side by > >>>>> side) > >>>>> https://www.rfc-editor.org/authors/rfc9790-alt-diff.html (diff > >>>>> showing changes where text is moved or deleted) > >>>>> > >>>>> For the AUTH48 status of this document, please see: > >>>>> https://www.rfc-editor.org/auth48/rfc9790 > >>>>> > >>>>> Thank you, > >>>>> RFC Editor/rv > >>>>> > >>>>> > >>>>>> On Jun 21, 2025, at 11:03 AM, Loa Andersson <l...@pi.nu> wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I'm OK with the change Section 2.5, para 3 of RFC 4385. > >>>>>> > >>>>>> I'm more uncertain about doing > >>>>>> > >>>>>> Post-Stack First Nibble (PFN) > >>>>>> > >>>>>> raather than > >>>>>> > >>>>>> Post-stack First Nibble (PFN) > >>>>>> > >>>>>> I thought capitalising in the name indicated the letters chosen > >>>>>> for the abbreviation. > >>>>>> > >>>>>> /Loa > >>>>>> > >>>>>> Den 21/06/2025 kl. 10:07, skrev Kireeti Kompella: > >>>>>>> Hi Rebecca, > >>>>>>> Apologies for the very late response. I seem to have lost the > >>>>>>> original email, but I do have this thread, so replying here. > >>>>>>> Thank you for the detailed review and the great work making > >>>>>>> this document immensely more readable! I sincerely appreciate > >>>>>>> it. > >>>>>>> Since several comments have been made and addressed, I looked > >>>>>>> at the “all changes” diffs and commented on them. Excuse the > >>>>>>> colorful cut-n- paste from the side-by-side diffs. > >>>>>>> There is one _important change_ that I suggest; this will need > >>>>>>> to be reviewed by the shepherd, the WG chairs and ADs. I'm > >>>>>>> putting it first. > >>>>>>> The rest of my comments are mostly NITs. Most things “Post- > >>>>>>> Stack” have a capital S, but “Post-stack First Nibble” > >>>>>>> consistently uses a lower case s. That bothers me, but it may > >>>>>>> be just me. > >>>>>>> There are a couple of indefinite articles that I think should > >>>>>>> be changed (one added, one deleted). Finally, an unwanted > >>>>>>> hyphen in “load balancing”, to be consistent. > >>>>>>> ——— > >>>>>>> Section 2.5, para 3 > >>>>>>> OLD > >>>>>>> Obsoleting the use of a PSH for non-IP payloads encapsulated in > >>>>>>> MPLS > >>>>>>> would assist with the progress toward a simpler, more coherent > >>>>>>> system > >>>>>>> of MPLS data encapsulation. However, before that can be done, > >>>>>>> it is ... > >>>>>>> NEW > >>>>>>> RFC 4385, Section 2 suggests the use of a PSH solely for the > >>>>>>> purpose > >>>>>>> of avoiding IP ECMP treatment of non-IP payloads encapsulated > >>>>>>> in MPLS. > >>>>>>> Obsoleting this use of a PSH would assist with the progress > >>>>>>> toward a > >>>>>>> simpler, more coherent system of MPLS data encapsulation. > >>>>>>> (Other uses > >>>>>>> of a PSH may still be valid.) However, before that can be > >>>>>>> done, it is ... > >>>>>>> ——— > >>>>>>> Section 1, para 1 > >>>>>>> /* NIT */ > >>>>>>> OLD > >>>>>>> correct interpretation of the : > >>>>>> > >>>>>> > >>>>>> in a PSH > >>>>>>> NEW > >>>>>>> correct interpretation of the Post-Stack First Nibble (PFN) in > >>>>>>> a PSH > >>>>>>> Section 1, para 7 > >>>>>>> /*NIT*/ > >>>>>>> OLD > >>>>>>> this document enable a more robust network operation. > >>>>>>> NEW > >>>>>>> this document enable more robust network operation. > >>>>>>> Section 1.2, para 6 > >>>>>>> /* NIT */ > >>>>>>> OLD > >>>>>>> Post-stack First Nibble (PFN): The most significant four bits > >>>>>>> of the > >>>>>>> NEW > >>>>>>> Post-Stack First Nibble (PFN): The most significant four bits > >>>>>>> of the > >>>>>>> Section 1.3 > >>>>>>> /* NIT */ > >>>>>>> OLD > >>>>>>> PFN: Post-stack First Nibble > >>>>>>> NEW > >>>>>>> PFN: Post-Stack First Nibble > >>>>>>> Section 1.4 > >>>>>>> OLD > >>>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without > >>>>>>> Preceding Post-Stack Header > >>>>>>> NEW > >>>>>>> Figure 2: Examples of an MPLS Packet Payload With and Without > >>>>>>> a Preceding Post-Stack Header > >>>>>>> Section 2.1.1.1, para 4 > >>>>>>> OLD > >>>>>>> heuristic can work very badly for non-IP packet as shown in > >>>>>>> example B > >>>>>>> in Figure 2. For example, if payload B is an Ethernet frame, > >>>>>>> then > >>>>>>> NEW > >>>>>>> heuristic can work very badly for the non-IP packet as shown in > >>>>>>> example > >>>>>>> B in Figure 2. For example, if payload B is an Ethernet frame, > >>>>>>> then > >>>>>>> Section 2.2, para 5 > >>>>>>> /* NIT */ > >>>>>>> OLD > >>>>>>> | (Post-stack First Nibble) value that is neither 0x4 nor 0x6 > >>>>>>> in all > >>>>>>> NEW > >>>>>>> | (Post-Stack First Nibble) value that is neither 0x4 nor 0x6 > >>>>>>> in all > >>>>>>> Section 2.2, last para > >>>>>>> /*NIT*/ > >>>>>>> | PFN: Post-stack First Nibble > >>>>>>> NEW > >>>>>>> | PFN: Post-Stack First Nibble > >>>>>>> Section 2.5, para 3 > >>>>>>> OLD > >>>>>>> or deployed implementations using the heuristic practice to > >>>>>>> load- > >>>>>>> balancing MPLS data flows. > >>>>>>> NEW > >>>>>>> or deployed implementations using the heuristic practice to > >>>>>>> load > >>>>>>> balancing MPLS data flows. > >>>>>>> (Frankly, I would prefer “to load balance MPLS data flows” to > >>>>>>> “to load balancing …”.) > >>>>>>> Kireeti. > >>>>>>>> On 20 Jun 2025, at 22:18, Rebecca VanRheenen > >>>>>>>> <rvanrhee...@staff.rfc- editor.org> wrote: > >>>>>>>> > >>>>>>>> Hello all, > >>>>>>>> > >>>>>>>> Thank you for the replies. We added the sentence that Loa > >>>>>>>> suggested to the Acknowledgments section with a small edit. We > >>>>>>>> also incorporated the changes sent by Jie. These changes are > >>>>>>>> best viewed in the alt-diff or lastdiff files listed below. > >>>>>>>> > >>>>>>>> Loa and Stewart, we have marked your approvals on the AUTH48 > >>>>>>>> status page for this document. Jim, we have also marked your > >>>>>>>> AD approval. See https://www.rfc-editor.org/auth48/rfc9790. > >>>>>>>> > >>>>>>>> We are now waiting for approvals or further updates from Jie > >>>>>>>> and Kireeti. > >>>>>>>> > >>>>>>>> — FILES (please refresh) — > >>>>>>>> > >>>>>>>> Updated XML file: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790.xml > >>>>>>>> > >>>>>>>> Updated output files: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790.txt > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790.html > >>>>>>>> > >>>>>>>> Diff file showing changes made during AUTH48: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-auth48diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-auth48rfcdiff.html > >>>>>>>> (side by side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html > >>>>>>>> (htmlwdiff diff between last version and this) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html > >>>>>>>> (rfcdiff between last version and this) > >>>>>>>> > >>>>>>>> Diff files showing all changes: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html (side > >>>>>>>> by side) > >>>>>>>> https://www.rfc-editor.org/authors/rfc9790-alt-diff.html (diff > >>>>>>>> showing changes where text is moved or deleted) > >>>>>>>> > >>>>>>>> For the AUTH48 status of this document, please see: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9790 > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> RFC Editor/rv > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Jun 20, 2025, at 11:36 AM, Adrian Farrel > >>>>>>>>> <adr...@olddog.co.uk> wrote: > >>>>>>>>> > >>>>>>>>> Yes, thanks for you diligence, Jie. Those changes are needed. > >>>>>>>>> Adrian > >>>>>>>>>> On 20/06/2025 15:27 BST Dongjie (Jimmy) > >>>>>>>>>> <jie.d...@huawei.com> wrote: > >>>>>>>>>> Hi Rebecca, > >>>>>>>>>> Thanks for the effort on this update. > >>>>>>>>>> The update to the definition of "MPLS payload" and "Post- > >>>>>>>>>> Stack Header (PSH)" looks good. While I found that in > >>>>>>>>>> section 1.4, there is one usage of "MPLS payload" which > >>>>>>>>>> needs to be updated to align with the current definition. > >>>>>>>>>> OLD: > >>>>>>>>>> Example C: This example is an MPLS Payload that starts with > >>>>>>>>>> a PSH followed by the embedded packet. Here, the embedded > >>>>>>>>>> packet could be IP or non-IP. > >>>>>>>>>> Since the current definition says the MPLS Payload is after > >>>>>>>>>> the label stack and optional PSHs, the text in this example > >>>>>>>>>> also needs to be updated. > >>>>>>>>>> Here is the suggested text: > >>>>>>>>>> NEW: > >>>>>>>>>> Example C: This example is an MPLS Payload that follows a > >>>>>>>>>> PSH. Here, the embedded packet could be IP or non-IP. > >>>>>>>>>> And the title of Figure 2 needs to be updated accordingly: > >>>>>>>>>> OLD: > >>>>>>>>>> Figure 2: Examples of an MPLS Packet Payload With and > >>>>>>>>>> Without Post- Stack Header. > >>>>>>>>>> New: > >>>>>>>>>> Figure 2: Examples of an MPLS Packet Payload With and > >>>>>>>>>> Without Preceding Post-Stack Header > >>>>>>>>>> Hope this helps. > >>>>>>>>>> Best regards, > >>>>>>>>>> Jie > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > >>>>>>>>>>> Sent: Friday, June 20, 2025 4:51 AM > >>>>>>>>>>> To: Adrian Farrel <adr...@olddog.co.uk>; Loa Andersson > >>>>>>>>>>> <l...@pi.nu>; Kireeti > >>>>>>>>>>> Kompella <kireeti.i...@gmail.com>; Matthew Bocci (Nokia) > >>>>>>>>>>> <matthew.bo...@nokia.com>; Greg Mirsky > >>>>>>>>>>> <gregimir...@gmail.com>; > >>>>>>>>>>> Stewart Bryant <s...@stewartbryant.com>; Dongjie (Jimmy) > >>>>>>>>>>> <jie.d...@huawei.com>; James Guichard > >>>>>>>>>>> <james.n.guich...@futurewei.com> > >>>>>>>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; m...@ietf.org; > >>>>>>>>>>> mpls- a...@ietf.org; > >>>>>>>>>>> MPLS Working Group <mpls-cha...@ietf.org>; auth48archive > >>>>>>>>>>> <auth48archive@rfc-editor.org> > >>>>>>>>>>> Subject: [AD] Re: AUTH48: RFC-to-be 9790 <draft-ietf- mpls- > >>>>>>>>>>> 1stnibble-13> > >>>>>>>>>>> Hi Adrian, authors, and Jim*, > >>>>>>>>>>> Adrian - Thank you for providing the updated text. We have > >>>>>>>>>>> updated the files > >>>>>>>>>>> accordingly (see list of files below) > >>>>>>>>>>> Authors - Please let us know if you approve of the document > >>>>>>>>>>> in its current form > >>>>>>>>>>> or if any further updates are needed. > >>>>>>>>>>> *Jim - As AD, please review the changes to the definitions > >>>>>>>>>>> for "MPLS Payload” > >>>>>>>>>>> and "Post-Stack Header (PSH)” in Section 1.2 and let us > >>>>>>>>>>> know if you approve. > >>>>>>>>>>> These changes are best viewed in this diff file: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html. > >>>>>>>>>>> — FILES (please refresh) — > >>>>>>>>>>> Updated XML file: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790.xml Updated > >>>>>>>>>>> output files: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790.txt > >>>>>>>>>>> https://www.rfc- editor.org/authors/rfc9790.pdf > >>>>>>>>>>> https://www.rfc-editor.org/authors/ rfc9790.html Diff > >>>>>>>>>>> file showing changes made during AUTH48: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-auth48diff.html > >>>>>>>>>>> https:// www.rfc-editor.org/authors/rfc9790- > >>>>>>>>>>> auth48rfcdiff.html (side by side) > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastdiff.html > >>>>>>>>>>> (htmlwdiff diff > >>>>>>>>>>> between last version and this) > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-lastrfcdiff.html > >>>>>>>>>>> (rfcdiff between > >>>>>>>>>>> last version and this) > >>>>>>>>>>> Diff files showing all changes: > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-diff.html > >>>>>>>>>>> https:// www.rfc-editor.org/authors/rfc9790-rfcdiff.html > >>>>>>>>>>> (side by side) > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790-alt-diff.html > >>>>>>>>>>> (diff showing > >>>>>>>>>>> changes where text is moved or deleted) > >>>>>>>>>>> For the AUTH48 status of this document, please see: > >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9790 Thank you, > >>>>>>>>>>> RFC Editor/rv > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Jun 18, 2025, at 1:20 PM, Adrian Farrel > >>>>>>>>>>>> <adr...@olddog.co.uk> wrote: > >>>>>>>>>>>> RFC Editor (Rebecca), authors, Working Group, > >>>>>>>>>>>> Document Shepherd here. > >>>>>>>>>>>> This document seemed to stagnate over the discussion of a > >>>>>>>>>>>> couple of minor > >>>>>>>>>>> editorial points. So I have been chatting with Greg and > >>>>>>>>>>> Loa, and we have > >>>>>>>>>>> agreed some changes that seem to address the concerns. > >>>>>>>>>>>> > >>>>>>>>>>>> I have based these changes on the text at > >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9790.txt > > >>>>>>>>>>>> Section 1.2 > >>>>>>>>>>>> OLD > >>>>>>>>>>>> MPLS Payload: All data after the label stack and the > >>>>>>>>>>>> optional Post- > >>>>>>>>>>>> Stack header. > >>>>>>>>>>>> NEW > >>>>>>>>>>>> MPLS Payload: All data after the label stack and any > >>>>>>>>>>>> optional PSHs. It > >>>>>>>>>>>> is possible that more than one type of PSH may be present > >>>>>>>>>>>> in a > >>>>>>>>>>>> packet, and some PSH specifications might allow multiple > >>>>>>>>>>>> PSHs of > >>>>>>>>>>>> the same type. The presence rules for multiple PSHs are a > >>>>>>>>>>>> matter > >>>>>>>>>>>> for the documents that define those PSHs, e.g., in > >>>>>>>>>>>> [I-D.ietf-mpls-mna-ps-hdr]. > >>>>>>>>>>>> END > >>>>>>>>>>>> Section 1.2 > >>>>>>>>>>>> OLD > >>>>>>>>>>>> Post-Stack Header (PSH): A field containing information > >>>>>>>>>>>> that may be > >>>>>>>>>>>> of interest to the egress Label Switching Router (LSR) or > >>>>>>>>>>>> transit > >>>>>>>>>>>> LSRs. Examples include a control word [RFC4385] [RFC8964] > >>>>>>>>>>>> or an > >>>>>>>>>>>> associated channel header [RFC4385] [RFC5586] [RFC9546]. A > >>>>>>>>>>>> parser > >>>>>>>>>>>> needs to be able to determine where the PSH ends in order > >>>>>>>>>>>> to find > >>>>>>>>>>>> the embedded packet. > >>>>>>>>>>>> NEW > >>>>>>>>>>>> Post-Stack Header (PSH): A field containing information > >>>>>>>>>>>> that may be > >>>>>>>>>>>> of interest to the egress Label Switching Router (LSR) or > >>>>>>>>>>>> transit > >>>>>>>>>>>> LSRs. Examples include a control word [RFC4385] [RFC8964] > >>>>>>>>>>>> or an > >>>>>>>>>>>> associated channel header [RFC4385] [RFC5586] [RFC9546]. > >>>>>>>>>>>> END > >>>>>>>>>>>> > >>>>>>>>>>>> I hope with these two changes, all of the authors can > >>>>>>>>>>>> confirm their AUTH48 > >>>>>>>>>>> proposal. > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Adrian > >>>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Loa Andersson > >>>>>> Senior MPLS Expert > >>>>>> Bronze Dragon Consulting > >>>>>> l...@pi.nu > >>>>>> loa.pi....@gmail.com > >>>>>> > >>>>> > >>>> > >>> > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
