RFC Errata
Found 6 records.
Status: Verified (5)
RFC 3031, "Multiprotocol Label Switching Architecture", January 2001
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")
Status: Reported (1)
RFC 3031, "Multiprotocol Label Switching Architecture", January 2001
Source of RFC: mpls (rtg)
Errata ID: 6450
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Duane L. Anderson
Date Reported: 2021-03-03
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.