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
