The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

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

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