The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-May> msg00598



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Label Mapping !!

  • From: Nagendra Singh Tomar <nagendras@netbrahma.com>
  • Date: Thu, 31 May 2001 10:28:36 +0530 (IST)
  • cc: mpls@UU.NET
  • Organization: NetBrahma Technologies

Hi Manoj!
	Read my comments between the lines 


On Wed, 30 May 2001, Manoj Dutta wrote:

> Hi,
> 
> In RFC 3036 section A.1.2 ,LMp.18, Note 8, it is mentioned that if
> LSR is not merging, then it may have sent label mapping for LSP in
> question to at most one LSR.  Lets take the following scenario :
> 
> LSR A is non merge capable and operating in DoD advertisement mode with
> independent control. Now, it may receive requests from multiple LSRs say
> LSR B, LSR C etc. Since, it is using independent control, it may send
> mapping (different labels) to LSRs B & C immediately without waiting for
> a mapping from its next hop (offcourse it will send requests to next hop
> for each such mapping). Also, it may so happen that LSR B is also non
> merge capable and it may send multiple requests to A (one for each of
> B's upstream peers). In this case, we might end up in a situation where
> A has send multiple uniquely distinct mappings to B and one (or
> more) uniquely distinct  mappings to C for the same FEC. Now, when
> A receives a mapping from its next hop for the FEC in question, we see
> that Note 8 as enumerated above is clearly violated as there is more
> than one LSR (in this case B & C) for which A has previously sent a
> mapping.

The problem is in the above statement. As u have rightly said that since A
is a non-merging LSR, it will send a label request downstream for each
label request it receives from its upstream peers (B and C here). Now when
A receives a label mapping from its nexthop (in response to one of its
request. Note that, it will get more such label mappings for its remaining
pending requests) this label mapping it got will be either for the request
it made to its downstream peer,
in response to B's request or C's request (note both will result in
different LSPs for the same FEC), so the statement given in the RFC is
perfectly true. The key is the statement "for the LSP in question", don't
confuse it with "for the FEC in question". 




> Let me know if there is some inconsistency in the above mentioned line
> of reasoning.
> 
> Thanks in advance
> manoj
> 


Hope it clarifies !

--tomar