RFC 5036, "LDP Specification", October 2007

Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552

Errata ID: 4465
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Guijuan Wang
Date Reported: 2015-09-05
Rejected by: Deborah Brungard
Date Rejected: 2015-11-18

Section 3.5.3 says:

The first rule: 
In section 3.5.3 
   A, Label Advertisement Discipline
         [omitting the first paragraph]

         If one LSR proposes Downstream Unsolicited and the other
         proposes Downstream on Demand, the rules for resolving this
         difference is:

         -  If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            MUST be used.

         -  Otherwise, Downstream Unsolicited MUST be used.


The second rule: 
In section 3.5.7.1.3.

   In general, the upstream LSR is responsible for requesting label
   mappings when operating in Downstream on Demand mode.  However,
   unless some rules are followed, it is possible for neighboring LSRs
   with different advertisement modes to get into a livelock situation
   where everything is functioning properly, but no labels are 
   distributed.  For example, consider two LSRs Ru and Rd where Ru is
   the upstream LSR and Rd is the downstream LSR for a particular FEC.
   In this example, Ru is using Downstream Unsolicited advertisement
   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
   assume that Ru will request a label mapping when it wants one and Ru
   may assume that Rd will advertise a label if it wants Ru to use one.
   If Rd and Ru operate as suggested, no labels will be distributed from
   Rd to Ru.

   This livelock situation can be avoided if the following rule is
   observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
   expected to send unsolicited mapping advertisements.  Therefore, if
   the downstream LSR is operating in Downstream on Demand mode, the
   upstream LSR is responsible for requesting label mappings as needed.

It should say:

[not provided]

Notes:

Label advertisement mode negotiation rule is different in two sections.

when the label advertisement mode is different between LSR peers,
the resolving rule is defined twice in two chapters,
both use "must" or "SHOULD NOT", but they are completely different.

It's better to settle down which rule to use for this case.
Seems the first one is simpler for implementation.

Or if you want to keep both rules,
better to enumerate both of those two rules in each section,
and say the implementer can choose any of them.

--VERIFIER NOTES--
This suggested errata requires an update to the RFC, which requires consensus.

Report New Errata