RFC Errata
Found 17 records.
Status: Verified (8)
RFC 3031, "Multiprotocol Label Switching Architecture", January 2001
Note: This RFC has been updated by RFC 6178, RFC 6790
Source of RFC: mpls (rtg)
Errata ID: 348
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2005-03-01
Section 2.3 says:
LDP Label Distribution Protocol L2 Layer 2 L3 Layer 3 LSP Label Switched Path
It should say:
LDP Label Distribution Protocol L2 Layer 2 L3 Layer 3 LSP Label Switched Path
Notes:
there is a missing CR/LF
Errata ID: 696
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2005-03-01
Section 3.20 says:
For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the the traffic to the egress node.
It should say:
For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the traffic to the egress node.
Notes:
Notice the double 'the'.
Errata ID: 1893
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dande Rajasekhar
Date Reported: 2009-09-24
Verifier Name: Ross Callon
Date Verified: 2009-09-29
Section 4.1.6 says:
It is important to note that if Ru and Rd are adjacent LSRs in an LSP for X1 and X2, forwarding will still be done correctly if Ru assigns distinct labels to X1 and X2 while Rd assigns just one label to the both of them. This just means that R1 will map different incoming labels to the same outgoing label, an ordinary occurrence.
It should say:
It is important to note that if Ru and Rd are adjacent LSRs in an LSP for X1 and X2, forwarding will still be done correctly if Ru assigns distinct labels to X1 and X2 while Rd assigns just one label to the both of them. This just means that Rd will map different incoming labels to the same outgoing label, an ordinary occurrence.
Notes:
R1 should be replaced by Rd since there is no reference for R1.
Errata ID: 2782
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Valeria Elisabetta Mattavelli
Date Reported: 2011-04-18
Verifier Name: Adrian Farrel
Date Verified: 2011-04-18
Section 2.2 says:
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
It should say:
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
Notes:
Wrong text indentation
Errata ID: 5002
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Gray
Date Reported: 2017-04-21
Verifier Name: RFC Editor
Date Verified: 2017-06-12
Section 3.8 says:
Liberal label retention mode allows for quicker adaptation to routing changes, but conservative label retention mode though requires an LSR to maintain many fewer labels.
It should say:
Liberal label retention mode allows for quicker adaptation to routing changes, while conservative label retention mode requires an LSR to maintain many fewer labels.
Notes:
Grammar error in original text, which may make it harder for some to read and understand.
Verifier Notes: (removed the spurious "though")
Errata ID: 7841
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08
Section 2.2 says:
label switched path The path through one or more LSRs at one
level of the hierarchy followed by a
packets in a particular FEC.
It should say:
label switched path The path through one or more LSRs at one
level of the hierarchy followed by packets
in a particular FEC.
Notes:
s/a packets/packets/
Errata ID: 7842
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08
Section 2.2 says:
MPLS edge node an MPLS node that connects an MPLS
domain with a node which is outside of
the domain, either because it does not
run MPLS, and/or because it is in a
different domain. Note that if an LSR
has a neighboring host which is not
running MPLS, that that LSR is an MPLS
edge node.
It should say:
MPLS edge node an MPLS node that connects an MPLS
domain with a node which is outside of
the domain, either because it does not
run MPLS, and/or because it is in a
different domain. Note that if an LSR
has a neighboring host which is not
running MPLS, then that LSR is an MPLS
edge node.
Notes:
s/that that/then that/
Errata ID: 7843
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christophe Deleuze
Date Reported: 2024-03-07
Verifier Name: RFC Editor
Date Verified: 2024-03-08
Section 2.2 says:
VP merge label merging where the MPLS label is
carried din the ATM VPI field, so as to
It should say:
VP merge label merging where the MPLS label is
carried in the ATM VPI field, so as to
Notes:
s/din/in/
Status: Held for Document Update (5)
RFC 3031, "Multiprotocol Label Switching Architecture", January 2001
Note: This RFC has been updated by RFC 6178, RFC 6790
Source of RFC: mpls (rtg)
Errata ID: 6240
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jitendra Kumar Sharma
Date Reported: 2020-07-27
Held for Document Update by: Deborah Brungard
Date Held: 2021-02-26
Section 3.10 says:
3.10. The Next Hop Label Forwarding Entry (NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
a labeled packet. It contains the following information:
1. the packet's next hop
2. the operation to perform on the packet's label stack; this is one
of the following operations:
a) replace the label at the top of the label stack with a
specified new label
b) pop the label stack
c) replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack.
It may also contain:
d) the data link encapsulation to use when transmitting the packet
e) the way to encode the label stack when transmitting the packet
f) any other information needed in order to properly dispose of
the packet.
Note that at a given LSR, the packet's "next hop" might be that LSR
itself. In this case, the LSR would need to pop the top level label,
and then "forward" the resulting packet to itself. It would then
make another forwarding decision, based on what remains after the
label stacked is popped. This may still be a labeled packet, or it
may be the native IP packet.
This implies that in some cases the LSR may need to operate on the IP
header in order to forward the packet.
If the packet's "next hop" is the current LSR, then the label stack
operation MUST be to "pop the stack".
It should say:
3.10. The Next Hop Label Forwarding Entry (NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
a labeled packet on an LSR or an unlabeled packet on an Ingress MPLS router. It
contains the following information:
1. the packet's next hop
2. the operation to perform on the packet's label stack; this is one
of the following operations:
a) replace the label at the top of the label stack with a
specified new label
b) pop the label stack
c) replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack.
d) push a new label on an unlabeled packet
It may also contain:
e) the data link encapsulation to use when transmitting the packet
f) the way to encode the label stack when transmitting the packet
g) any other information needed in order to properly dispose of
the packet.
Note that at a given LSR, the packet's "next hop" might be that LSR
itself. In this case, the LSR would need to pop the top level label,
and then "forward" the resulting packet to itself. It would then
make another forwarding decision, based on what remains after the
label stacked is popped. This may still be a labeled packet, or it
may be the native IP packet.
This implies that in some cases the LSR may need to operate on the IP
header in order to forward the packet.
If the packet's "next hop" is the current LSR, then the label stack
operation MUST be to "pop the stack".
Notes:
Section 3.10 defines NHLFE, and it sounds from the definition that this piece of information is used by an MPLS router only when packet is already labeled. Now, when section 3.12 (FTN) defines the relationship between FEC and NHLFE, the definition of NHLFE in section 3.10 does not align with FTN definition.
Errata ID: 6450
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Duane L. Anderson
Date Reported: 2021-03-00
Held for Document Update by: Andrew Alston
Date Held: 2022-05-26
Throughout the document, when it says:
2.2. Terminology defines the terms
Layer 2 layer 2 the protocol layer under layer 3
(which therefore offers the services used by layer 3)
Layer 3 the protocol layer at which IP and its associated
routing protocols operate
2.3. Acronyms and Abbreviations defines
L2 Layer 2
L3 Layer 3
However, in 3.14. Scope and Uniqueness of Labels, 4.3. Label Stacks and Implicit Peering, 4.5. LSP Trees as Multipoint-to-Point Entities, and 4.6. LSP Tunneling between BGP Border Routers, L1, L2 and L3 are used as differentiating names for certain labels attached to packets.
Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 frame header and to a layer 2 switch, which is correct.
However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is used to refer to the LIFO (stack) ordinal number of a label then named L1 and given a protocol layer 2 protocol of layer 2 (L2). Furthermore, labels named L2 and then L1 are pushed onto the stack of labels prefixed to the packet. To top it all off the packet's stack attribute as protocol level 2 (L2).
Of course, in 3.17. LSP Next Hop, 4.1.5. The Implicit NULL Label, 5.1.1.2. PushConditional, 5.1.1.4. PulledConditional, 5.1.2.2. RequestWhenNeeded, 5.1.3. Upstream LSR: NotAvailable Procedure, 5.1.4. Upstream LSR: Release Procedure, 5.1.4.2. NoReleaseOnChange, 5.1.5. Upstream LSR: labelUse Procedure, 5.2.2. Schemes for LSRs that do not Support Label Merging, refer to L3 meaning level 3, which is correct.
Furthermore, in 3.1. Labels, 3.2. Upstream and Downstream LSRs, 3.4. Label Assignment and Distribution, 3.5. Attributes of a Label Binding, 3.14. Scope and Uniqueness of Labels, 4.1.2.2. Distributing Labels, 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2. UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure
* L is used as a name for a certain label attached to packet, and
* L is used as a arbitrary value assigned to a label attached to a packet
It should say:
I have not provided any corrected text as I've literally "highlighted" 44 places in a pdf format file of RFC 3031 that are ambiguous. As there is no facility to attach a file to this Report Errata for RFC3031 form, i will send the file commented pdf file upon request.
Notes:
My rational for highlighting (no pun intended) these problems is that the overloading of the L2, L3 abbreviations layer 2 and layer 3, with the names L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names for the ordinal position of a label prefixed to a payload, then to use L2 and L3 as to actually mean layer 2 and layer is uh ... sloppy.
Honestly, I can't understand how RFC 3031 has been posted for twenty years and that it is on the Standards Track and no one has found these problems.
Its similar to when someone publishes a mathematical treatise and use the same set of variable names {x, y, z, t} over and over again in different contexts spread throughout the paper. Its intractable and practically gibberish.
I apologize if my criticism is harsh regarding this problem but I spent a considerable amount of my time reading this document trying to make sense of it before I realized that the fault is not mine but it is of the document.
[Andrew] This seems to wide and generalized to be a simple errata, as such I am marking this as held for document update.
Errata ID: 2803
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: maligree
Date Reported: 2011-05-08
Held for Document Update by: Adrian Farrel
Section 3.1 says:
Ru will label with packet with label value L
It should say:
Ru will label the packet with label value L
Errata ID: 2967
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: fl
Date Reported: 2011-09-11
Held for Document Update by: Adrian Farrel
Section 3.20 says:
When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
It should say:
When ordered control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
Errata ID: 2992
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bala Venkata
Date Reported: 2011-10-12
Held for Document Update by: Adrian Farrel
Section 3.12 says:
If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
It should say:
If the FTN maps a particular FEC to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a FEC to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
Notes:
Since FTN is used for packets that arrive unlabeled (as ILM is used for label-NHLFEs), this section should be corrected. It says that "FTN maps a particular label to a set of NHLFEs"
Status: Rejected (4)
RFC 3031, "Multiprotocol Label Switching Architecture", January 2001
Note: This RFC has been updated by RFC 6178, RFC 6790
Source of RFC: mpls (rtg)
Errata ID: 3689
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Renato Westphal
Date Reported: 2013-07-28
Rejected by: Adrian Farrel
Date Rejected: 2013-09-27
Section 5.2.1 says:
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
UseImmediate>
This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop detection.
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
UseIfLoopNotDetected>
It should say:
6. <PulledUnconditional, RequestWhenNeeded, RequestRetry,
ReleaseOnChange, UseImmediate>
This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop detection.
7. <PulledUnconditional, RequestWhenNeeded, RequestRetry,
ReleaseOnChange, UseIfLoopNotDetected>
Notes:
If the "Request Procedure" is different than "Request Never", then a "NotAvailable Procedure" should be specified. In this case, the "Request Retry" procedure is the right option for Downstream on Demand.
[Note that the reported original text has been updated to reflect the actual text in the RFC]
--VERIFIER NOTES--
This report is rejected for a number of reasons.
The first point to note is that the text in section 5.2 is intended to show how the different label distribution schemes will interoperate. It is not intended to cover every wrinkle or be a normative. In that light, the downstream-on-demand operations can be considered to be consistent with a converged IGP in which case the failure to return a LabelMapping would simply not arise or would represent a marginal error that should not be blindly retried.
Consider for example that the routing tables on the two routers are not in agreement. Can the upstream router know which one is out of synch?
Consider that the downstream router has run out of labels (maybe not realistic these days, but it was a concern once upon a time). Would retrying the request help?
The second point to note is that if this text *is* considered to be normative (i.e., an absolute definition of how downstream-on-demand operates) then any change is also normative. Since the current text is what the authors and WG intended to write, a change to this text would be a change of substance and needs more than just an errata report (for example, an Internet-Draft).
Errata ID: 4331
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Shearman
Date Reported: 2015-04-09
Rejected by: Alia Atlas
Date Rejected: 2015-04-09
Section 3.22 says:
When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop.
It should say:
When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid and it has a usable L3 next hop. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop.
Notes:
Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition.
The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop.
This proposed errata would thus add incorrect ambiguity for no purpose.
================================================
There is ambiguity as to the cause of the "ILM [not mapping] the packet's incoming label into an NHLFE". It could be read in a number of ways, of which only one can be correct:
1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has been installed because the label hasn't been advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label" so this interpretation is unlikely to have been intended.
2. The label is valid and is expected to be used for forwarding, but an NHLFE entry is missing or not usable because the interface the next hop is reachable over has gone down, or for some other reason isn't usable. This interpretation is ruled out by the statement that "it is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down.
3. A resource allocation error occurred meaning that the ILM binding was allocated, but the NHLFE entry couldn't be allocated. There is no mention of resource issues in this or related sections so again this interpretation seems unlikely.
4. The label is valid and is expected to be used for forwarding, but the LSR has received no label binding from the LSP's next hop even though it has a usable L3 next hop (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry because the actions in section 3.10 don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits.
To clarify that interpretation 4 is the one intended, the phrase "and it has a usable L3 next hop" is inserted into the text, using the definition of L3 next hop from section 3.17.
--VERIFIER NOTES--
Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition.
The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop.
This proposed errata would thus add incorrect ambiguity for no purpose.
Errata ID: 5643
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Smith
Date Reported: 2019-02-25
Rejected by: Deborah Brungard
Date Rejected: 2019-05-30
Section Terminology says:
<missing>
It should say:
label edge router - a router capable of accepting an unlabelled packet, and through MPLS processing, may MPLS encapsulate the packet by adding a label stack.
Notes:
I am doing some MPLS review.
The book I'm using said an LER was an (RFC3031) MPLS edge node. I believed it was any router that could take unlabelled packets and label them, regardless of where the router was within the MPLS domain. (In other words, an MPLS router was not an LER if it would not MPLS label unlabelled packets and forward them.)
I decided to check RFC3031 for a definition, and discovered there isn't a definition at all for "label edge router", or a match on any text that matches "label edge" or "LER".
RFC6178 clarifies LER processing of IPv4 packets, and the general description of processing matches my understanding of what an LER is.
However, it doesn't formally define an "label edge router" either, and I think an update to RFC3031 should be where "label edge router" is formally defined.
--VERIFIER NOTES--
This is not an error with RFC3031. It is inappropriate to use an Errata Report to add a new term to an RFC.
Errata ID: 3171
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2012-04-01
Rejected by: Adrian Farrel
Date Rejected: 2012-04-03
Section 3.20 says:
Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity".
It should say:
Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (b) being the "finest granularity".
Notes:
In the case of (c) the aggregation is not used, so there is no granularity.
--VERIFIER NOTES--
Not aggregating is a degenerate case of aggregation where a one-to-one aggregation mapping is used. Thus, the result is the "finest granularity".