[mpls] [Errata Rejected] RFC3031 (4331)

[RFC Errata System <[e-mail]>]

The following errata report has been rejected for RFC3031,
"Multiprotocol Label Switching Architecture".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=4331

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Robert Shearman <[e-mail]>
Date Reported: 2015-04-09
Rejected by: Alia Atlas (IESG)

Section: 3.22

Original Text
-------------
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.

Corrected Text
--------------
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.

--------------------------------------
RFC3031 (draft-ietf-mpls-arch-06)
--------------------------------------
Title               : Multiprotocol Label Switching Architecture
Publication Date    : January 2001
Author(s)           : E. Rosen, A. Viswanathan, R. Callon
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG