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
