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
