The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] LDP Label WIthdraw doubt !!
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 Vijayanand C - CTD, Chennai. wrote: >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:gabhijit@ee.iitb.ac.in] >Sent: Friday, March 29, 2002 5:56 PM >To: Manoj Dutta >Cc: mpls@UU.NET >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 >> >
|
|