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 Post-stack First Nibble (PFN) 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
> <[email protected]> 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 <[email protected]> wrote:
>>
>> Yes, thanks for you diligence, Jie. Those changes are needed.
>> Adrian
>>> On 20/06/2025 15:27 BST Dongjie (Jimmy) <[email protected]> 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 <[email protected]>
>>>> Sent: Friday, June 20, 2025 4:51 AM
>>>> To: Adrian Farrel <[email protected]>; Loa Andersson <[email protected]>;
>>>> Kireeti
>>>> Kompella <[email protected]>; Matthew Bocci (Nokia)
>>>> <[email protected]>; Greg Mirsky <[email protected]>;
>>>> Stewart Bryant <[email protected]>; Dongjie (Jimmy)
>>>> <[email protected]>; James Guichard <[email protected]>
>>>> Cc: RFC Editor <[email protected]>; [email protected];
>>>> [email protected];
>>>> MPLS Working Group <[email protected]>; auth48archive
>>>> <[email protected]>
>>>> 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 <[email protected]> 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
>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
