errata logo graphic

Found 9 records.

Status: Verified (4)

RFC3031, "Multiprotocol Label Switching Architecture", January 2001

Source of RFC: mpls (rtg)

Errata ID: 348

Status: Verified
Type: Editorial

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

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

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

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


Status: Held for Document Update (3)

RFC3031, "Multiprotocol Label Switching Architecture", January 2001

Source of RFC: mpls (rtg)

Errata ID: 2803

Status: Held for Document Update
Type: Editorial

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

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

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 (2)

RFC3031, "Multiprotocol Label Switching Architecture", January 2001

Source of RFC: mpls (rtg)

Errata ID: 3689

Status: Rejected
Type: Technical

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: 3171

Status: Rejected
Type: Editorial

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".


Report New Errata