Subject: draft-loa-mpls-cap-set-01.txt

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Nov 1999 12:58:47 -0500

I'm not sure what  the purpose of this document is, or  why anyone thinks it
might be helpful.  It just seems  to add to the confusion.  My understanding
is that it  is intended for the "Informational RFC" track,  but I just don't
see that  it provides any  interesting or useful information.   Certainly it
doesn't  help anyone  figure out  what they  need to  implement in  order to
achieve any  particular function, to support any  particular application, or
to  interoperate  with  any  particular implementation.   The  criteria  for
grouping a bunch of stuff into  a "capability set" are never given, and it's
a mystery to me just what they might be.

I  could imagine  a  use for  a  document which  defined  the following  six
"capability sets":

1. Basic Intra-domain Hop by Hop Functionality
   
   Basic LDP mechanisms (discovery, etc.) plus:

   a. For non-merging ATM-LSRs, downstream on demand ordered mode
   b. For frame LSRs, downstream unsolicited independent mode
   c. For merging ATM-LSRs, either 

2. Traffic engineering functionality

   a. For signalling and QoS, RSVP
   b. For passing routing constraints, OSPF extensions

3. BGP label distribution

4. 1+2

5. 1+3

6. 1+2+3

But even  this is too  imprecise to  be of that  much use, since  it doesn't
precisely  define  (in terms  of  protocol  message  fields and  procedures)
exactly what is required.  And it  doesn't say whether any of the parameters
or  procedures  which  are optional  in  the  specs  are mandatory  (or  not
included) in the capability sets. 

I find it somewhat difficult  to determine whether these six capability sets
are included in the draft or not.   Also, in order to get WG consensus, we'd
probably have to add about 12  more capability sets, most of which are quite
useless  and will  never get  deployed.  I  don't see  much point  in having
another  document which  provides a  large  group of  confusing options;  we
already have the official specifications  for that ;-) Alternatively, we can
use this  document as  a reason for  revisiting all  the fights of  the last
several years, but it is hard to regard that as "helpful".

It might be better  to revisit this in a year or two,  when it will be clear
what has been deployed, and we can start eliminating cruft from the specs on
grounds of  non-deployment.  In the meantime,  I would like  to suggest that
this document not go forward.