Subject: LDP protocol problem?

From: [email-masked]
Date: Thu, 17 Jan 2002 22:23:20 -0500 (EST)

I think I have found a serious protocol problem in LDP (RFC 3036).
The best way to describe it is to give an example...

Consider the following set of events, in chronological order
 (all messages refer to the same FEC/Label pairing; the session
 supports unsolicited label mappings; and Router B is using
 conservative label retention):

  Router A                          Router B
  --------                          --------

  Sends Label Mapping
                                    Receives Label Mapping
                                    Sends Label Release
                                     (because Router A is not the next hop)
  Sends Label Mapping
   (because the hop count changed)
                                    Router A becomes the next hop
  Receives Label Release
                                    Receives Label Mapping

The problem here is that the Label Mapping message which updates the
hop count and the Label Release message are sent more or less
simultaneously.

The result in the scenario above is that Router A thinks that there is no
valid Label Mapping advertised to Router B.  Router B thinks that it
has a valid Label Mapping.

At least three problems can come from this.  First, Router B can put traffic
onto a label which Router A has reused for another purpose.

Second, Router A may try to readvertise the FEC in the future.
Router B will not accept any such Label Mappings (LMp.10, Appendix A,
RFC 3036), unless Router A is fortunate enough to use the same
label which was originally used.

Third, if Router B tries to release the label, Router A may
report an error.

Is this analysis correct?  Is this a real problem with the protocol?
If so, is it already known?  How can this problem be solved?

    Jack Brennen

---

From: Abhijit Gadgil <[email-masked]>
Date: Fri, 18 Jan 2002 10:54:03 +0530 (IST)

>  Router A                          Router B

Actually, the problem _may_ not arise, because if you read the note 1. At
the end of process release message (LRl.), it takes care of the scenario
when LSR A is in DU mode and B releases the mapping sent by A. In that
case, A should not send a mapping to lsr B, unless B explicitely requests
it. (Which B would indeed do, unless it is request never.) Well at the
most one can say this is inefficient behavior and not incorrect behavior.
At most what can happen is for that FEC, an LSP can never be created.

However if PHP is used with unsolicited mapping, interesting scenarios can
occur. (This occured to me quite recently)

eg.

Consider

A -- B -- C

(A, B, C tail of some LSP) And when session becomes operational between
LSR A and LSR B, but there exists no session between B and C, B will send
Implicit Null label for some FECs, which it thinks it is egressing.
However, when a session is operational with LSR C, C will egress those
FECs and will send implicit Null labels, which would result in a lot of
withdraw-release and mapping messages between B and A. Also, B has to
install correct bindings in the LIB. Is it ingeneral a good/bad idea to
use PHP when sending DU labels?

Things will not be so bad in case of DoD, because B will send Implicit
Null labels for FECs requested by A only, which _could_ be substantially
less than the ones B sends unsolicitedly.

-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.