Subject: Label Mapping mesage !!

From: Manoj Dutta <[email-masked]>
Date: Mon, 14 May 2001 00:49:55 -0700

hi,

Is is possible for a given LSR Rd to distribute the same label mapping
for more than one fec elements to another LSR Ru while using platform
wide label space only. If so, then what are the possible scenarios.

thanks
manoj

---

From: "Akshat Kapoor" <[email-masked]>
Date: Mon, 14 May 2001 15:21:20 +0530

Hi Manoj,
    Refer to section 3.14 of rfc 3031

"If a particular LSR Rd is attached to a particular LSR Ru over two
   point-to-point interfaces, then Rd may distribute to Ru a binding of
   label L to FEC F1, as well as a binding of label L to FEC F2, F1 !=
   F2, if and only if each binding is valid only for packets which Ru
   sends to Rd over a particular one of the interfaces.  In all other
   cases, Rd MUST NOT distribute to Ru bindings of the same label value
   to two different FECs."

Akshat

---

From: Eric Gray <[email-masked]>
Date: Mon, 14 May 2001 11:35:56 -0400

Manoj,

    There are some holes in any literal interpretation of the platform
wide label space concept.  You may be looking at one of them, if I
understand your question correctly.  Typically, if any LSR were to
distribute a single label for multiple FECs, the one thing that all of
these FECs must have in common is identical next hop information
(this might happen, for example, if FECs from Ru's perspective are
aggregated by Rd into a single FEC going downstream).  In this case,
the restriction that a per platform label must not be 'honored' if it is
received by the interface which would be used to forward the packet
(IOW, the packet is received from the next hop for the label) is even
more important.

    Note that the fact that the specifications were meant to support
distributing a single label for multiple FECs, does not mean that any
one was absolutely convinced that this was necessarily a good idea.
Scenarios is which this will both work and result in optimal behavior
are somewhat restricted.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Mon, 14 May 2001 15:26:05 -0400

Akshat,

    The meaning of 'over a particular one of the interfaces' is not
(and never has been) absolutely crystal clear to me.  At issue, is
whether or not there is a viable implementation which adopts some
perspective on the use of such a label that is sufficiently at odds
with a perspective adopted by another workable implementation, that
the result would be to incorrectly forward packets bearing this label.

    I believe it is fair to say that - with downstream allocation of
labels - assuring correctness of forwarding is the burden of the
downstream LSR that issues the labels.  Therefore, if a label is
distributed by a downstream LSR 'Rd' to an upstream LSR 'Ru' in
association with a particular interface and FEC, it is up to Rd to
ensure that packets received on that interface - bearing this label
(and received from Rd) - are correctly forwarded based on the FEC to
which this label is bound.  If this same label is also distributed
for this same FEC in association with a different particular interface
- either explicitly, or by implication (based on a common label 'space',
for instance) - then, once again, it is Rd's responsibility to ensure
correct forwarding.

    If it is possible to associate more than one FEC with a label,
and this association (or binding) is advertised for more than one
interface, then again Rd is responsible for ensuring that packets
received with this label are correctly forwarded - based on any
of the possible FECs associated with this label. Rd may distribute
any labels which it will be able to use in correctly forwarding a
labeled packet - provided that this does not impose an unreasonable
burden on Ru.  In some cases, issuing the same label for multiple
FECs could be seen to reduce label consumption at all upstream LSRs
which MAY be beneficial throughout an MPLS domain.

    So, it seems to me, as long as it is possible to associate more
than one FEC with the same label issued by Rd, Ru should be able to
forward packets for any FEC associated with that label to Rd and
rely on those packets being correctly forwarded.  As far as I can
tell, it only necessary for an LSR to comply with the letter of the
appropriate signaling and encapsulation specifications and the spirit
of the architecture specification.

    It may not be possible to associate more than one FEC with a
single label, however, because issuing the same label for multiple
FECs implies that multiple labels were requested (one for each FEC
from Ru's perspective) and only one is given.  Ru may not be able
(or may not be optimized) to use a single label in this case; for
example, Ru may not be able to perform a merging operation implied
by the common label issued by Rd.  If this is the case, however, Ru
may (as in the general non-merging case) simply request more labels
for each FEC and release the common label (or at least all but one
FEC in association with the common label.  Since it is possible
that Rd may be learning impaired, there is the real possibility that
this process could become quite tiresome - so there should some way
to configure a peer relationship for the general non-merging case.
Note that the non-merging case applies only to ATM LSRs.  Also, it
is a general need (supported in the appendix of the LDP specification,
at least) for Rd to issue a different label if an additional label is
requested for any FEC that Rd has issued a label binding, that has
not been released by Ru.  Likewise, Ru should not release a label
it has received from Rd if it is trying to get a different label.  In
other words, if Rd gives a label to Ru for a FEC (or multiple FECs)
and Ru requests another label, Rd must give Ru another label (not the
same one) - but, in order to ensure that this happens, Ru must not
release the label it does not want until it has received another one.

    Also, combining FECs using a single label can result in excessive
label churning if there are frequent route changes in an MPLS domain.

    Since there are ways to work around LSRs that disagree on the
usefulness of combining FECs using a single label - however clunky
- and these are already required by the need to deal with merging
and non-merging LSPs, then I believe that the current specifications
already say enough on the subject.

--
Eric Gray