All, I don’t think we want to go to PSFN, we should stay with PFN and expand it as we do now.
/Loa On Mon, 23 Jun 2025 at 23:19, 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 > > > > _______________________________________________ > mpls mailing list -- m...@ietf.org > To unsubscribe send an email to mpls-le...@ietf.org >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
