RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (1)

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1700
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Verifier Name: Adrian Farrel
Date Verified: 2010-01-04

Section 7, pg. 8 says:

   Some tunnels may not even require configuration, e.g., a Generic
   Routing Encapsulation (GRE) tunnel can be "created" just by
   encapsulating packets and transmitting them.  In such a case, the IP
   address of the root is considered to be the IP source address of the
|  encapsulated packets.
             ^^ 

It should say:

   Some tunnels may not even require configuration, e.g., a Generic
   Routing Encapsulation (GRE) tunnel can be "created" just by
   encapsulating packets and transmitting them.  In such a case, the IP
   address of the root is considered to be the IP source address of the
|  encapsulation headers.
             ^^^  

Notes:

Location is 4th paragraph on page 8.

Rationale:

The term "encapsulated packets" has been variously interpretted to mean
the "payload packets that" and the "whole packets including the
encapsulation headers."

To make this completely clear, the text should be read as in the correction.

Clarifying Reference:

Earlier in the same section, the 2nd paragraph on page 7 defines
the 'root' of a tunnel:

"The root is identified by the head-end IP address of the tunnel."

Consequentially, in the case of 'ad-hoc' GRE tunnels the IP address
of the 'root' obviously is the source address in the *outer* IP
header.

Status: Held for Document Update (5)

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 1698
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 4., 1st para says:

   [...]
   Then, with respect to this binding, Ru is the "upstream LSR", and Rd
|  is the "downstream LSR"."
                          ^^

It should say:

   Then, with respect to this binding, Ru is the "upstream LSR", and Rd
|  is the "downstream LSR".
                          ^

Notes:

Typo; keep for update!

Errata ID: 1699
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 7, pg.8 says:

   The precise set of procedures for identifying the IP address of the
|  root of the tunnel depend, of course, on the protocol used to set up
   the tunnel.  [...]
                           ^^

It should say:

   The precise set of procedures for identifying the IP address of the
|  root of the tunnel depends, of course, on the protocol used to set up
   the tunnel.  [...]
                           ^^^

Notes:

Location is the 2nd paragraph on page 8.

Rationale: singular/plural mismatch: "The ... set ... depend".
Keep for update!

Errata ID: 1701
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 8., 6th para says:

          [...].  Values of the host part of the IPv4 address greater
|  than 0xFFFEF are not allowed to be used as context labels.
                                           ^^

It should say:

          [...].  Values of the host part of the IPv4 address greater
|  than 0xFFFEF are not allowed to be used to generate context labels.
                                           ^^^^^^^^^^^

Notes:

Rationale: The 'host part' only becomes a part of the label
(The full, 32-bit label format is specified in RFC 3032 with
significant updates by RFC 5462, RFC 3270, and RFC 5129.)
Thus, the host part cannot be used "as" as label; the Corrected
Text suggests an appropriate wording.

Errata ID: 1702
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2009-03-02
Held for Document Update by: Adrian Farrel

Section 9 says:

   A typical use case of upstream-assigned labels is for MPLS multicast
   and is described here for illustration.  This use case arises when an
   upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
|  an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access
   media or tunnel, AND Ru wants to transmit a single copy of an MPLS
   packet on the LSP to <Rd1...Rdn>.  [...]

It should say:

   A typical use case of upstream-assigned labels is for MPLS multicast
   and is described here for illustration.  This use case arises when an
   upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in
|  an LSP, LSP1, AND Ru is connected to <Rd1...Rdn> via a multi-access
               ^
   media or tunnel, AND Ru wants to transmit a single copy of an MPLS
   packet on the LSP to <Rd1...Rdn>.  [...]

Notes:

Rationale:
The missing comma distorts the sense (giving the subject LSP a name,
"LSP1") and visually binds "LSP1" too much to the "AND".
Maybe it would have been preferable to also insert "say" for clarity:
"... and LSP, say LSP1, AND ..."

Errata ID: 3728
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Liu Lin
Date Reported: 2013-09-16
Held for Document Update by: Adrian Farrel
Date Held: 2013-09-17

Section 8 says:

If the IPv4 network mask is greater than 12 bits, 
it is possible to map the remaining 20 bits into 
a unique context label value.  

It should say:

If the IPv4 network mask is equal or greater than 12 bits, 
it is possible to map the remaining bits into 
a unique context label value.

Status: Rejected (1)

RFC 5331, "MPLS Upstream Label Assignment and Context-Specific Label Space", August 2008

Note: This RFC has been updated by RFC 7274

Source of RFC: mpls (rtg)

Errata ID: 3726
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Liu Lin
Date Reported: 2013-09-16
Rejected by: Adrian Farrel
Date Rejected: 2013-09-27

Section 6 says:

In the former case, an LSR distributes an upstream-assigned 
label binding for a FEC F if it is either (a) the ingress LSR 
for FEC F, or (b) if it has already received an upstream label 
binding for that FEC from its adjacent upstream LSR for FEC F, 
or (c) if it has received a request for a downstream label 
binding from its upstream adjacent LSR.

It should say:

In the former case, an LSR distributes an upstream-assigned 
label binding for a FEC F if it is either (a) the ingress LSR 
for FEC F, or (b) if it has already received an upstream label 
binding for that FEC from its adjacent upstream LSR for FEC F, 
or (c) if it has received a request for a upstream label 
binding from its downstream adjacent LSR.

Notes:

if a LSR has received a request for a downstream label binding from its upstream adjacent LSR, it will distributes a downstream-assigned label, not upstream-assigned-label. When a LSR has received a request for a upstream label binding from its downstream adjacent LSR, it may distributs a upstream-assigned label.
--VERIFIER NOTES--
The reporter has become confused between the different uses of "upstream" and "downstream" in the text.

The original text may have intended to imply that when an LSR receives a request for a downstream label from its upstream adjacent LSR then it
will use this as a trigger to send an upstream-assigned label to its
downstream adjacent LSR.

Thus the text is correct as it stands.

Report New Errata



Advanced Search