[mpls] Re: [IANA #1422440] [IANA] Re: [AD] AUTH48: RFC-to-be 9790 <draft-ietf-mpls-1stnibble-13>

[Rebecca VanRheenen <[e-mail]>]

Hi David,

The change looks great.

Thank you!
RFC Editor/rv


> On Jul 1, 2025, at 7:22 PM, David Dong via RT <[e-mail]> 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, [e-mail] 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
>>> <[e-mail]> 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
>>>> <[e-mail]> wrote:
>>>> 
>>>> I do indeed approve of the doc in its current form.
>>>> 
>>>> Kireeti.
>>>> 
>>>>> On 26 Jun 2025, at 10:09, Rebecca VanRheenen
>>>>> <[e-mail]> 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
>>>>>> <[e-mail]> 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
>>>>>>> <[e-mail]> 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 <[e-mail]> 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
>>>>>>>>>> <[e-mail]- 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
>>>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Yes, thanks for you diligence, Jie. Those changes are needed.
>>>>>>>>>>> Adrian
>>>>>>>>>>>> On 20/06/2025 15:27 BST Dongjie (Jimmy)
>>>>>>>>>>>> <[e-mail]> 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 <[e-mail]>
>>>>>>>>>>>>> Sent: Friday, June 20, 2025 4:51 AM
>>>>>>>>>>>>> To: Adrian Farrel <[e-mail]>; Loa Andersson
>>>>>>>>>>>>> <[e-mail]>; Kireeti
>>>>>>>>>>>>> Kompella <[e-mail]>; Matthew Bocci (Nokia)
>>>>>>>>>>>>> <[e-mail]>; Greg Mirsky
>>>>>>>>>>>>> <[e-mail]>;
>>>>>>>>>>>>> Stewart Bryant <[e-mail]>; Dongjie (Jimmy)
>>>>>>>>>>>>> <[e-mail]>; James Guichard
>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>> Cc: RFC Editor <[e-mail]>; [e-mail];
>>>>>>>>>>>>> mpls- [e-mail];
>>>>>>>>>>>>> MPLS Working Group <[e-mail]>; auth48archive
>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <[e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> [e-mail]
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>