Subject: RE: LDP protocol problem?

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 18 Jan 2002 10:22:53 +0530

I faced a similar problem some time back

I think the problem comes because of the configuration of the LDP label
distribution mode, control mode and Request mode.

Particularly here the request node is REQUEST_NEVER though the distribution
mode is DuS. If router B were 'Request When Needed' then it would have
requested A for a label when A becomes its next Hop then the problem would
have been overcome by A sending the mapping again after receiving the
request. I wonder if DuS Ind control with 'Request Never' is not a good
configuration choice

Please correct me if I am wrong.

Regards,
Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 18, 2002 8:53 AM
To: [email-masked]
Subject: LDP protocol problem?

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: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 18 Jan 2002 11:16:50 +0530

One more point I can think of is - the retention mode . Is it OK to have
Conservative retention mode when operating in DuS Ind Req Never
configuration. Should'nt the rethention and request modes be complementary
so that this kind of situations can be avoided.

Regards,
Vijay

-----Original Message-----
From: Abhijit Gadgil [mailto:[email-masked]]
Sent: Friday, January 18, 2002 10:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: LDP protocol problem?

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

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Mon, 21 Jan 2002 11:55:47 +0530

Abhijit,
ACKing is not merely for ensuring the reliability of PDUs but for triggering
subsequent events in the state machine.

When release is initiated by LDP due to FEC going down or local repair etc.
it does'nt have an ACK and this causes some confusion as in the present case
and in CR LDP local repair (ref
:http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html).
When an  ABORT_REQUEST message in LDP is ACKed by a notification why not a
release which is even more critical because it involves releasing an already
held label. 

Regards,
Vijay

-----Original Message-----
From: Abhijit Gadgil [mailto:[email-masked]]
Sent: Monday, January 21, 2002 11:23 AM
To: Vijayanand C - CTD, Chennai.
Cc: Eric Gray; [email-masked]
Subject: RE: LDP protocol problem?

Vijay,

Please refer to a message posted about release message. I agree with Eric
that ACKing release is not a very good idea. But neverthless a release
message can itself indicate what it exactly is Acking(withdraw) or
Nacking(Mapping) with the mesg-id. So now the ball is in the court of
downstream LSR, to act upon this. It will do so if it finds it necessary.
Otherwise the upstream LSR cannot really help. It solves the problem
indicated by Jack as well. I havent really checked how it will work with
CR-LDP.

Since LDP is anyways using TCP, asking for ack for every message sent is
somewhat unreasonable.

Any thoughts?

-abhijit

Vijayanand C - CTD, Chennai. wrote :

>It is common for set up and release to be a 3 way handshake in many
>signalling protocols. If Rel is always triggered by a withdraw then its not
>a problem but in situations were it is not don't u think the release needs
>to be ACKed.All u need is a Rel ACK status in the notification messages.
>This could clear up this and a similar problem in CR LDP. It would also
>offer a lot of flexibilty in the Label distribution, control and retention
>modes.
>
>Please consider this  and correct me if I am wrong
>
>Regards,
>Vijay
>
>From: Eric Gray [mailto:[email-masked]]
>Sent: Saturday, January 19, 2002 12:26 AM
>To: Vijayanand C - CTD, Chennai.
>Cc: MPLS Mailing List
>Vijay,
>    I can't support the notion that the Release message needs an ACK.
>Recall
>that the Release message is itself an ACK to the Withdraw message.  We
don't
>want to get in the middle of an ACK war...
>
>
>You wrote:
>
>> I think the problem is - the release message has no ACK. If the Upstream
>> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
>> request for the same FEC to the same downstream and the Upstream when
>> receiving the mapping 'update' drops it if it were waiting for the
Rel-ACK
>> then the problem would have been avoided.
>>
>> A related  problem occurs in CR LDP local repair(ref
>> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
>> request arrives earlier than the release.
>>
>> Please correct me if I am wrong
>>
>> Regards,
>> Vijay
>>
>> Sent: Friday, January 18, 2002 12:47 PM
>> To: [email-masked]
>> Vijay wrote:
>> The problem also manifests itself if the session is
>> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>>
>>   Router A                          Router B
>>   --------                          --------
>>
>>                                     Sends Label Request
>>   Receives Label Request
>>   Sends Label Mapping (Label 1)
>>                                     Router A becomes NOT the next hop
>>                                     Sends Label Abort Request
>>   Receives Label Abort Request
>>    (which is ignored)
>>                                     Receives Label Mapping (Label 1)
>>                                     Sends Label Release (Label 1)
>>   Sends Label Mapping (Label 1)
>>                                     Sends Label Request
>>   Receives Label Release (Label 1)
>>                                     Receives Label Mapping (Label 1)
>>   Receives Label Request
>>   Sends Label Mapping (Label 2)
>>                                     Receives Label Mapping (Label 2)
>>                                     Sends Label Release (Label 2)
>>   Receives Label Release (Label 2)
>>
>> The final outcome is the same.  Router B believes that a
>> Label Mapping exists; Router A believes that no Label Mapping exists.
>>
>> The problem seems independent of distribution, control, or retention
>> modes.  The crux of the problem is that when Router A sends a
>> Label Mapping message which is an "update" message (the same FEC
>> and Label as a previous message, usually sent to change the
>> hop count and/or path vector) and then subsequently receives a
>> Label Release message for that FEC and Label, one of two
>> situations can exist:
>>
>>   * If Router B sent the Label Release after receiving the
>>     "update" message, then Router B is not keeping the label
>>
>>   * If Router B sent the Label Release before receiving the
>>     "update" message, then Router B may in fact keep the
>>     label if his situation changed between sending the
>>     Label Release and receiving the "update" message.
>>     (The most likely reason for the situation to change
>>     would be Router A becoming the next hop for the FEC.)
>>
>> Router A simply cannot reliably determine which of these
>> two situations exists on Router B.