The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] LDP Label WIthdraw doubt !!
Eric Gray wrote: > 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 This was supposed to say "(ordered or independent)". Oops... > > 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 >>> >> > > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray
|
|