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
