RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 3031, "Multiprotocol Label Switching Architecture", January 2001

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

Report New Errata