Authors, IANA has updated the registry to match the edited document. We now consider AUTH48 complete; see https://www.rfc-editor.org/auth48/rfc9790.
We will prepare this document (along with the other documents in cluster 520) for publication at this time. Thank you for your attention and guidance during the AUTH48 process! Best regards, RFC Editor/rv > On Jul 2, 2025, at 10:51 AM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi David, > > The change looks great. > > Thank you! > RFC Editor/rv > > >> On Jul 1, 2025, at 7:22 PM, David Dong via RT <iana-mat...@iana.org> wrote: >> >> Hi Rebecca, >> >> This has been completed: >> >> NSH 0x0 NSH Base Header, payload [RFC8300] >> >> Registry: >> https://www.iana.org/assignments/post-stack-first-nibble/ >> >> Thank you. >> >> Best regards, >> >> David Dong >> IANA Services Sr. Specialist >> >> On Tue Jul 01 17:36:31 2025, rvanrhee...@staff.rfc-editor.org wrote: >>> 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
