Subject: RE: change in next hop !!

From: Mohit Misra <[email-masked]>
Date: Fri, 18 May 2001 13:36:49 +0530

Hi,
I think you need to execute this procedure for each FEC for which the next
hop has changed.
NH1.-NH5 takes care about the case for each FEC and  label(s)  being used
for it.

> Hi,
> 
> I have a few questions based on section A.1.7 RFC 3036.
> 
> 1) Is is correct to assume that NH.1 - NH.5 also consider the case where
> LSR has received and retained multiple label mappings from old next hop
> ??
>>>> I could not understand multiple label mappings. This procedure is being
executed for a single FEC so you would
         have a single label corresponding to it. If you have other labels
for other FECs from the same next hop then you should
         execute this procedure those many times.

> 3) Also NH.6 to NH.8 take into account the scenario where multiple
> requests are pending.
      Same as above. You need to take care about the label request for the
particular FEC in question within this procedure.

> Consider the following scenario :
> 
> LSR U1 and LSR U2 are upatream wrt LSR A and LSR D1 and LSR D2 are
> downstream of LSR A.
> 
> 
> 
>                             LSR U1            LSRU2
>                                 |                       |
>                                   \                   /
>                                      \              /
>                                        LSR A
>                                      /            \
>                               LSR  D1    LSR D2
> 
> Suppose LSR A is non merge capable and for a given FEC F,  LSR D1 is its
> next hop.  D1 has distributed
> labels L1 and L2 for FEC F which LSR A maps to lable L3 and L4 given to
> LSR U1 and LSR U2 respectively.
> Now, LSR D2 becomes the new next hop for LSR A (FEC F).
> Cosider statement NH.11 :
> 
> a) Suppose, LSR A already has a label mapping  ,say L5, from LSR D2 for
> FEC F. A recv mapping event will be generated. Now if LMp.18 of section
> A.1.2  is executed, it contradicts Note 8 as we have sent labels, L3 and
> L4, to more  than one peer (LU1 and LU2, in this case.) despite being a
> non merge LSR. Even if we ignore this,  which of the upstream labels (L3
> and L4) should we map to L5 .
> Let say that we map L5 to L3 (LSR U1).  There is no way to let LSR U2
> know that lable L4 is not mapped
> to any downstream label now and if LSR A is using ordered control then
> we have an exception here.
> 
> b) Now, lets take the case where LSR A does not have any mapping from
> new hop LSR D2. Now, it might
> send a single label request which again cannot be mapped to the two
> upstream labels L3 and L4.
> 
> I would really appreciate any help in understanding this scenario.
> 
> Thanks in advance,
> manoj
> 
	I little bit of confision here. NH.11 talks about if the node is
operating in liberal label retention mode. In the case described
	above D2 would have supplied two labels in the past because LSR A is
non -merge capable. So if it becomes the new next
	hop you will have two labels to map to L3 & L4. LSR A can't have two
modes of operation with to LDP peers (D1 & D2)
	ie. Merge and non-merge. I hope this helps

	Mohit Misra
	Netbrahma Technologies
	www.netbrahma.com