Subject: Label Mapping !!

From: Manoj Dutta <[email-masked]>
Date: Wed, 30 May 2001 20:46:26 -0700

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.
Let me know if there is some inconsistency in the above mentioned line
of reasoning.

Thanks in advance
manoj

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Thu, 31 May 2001 10:28:36 +0530 (IST)

Hi Manoj!
	Read my comments between the lines 

> than one LSR (in this case B & C) for which A has previously sent a

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

Hope it clarifies !

--tomar

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Thu, 31 May 2001 12:07:08 +0400 (RET)

Hello Manoj,
	Please also note that it is made mandatory in the rfc that if a
mapping message is a response to a request message then the sender should
include the Label Request id TLV in the mapping message. By this request
id you will be able to map the mapping to a unique request message.

regards
Bhushana

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 May 2001 13:34:10 -0400

Manoj,

    First, I would have to say that this is a bit of a contrived
scenario.  In order to be non-merge capable, the LSR would
have to have an ATM interface at least with respect to the
downstream LSR from which it is expecting a label mapping.
But, for it to issue labels to upstream LSRs in this case, it
should be able to forward packets it receives bearing those
labels (otherwise it indulges in a bit of false advertisement).
Not having 'labels' downstream means it should forward
these packets using an established VC to the next dowstream
ATM LSR (since the interface is an ATM interface).  In order
to do this, however, it should also be able to avoid interleaving
cells from multiple sources onto the same VC.  In short, if it is
giving out labels in indepedent mode, it should be merge capable.

    However, assuming someone actually implemented this the
way you suggest, you have to remember that - from a strictly
local perspective - a label is an LSP when it is received from
a downstream peer, bound to an upstream label and the upstream
label is distributed to an upstream peer.  Once a label mapping is
received from a downstream peer, the local LSR which has
distributed multiple labels to upstream LSRs must pick one of
them to bind with the label in the mapping it has just received -
before there is an 'LSP in question'.  If the local LSR is not merge
capable, then it will - by definition - only bind a label mapping to
a single upstream label.

--
Eric Gray