Subject: RE: LDP Label WIthdraw doubt !!

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Fri, 29 Mar 2002 18:36:29 +0530

I also agree with abhijit that the problem can be addressed at the routing
protocol level. If a link goes down the routing protocol would generally
give a next hop change to the LDP module to trigger a request along the new
path. In other words, by the time LDP detects it routing protocol would have
sensed it and found and alternate path.If that were not the case, ie, if
alternate next hop is not immediatly available, the routing entity in
upstream(A in this case) would also be aware of that the dest is unreachable
and would have  informed the LDP entity about it. Subsequently when next hop
becomes available at B, routing protocol at A would intimate LDP at A. The
case described where the ingress has to re-request would seldom arise with a
good routing protocol implementation.

Please correct me if I am wrong

Regards,
Vijay

-----Original Message-----
From: Abhijit Gadgil [mailto:[email-masked]]
Sent: Friday, March 29, 2002 5:56 PM
To: Manoj Dutta
Cc: [email-masked]
Subject: Re: LDP Label WIthdraw doubt !!

Manoj,

Consider here the events that would lead to such a behavior. One cannot
neglect the role played by routing protocol here. The first event would
cause B to withdraw and A to release label(s). However the next event when
B sees D as next hop for some fec F, would in turn cause the routing
protocol to indicate the reachability for fec F through D. This event
would generate an internal trigger at LSR A for LDP to issue request
(implementation dependent). I dont think it is required for A to do
something different becuase it is ingress LSR.

LDP working alone without any routing protocol cannot obviously catch the
dynamic effects.

-abhijit.

Manoj Dutta wrote :

>Hi,
>
>I have a doubt regarding label wihdraw procedures described in RFC 3036
>section A.1.5.
>Consider the following topology :-
>
>
>    A-------B---------C--------D
>            |                  |
>             -----D------------
>
>
> Now, lets suppose that for a given FEC F,
>
>a) C is B's nexthop for FEC F
>b) B is A's nexthop for FEC F
>
>All the routers are using Downstream on demand with ordered control. So,
>A send request to B (for FEC F) and gets a label
>L (assuming B has a label from C and so on..). Now, for some reason the
>link between B and C goes down and consequently
>B withdraws label L from A. So, now A has no label for FEC F. After some
>time, B chooses D as the nexthop for FEC F and
>gets a label from D subsequently. But, A's nexthop still points to B for
>FEC F and so A never sends a request to B to get a label
>for FEC F. This behaviour is due to LWd.5 in section A.1.5 in the RFC.
>Is there a reason for this check. So, basically A would send
>a request to B if it were in DOD Independent control. According to me,
>if two LDP peers are using DOD then, in case of a label withdrawal the
>upstream should always send a request to nexthop for theFEC in question.
>
>Does it make sense ??
>
>
>Thanks in advance
>Manoj

---

From: Eric Gray <[email-masked]>
Date: Fri, 29 Mar 2002 10:26:00 -0500

You're _all_ right, starting with Shahram.

The intention of step LWd.5 is to say that you don't ask for
a new label just because the current one has been withdrawn
if you're using ordered control _and_ you're supposed to be
waiting for a request from an upstream peer to drive your
downstream request.

It might be possible to add a note to clarify this, but it's not
clear what the note should say.  It is very implementation
specific - i.e. - one implementation might simply immediately
request a new label if it is the ingress (simply because it needs
one in order to _be_ an ingress :-)) while another may wait (as
Abhijit and Vijay suggested) until it has an indication that its
peer is likely to have a new label to give.

Remembering that - in basic LDP - there is no hard requirement
that an entire network must conform to either a specific label
advertisement mode (DoD or DU) or control mode (ordered or
downstream on demand), it is probably slightly more correct for
the ingress implementation (A in the example) to immediately
request a new Label from its downstream peer relative to the
given FEC (B in the example).  Otherwise, A makes assumptions
about B's behavior that may not be correct.  

If A requests a label from B and B is not yet prepared to give it
one, it could propagate the request (ordered control) or it could
return a Notification message with no route.  If it does the latter,
however, there will be a synchronization problem if has not also
removed or withdrawn its route advertisement for the FEC.  If
it has removed its route advertisement, then there will be a new
FEC recognition event at some point in the future.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Fri, 29 Mar 2002 11:47:08 -0500

> downstream on demand), it is probably slightly more correct for 

This was supposed to say "(ordered or independent)".  Oops...

-- 
--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray