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.

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"

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

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.

It should say:

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.

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