Subject: RE: Questions about merge-capability in LDP

From: "Ju, Yu" <[email-masked]>
Date: Thu, 19 Apr 2001 10:09:42 -0400

Eric,

A label mapping message can have a FEC with more than one FEC elements.
However, a label request message can have only one FEC element. How should a
non-merge capable or merge-averse LSR handle this case?

Thanks,

Yu

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 4:56 PM
To: David Charlap
Cc: [email-masked]
Subject: Re: Questions about merge-capability in LDP

David,

    That's because - when the issue with handling merge capable
and non-merge capable label distributions came up during the last
call, the authors decided that the functionality required to handle
this was not specific to non-merging LSRs.  It is applicable to any
LSP for which the upstream LSR chooses not to merge - whether
or not it is merge capable.

    Therefore, if you were expecting there to be a call-out - of the
sort "if the LSR is non-merge capable", then you will continue to
be disappointed.  :-)

    If you look at the procedures for handling label mappings, you
will see that the notion of handling a requested label is dealt with
irrespective of the label distribution mode (DU/DoD).  You will
also see that there is nothing in the procedures for handling a
label request that prevents an LSR from responding to one even
if the mode of operation is supposed to be DU.

    If I can request a label - and get a distinct one - whenever I
want one (unless and until the peer runs out), then I can handle
both the case where the peer is merge capable and the case
when the peer is simply merge-averse.

--
Eric Gray

You wrote:

> Eric Gray wrote:
> >
> >     Near as I can tell, these are all right.  However, LDP does
> > explicitly describe the handling of 'unsolicited label mappings' in
> > procedures for receiving label mappings in Appendix A.  Look into
> > the behaviors with respect to getting a label mapping for which
> > there is no outstanding request - that's pretty much what it's all
> > about.
>
> Yes, but the pseudocode there doesn't talk about non-merge-capable
> routers requesting additional labels.  The only mention of merge-
> capable vs. non-merge-capable in Appendix A is in the context of whether
> or not to include a Path Vector TLV.
>
> -- David

---

From: Eric Gray <[email-masked]>
Date: Thu, 19 Apr 2001 11:35:57 -0400

Yu,

    The ability to send a single label mapping with multiple
FECs allows for an optimization that may make some sense
if the predominant mode of operation is DU, ordered control
for merging LSPs.  There are those who think this optimization
is of dubious value, even then.  Use of this mechanism when a
label is requested for a specific FEC makes even less sense.

    The implication is that an LSR waits for some period of
time to accumulate FEC forwarding information where the
forwarding for a set of FECs is coincidental.  This requires
upstream LSRs to merge traffic associated with all of the
FECs for this downstream label.  The interesting thing is that
this behavior has heavier implications for downstream LSRs
than for upstream LSRs since the upstream LSR - if it is
merge capable - can simply send a label mapping to its own
upstream peers with the same set of FECs (thus avoiding a
need to perform the additional merge locally).

    The implications to dowstream LSRs are potentially much
worse.  At some downstream LSR, this LSP may need to split,
so that routes to a proper subset of the set of FECs for this
LSP can be observed.  This would require termination of
the existing LSP at that LSR and performing an IP header
lookup to find the correct downstream LSP on which to
further forward packets received on this LSP.  If that is
not acceptable to the LSR that would be required to do
this, it will not issue a label mapping for this set of FECs
(instead issuing multiple label mappings, possibly for each
subset of FECs that requires different forwarding).  This
behavior would repeat until an LSR is reached that has no
choice but to terminate the LSP and perform an IP lookup
(this would be the domain egress).

    As you can see, this argues against using the multi-FEC
approach with either DoD label distribution or independent
control - since either would result in LSP setup thrashing.

    In the event that an LSR sends such a label mapping
to an upstream peer that is not merge capable, the LSR
receiving this label mapping would have no choice but to
release (at least all but one of) the FECs associated with
the label mapping and request additional labels for each
of these FECs.  Note that releasing a label releases the
binding of that label to a FEC; the label may remain valid
for other FECs.  Following the procedures defined in LDP,
this would result in distinct labels for each FEC.  If this
was being done for all such label mappings, the LSR  that
was attempting to be clever by using a single label for
multiple FECs had best not be learning impaired or things
could get pretty ugly.

    In the event that the upstream LSR is simply merge
averse (for some reason and with respect to some LSPs),
it can reduce the amount of merging it has to do by trying
to push this set of FECs on its upstream peers.  If that is
not good enough (or doesn't work), it can do pretty much
the same thing as the non-merge capable LSR behavior
described in the paragraph above.

    But the case where you have non-merge capable LSRs
using DU label distribution is self-cancelling because DU
label distribution does not make a lot of sense when using
conservative label retention.  Since non-merging (and, to
some extent at least, merge-averse) behavior makes the
most sense in ATM LSRs, and ATM LSRs tend to use
conservative label retention, the combination of non-merge
capable LSRs using DU label distribution is a little off the
beaten path.

    Hopefully, this makes some sense and clears things up.

--
Eric Gray