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
