Cheers
Matthew
*From: *Loa Andersson <l...@pi.nu>
*Date: *Thursday, 15 May 2025 at 06:45
*To: *Tony Li <tony...@tony.li>, RFC Errata System <rfc-editor@rfc-
editor.org>
*Cc: *Stewart Bryant <s...@stewartbryant.com>, Matthew Bocci (Nokia)
<matthew.bo...@nokia.com>, mpls-...@ietf.org <mpls-...@ietf.org>, mpls-
chairs <mpls-cha...@ietf.org>, ts...@cisco.com <ts...@cisco.com>, James
Guichard <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org
<auth48archive@rfc-editor.org>
*Subject: *Re: AUTH48: RFC-to-be 9789 <draft-ietf-mpls-mna-fwk-15> for
your review
CAUTION: This is an external email. Please be very careful when clicking
links or opening attachments. See the URL nok.it/ext for additional
information.
Hi,
I had also started tyo to through the questions, but will add to Tony's
mail since it is more complete then mine.
Den 15/05/2025 kl. 05:56, skrev Tony Li:
Hi,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Per use in RFCs 9613, we updated the expansion for MNA from
"MPLS
Network Actions" (plural "Actions") to "MPLS Network Action" (singular
"Action"). Note that we also made this change in the abstract and
introduction. However, if you prefer to use the plural, perhaps we can update as
follows.
Original (document title):
MPLS Network Actions (MNA) Framework
Current:
MPLS Network Action (MNA) Framework
Perhaps:
Framework for MPLS Network Actions (MNAs)
-->
The ‘Current’ version is fine.
I don't understand this, RFC 9613 has the plural:
RFC 9613
Requirements for Solutions that Support MPLS Network Actions (MNAs)
I still think that the Original is best:
MPLS Network Actions (MNA) Framework
Caveat, this is English grammar and I normally defer to the RFC Editor
and my co-authors, but I don't understand why we'd do the two RFC
differently. That said I also think that the plural s in the RFC 9613
abbreviation could be dropped, but not important enough for me to create
an errata. The only thing that could happen with the plurarl s there is
that if someone searches the documents for MNAs, it will not find MNA.
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search
<https://www.rfc-editor.org/search>. -->
Some suggestions: “network function virtualization”, “service chaining”.
The general problem here is that MNA is an extension mechanism that could be
made to do just about anything. “Kitchen sink” doesn’t seem like it’s
constructive, but it would be accurate. :-)
Agree with Tony.
3) <!-- [rfced] Will readers understand which items are part of the series here?
Does one of the following accurately convey the intended meaning?
Original:
These might include
load-balancing a packet given its entropy, whether or not to perform
fast-reroute on a failure, and whether or not a packet has metadata
relevant to the forwarding actions along the path.
Perhaps (entropy, whether or not..., whether or not...):
These might include
load-balancing a packet given its entropy, whether or not
fast-reroute is performed on a failure, and whether or not a packet has
metadata
relevant to the forwarding actions along the path.
Or (load-balancing, indicating, indicating):
These might include
load-balancing a packet given its entropy, indicating whether or not to
perform
Fast Reroute on a failure, and indicating whether or not a packet has
metadata
relevant to the forwarding actions along the path.
-->
Either alternative seems fine.
Yes, agree. But have a (very slight) preference for the second alternative.
4) <!-- [rfced] We have a few questions about the similar text below from
Sections 1.2 and 2.
a) Please confirm that NSI is the correct acronym for "Network Action
Sub-Stack Indicator". Should it be "NASI" rather than "NSI" to correspond with
"Network Action Indicator (NAI)" and "Network Action Sub-Stack (NAS)"?
NSI is correct, but we’re not married to it. If there is a good reason to
change, we can.
Yes, we did not like NASI.
b) Is the NSI the special-purpose label? If so, may we update the definition
below as follows?
The NSI is the entire LSE, which includes the SPL.
Ack.
c) The second definition below mentions "MNA label", but the first does
not. Also, one definition uses "special label", and the other uses
"special-purpose label". Are any updates needed?
Original:
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
contains a special label that indicates the start of the NAS.
...
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
contains a special purpose label, called the MNA label, which is
used to indicate the start of a network action sub-stack.
Perhaps:
Network Action Sub-Stack Indicator (NASI): The special-purpose label
contained
in the first LSE in the NAS. The NSI, also called the MNA label,
indicates
the start of the NAS.
...
* Network Action Sub-Stack Indicator (NASI): The special-purpose label
contained
in the first LSE in the NAS. The NSI, also called the MNA label,
indicates
the start of the NAS.
I prefer the orignal but s/a special label/a special purpose label/
-->
Perhaps:
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
The NSI contains a special label that indicates the start of the NAS.
* Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS.
The NSI contains a special purpose label, called the MNA label, which is
used to indicate the start of a network action sub-stack.
5) <!-- [rfced] We see that "sub-stacks" (plural) is used early in the sentence
and "sub-stack" (singular) is used later. Is the current correct, or
should both instances be either plural or singular?
Original:
A solution must specify where in the label stack the network
actions sub-stacks occur, if and how frequently they should be
replicated within the label stack, and how the network action sub-
stack and post-stack data are encoded.
-->
Multiple sub-stacks are permissible and expected, so plural throughout would
make more sense.
I'm not sure about this, there are places when we talk abour "a
sub-stack" and "the sb-stack", I think this should stay singular.
6) <!-- [rfced] This sentence includes two instances of "post-stack data".
Please
confirm that this is correct.
Original:
As an example, post-stack data might appear as a label stack followed
by post-stack data, followed by the payload:
Perhaps:
As an example, post-stack data might appear in a label stack, followed
by the payload:
-->
The original is correct.
If it helps clarify things, we might also say:
As an example, a packet containing post-stack data might contain a label stack
followed by post-stack data, followed by the payload:
Agree with Tony.
7) <!-- [rfced] Would updating "not more than one" to simply "one" or "a single"
improve readability of this sentence?
Original:
This document assumes that the MPLS WG will select not more than one
solution for the encoding of ISD and not more than one solution for
the encoding of PSD.
Perhaps:
This document assumes that the MPLS WG will select a single
solution for the encoding of ISD and a single solution for
the encoding of PSD.
-->
That would be ok. There was considerable confusion that we might select more
than one and a distinct possibility of selecting zero, but that has passed.
Agree with Tony the the "Perhaps" is clearer.
8) <!-- [rfced] FYI - We updated the parenthetical as shown below.
Original:
A node SHOULD use signaling
(e.g., [RFC9088], [RFC9089]) to determine this.
Updated:
A node SHOULD use signaling
(e.g., the signaling described in [RFC9088] and [RFC9089]) to determine
this.
-->
That’s not an improvement, IMHO, but acceptable.
I think the "Updated" is beter.
9) <!-- [rfced] Should the text introducing the list indicate if the value is
"from one of the following" or "each of the following"? Or will readers
understand?
Original:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from:
* The RLD advertised for the link.
* The RLD advertised for the node.
* The non-zero ERLD for the node.
Perhaps:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from one of the following:
* The RLD advertised for the link
* The RLD advertised for the node
* The non-zero ERLD for the node
Or:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from each of the following:
* The RLD advertised for the link
* The RLD advertised for the node
* The non-zero ERLD for the node
-->
I think the original is clear, but if you dislike that, another version might
be:
An MNA node MUST use the RLD determined by selecting the first
advertised non-zero value from the following:
I would go with Tony's suggestion.
10) <!-- [rfced] Each definition below includes a number of bits except for
TTL. Should the TTL definition also include a number of bits?
Original:
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live
Perhaps:
Label: Label value, 20 bits
TC: Traffic Class, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time To Live, 8 bits
-->
That’s fine.
Agree.
11) <!-- [rfced] Figure 4 does not have a title; all the other figures do. What
title should we add for Figure 4? Also, would it be helpful to revise the
title of Figure 3 to be more descriptive?
Current:
Figure 3: A Label Stack Entry
Figure 4
Perhaps:
Figure 3: A Label Stack Entry with TC and TTL Retained
Figure 4: A Label Stack Entry with TC and TTL Repurposed
-->
That’s fine.
Agree.
12) <!-- [rfced] Should "NAI" here be plural (i.e., "NAIs")?
Original:
A solution may carry some NAI and AD as PSD.
Perhaps (change to "NAIs"):
A solution may carry some NAIs and AD as PSD.
Or (remove "some"):
A solution may carry NAI and AD as PSD.
-->
Either is fine.
Prefer removing "some".
13) <!-- [rfced] "ECMP'ed" has not been used in published RFCs. Will readers
understand what this means? Perhaps rephrasing would be helpful.
Original:
For example, an
Ethernet Pseudowire without a control word might have "4" or "6" in
the first nibble and thus will be ECMP'ed.
-->
ECMP is on our well-known acronym’s list. If you object to the informality, I
would suggest:
For example, an
Ethernet Pseudowire without a control word might have "4" or "6" in
the first nibble and thus will be subject to ECMP forwarding.
hmmm, would prefer Tony's suggestion.
14) <!-- [rfced] We are having trouble understanding the text starting with "to
determine...". Please clarify.
Original:
However, the BIER approach meets
the design goal of [RFC8296] to determine that the payload is IPv4,
IPv6 or with the header of a pseudowire packet with a control word,
rather than being a payload belonging to a BIER or some other type of
packet.
-->
How about:
However, the BIER approach meets
the design goal of [RFC8296] to determine that the payload is IPv4,
IPv6, or the header of a pseudowire packet with a control word,
rather than being a payload belonging to a BIER or some other type of
packet.
I think this is a mine field, I hope Stewart or Matthew can help us.
15) <!-- [rfced] How may we update this sentence for clarity?
Original:
Network actions should be defined in a document that must contain:
Perhaps:
The definition of a network action in a document must contain the following:
Or:
Network actions should be defined in a document using the format below:
-->
Your first alternative would work.
Agree, but I would rather say
A document defining a network action must contain the following:
16) <!-- [rfced] The "Scope", "State", and "Required/Optional" items below
include
complete sentences starting with "The document should..."; the other
items in the list do not. How may we update these three items to create
parallel structure in this list?
Original:
* Name: The name of the network action.
* Network Action Indicator: The bit position or opcode that
indicates that the network action is active.
* Scope: The document should specify which nodes should perform the
network action as described in Section 2.1.
* State: The document should specify if the network action can
modify state in the network, and if so, the state that may be
modified and its side effects.
* Required/Optional: The document should specify whether a node is
required to perform the network action.
* In-Stack Data: The number of LSEs of in-stack data, if any, and
its encoding. If this is of a variable length, then the solution
must specify how an implementation can determine this length
without implementing the network action.
* Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
Perhaps:
Name: The name of the network action.
Network Action Indicator: The bit position or opcode that indicates
that the network action is active.
Scope: Description of which nodes should perform the
network action as described in Section 2.1.
State: Indication of whether the network action can modify
state in the network and, if so, the state that may be modified
and its side effects.
Required/Optional: Indication of whether a node is
required to perform the network action.
In-Stack Data: The number of LSEs of in-stack data, if any, and its
encoding. If this is of a variable length, then the solution must
specify how an implementation can determine this length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
-->
Fine.
Agree.
17) <!-- [rfced] May we update this text as follows to clarify "its" and "this"?
Original:
In-Stack Data: The number of LSEs of in-stack data, if any, and its
encoding. If this is of a variable length, then the solution must
specify how an implementation can determine this length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If this
is of a variable length, then the solution must specify how an
implementation can determine this length without implementing the
network action.
Perhaps:
In-Stack Data: The number of LSEs of in-stack data, if any, and the
encoding of the in-stack data. If the in-stack data is of a variable
length, then the solution must
specify how an implementation can determine the length without
implementing the network action.
Post-Stack Data: The encoding of post-stack data, if any. If the
post-stack data
is of a variable length, then the solution must specify how an
implementation can determine the length without implementing the
network action.
-->
Sure.
Agree
18) <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
Your choice. If we have a global preference, I’ve never heard of it.
Anything works. I have a slight preference for references to occur in
the same order in the dcoument as in the reference list.
19) <!-- [rfced] The following reference appears to point to IEEE Std 802.1AE
with
a date of August 2006. However, that version has been superseded by a new
version dated December 2018. See https://ieeexplore.ieee.org/document/8585421 <https://
ieeexplore.ieee.org/document/8585421>.
We have updated this reference entry to current version. Please let us know
if you have any objections.
Original:
[MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control
(MAC) Security", August 2006.
Updated:
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
December 2018,
<https://ieeexplore.ieee.org/document/8585421 <https://
ieeexplore.ieee.org/document/8585421>>.
-->
That’s fine, thank you.
Agree
20) <!-- [rfced] Terminology
a) If no objections, we will update instances of "sub-stack" (with hyphen) to
"substack" (no hyphen).
b) Please review use of "special label". Should instances of
"special label" be updated to "special-purpose label"?
-->
Both are fine.
I actually prefer sub-stack, it is easier to find when reading-
I should definitely be "special-purpose label".
21) <!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.
Operations, Administration, and Maintenance (OAM)
IP Fast Reroute (IPFRR)
Fast Reroute (FRR)
Label Switching Router (LSR)
Media Access Control Security (MACsec)
Ok.
OK fir the first three.
MACsec is a reference identifier, never used as an abbreviation in the
document. If you want to include I won't fight it, but it seems like a
bit outside what we uses abbreviations for.
b) Is the abbreviation NAS read as "nass" or as "en-ay-ess"? We ask in order to
choose the appropriate indefinite article for it to follow. Currently, both
"an NAS" and "a NAS" are used in the document.
I don’t think we have any consistency. I personally use “nass”. I was taught
that you always use ‘an’ with an abbreviation, but I’ve never liked that.
With my Swedish background I would do "a NAS", but as always I will
defer to people with English as their mother-tongue.
c) The following abbreviations appear in the text but do not appear in Table 1.
Would you like for them to be added to Table 1?
LSP
TC
TTL
Not necessary, IMHO, but not objectionable either. We’ve been using those
abbreviations for 25 years...
I'd say include them, as Tony said maybe not necessary, but for
completeness.
Label Switched Path LSP is not "well-known", there is more than one
expansion of the abbreviation.
Traffic Class (TC) also have several expansions, so include it.
TTL is wellknown, but I'd prefer to have it in the list.
d) Throughout the document, the expanded form of the following terms are often
used although the abbreviations are introduced in Section 1. Would you like to
use the abbreviations after the introduction in Section 1? Or do you prefer the
current?
network action sub-stack
post-stack data
ancillary data
Entropy Label
-->
Several WG members have requested that we decrease our use of acronyms.
True, but maybe we shold look at this case by case, i.e. I would not
support changing e.g. all "post-stack data" to PSD, but it might be
motivated in some cases.
22) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
—>
No changes.
If I try to do this I will just casue a mess :). No changes needed.
Thanks,
Tony
/Loa
--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
l...@pi.nu
loa.pi....@gmail.com
