Subject: rfc3035

From: Jane Jiang <[email-masked]>
Date: Wed, 11 Jul 2001 05:53:18 -0700 (PDT)

Hi, all,

I have a question regarding a paragraph on page 2 of
rfc3035, "This label distribution technique MUST be
used by ATM-LSRs that are not capable of "VC merge",
and is OPTIONAL for ATM-LSRs that are capable of VC
merge.".  

I don't understand why the words "MUST" and "OPTIONAL"
should be used respectively here.

Regards,
Jane D. Jiang

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

---

From: Eric Gray <[email-masked]>
Date: Wed, 11 Jul 2001 15:34:55 -0400

Jane,

    Short answer - because it makes sense that way.

    In general, the combination of non-merging and downstream unsolicited
label distribution is difficult to make work. However, the bulk of the work
on RFC 3035 was already done before specific support for non-merging was
added to LDP and - among label distribution protocols - LDP is the only
one which offers a choice between DU and DoD.  MPLS BGP only supports DU
distribution (merging implied), but would only apply to lower level labels
(in the shim layer label stack) in conjunction with ATM LSRs.  RSVP-TE and
CR-LDP only support DoD distribution.

    Since the merge capability of an LSR is not part of the information a
a peer can reliably determine from label distribution, this statement has
little value except to establish a basic set of assumptions used throughout
the remainder of the specification; but this might be a huge value.  If the
statement you point out (also stated in section 8 of the RFC) is complied
with exactly, then the fact that an LSR announces it would prefer to use
downstream unsolicited label distribution (during LDP session establishment)
can be construed to mean that it is merge capable (and this would be likely
to be true even if not specified) - but the reverse is not true (asserting
DoD does not necessarily mean that an LSR is not merge capable).  So it is
difficult to see why it might be important, for interoperation with a peer,
that this behavior is strictly adhered to - but it might be.

    Because the base LDP specification supports requesting additional
labels for a given FEC irrespective of the merge capability of the LSR,
it might be possible for an ATM LSR to pretend to be merge capable
even though it is not.  But then the implementation would be cheating
on the specification and it would fall on the implementer to make sure
that the implementation interoperates with specificationally correct
implementations.  This would require extensive analysis of procedures
specified in section 8 of the RFC to ensure that the 'cheat' is not
detectable by (i.e. - it would not trip up) a compliant LSR peer.  I am
not sure what advantage an implementer would expect to achieve through
this particular cheat, and the cost might be very high.

--
Eric Gray