The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

I do not think this document should be advanced to RFC status in its current
form, even as Informational.  I think there are a number of problems: 

1. Basically what this document says  is "obviously we need a solution which
   provides traffic engineered multicast  distribution trees, and we require
   that  the  solution  be  RSVP-TE  extensions  for  setting  up  multicast
   distribution trees". 

   The problem to which this is a solution is not very well characterized or
   explored,  so  it  is hard  to  judge  from  this document  whether  this
   particular solution is  the best one.  There is  no serious consideration
   of  alternatives,  so  we  don't  know really  know  why  one  particular
   solution should be required over another.  In any event, the requirements
   should  be general enough  so that  we can  compare various  solutions to
   them.  If  the requirement is "use  RSVP-TE", it's hard  to compare other
   solutions against it. 

   The solution being  required might be the best  solution to some problem,
   but one really can't tell from this document. 

2. The document  attempts to exhibit the  required solution as  being a good
   solution for a variety of problems being considered by other WGs, such as
   L2VPN,  L3VPN, and  PWE3.   However, the  solutions  which this  document
   sketches out are not fully thought out, and fail to consider a variety of
   thorny issues.  For example:

   - Providing  ethernet  multicast  support  is more  complex  than  merely
     setting up a P2MP LSP, as the ethernet specs pose ordering requirements
     that would  be violated  unless unicast packets  were also sent  on the
     multicast tree. 

   - The suggestion  to use this solution  for VPN multicast  seems to clash
     with  existing  proposals for  VPN  multicast,  but  this is  not  even
     considered. 

   Frankly, if we are looking for requirements that apply to L2VPN and L3VPN
   problems,  we should  be getting  the  requirements from  those WGs,  not
   telling those WGs that they are required to use a particular solution.

3. There is a "requirement" that the solution be applicable to GMPLS as well
   as MPLS.  I don't see where this requirement comes from.  For all I know,
   GMPLS might  introduce a variety of additional  complications that aren't
   necessary in MPLS.  If this is  so, I would not necessarily support using
   the same solution in both cases.

4. There  is  a  "requirement" that  it  be  possible  to set  up  multicast
   distribution trees without using multicast routing protocols.  Presumably
   the  assumption is  that setting  up  the distribution  trees is  greatly
   simplified if multicast routing is not  used.  While this may be true, it
   certainly needs  to be argued  in more detail.   I think we also  need to
   understand better  whether TE multicast trees  can be mixed  in a network
   with non-TE multicast trees.

5. Central  to the  original design  of RSVP  was the  goal of  using  it to
   establish  QoS for  multicast distribution  trees.  This  might  make one
   think  that RSVP  could be  combined with  PIM to  allow  for dynamically
   created distribution  trees to which  QoS can be applied.   However, this
   possibility  seems to  be immediately  ruled out  by  the "requirements".
   It's  not  very  clear  whether  the  use of  PIM  to  set  up  multicast
   distribution trees is supposed to  be compatible or incompatible with the
   traffic engineering of those trees.

6. The requirement that RSVP be enhanced so that it can add/remove receivers
   dynamically raises  the question of  whether too much multicast  stuff is
   being moved  into RSVP.   Do we need  to invent new  multicast join/prune
   mechanisms?  What's wrong with the ones we already have?

7. The document has  a number of places where it  is asserted that something
   is or is not "optimal" or "efficient", without any statement of just what
   resource is being used suboptimally or inefficiently. 

8. It  is not  clear to  me whether  these "requirements"  rule out  (or are
   intended to rule out) the use of bidirectional multicast trees. 

9. There  is  mention of  using  RSVP-TE multicast  LSPs  to  carry layer  2
   traffic, apparently without a PWE3 encapsulation.  This might be taken to
   infringe upon PWE3's charter. 

10. It is blithely stated that  RSVP-TE multicast allows for the creation of
   inter-AS  multicast distribution  trees.   Since inter-AS  considerations
   have proven to be  quite thorny for both multicast and TE,  it is hard to
   imagine   that   combining  multicast   with   TE   makes  the   inter-AS
   considerations any simpler. 

So I  think the  document needs considerable  additional work before  we can
consider advancing it.

By the  way, these  comments should  not be interpreted  as an  objection to
extending RSVP-TE  to support  multicast traffic engineering.   The comments
are directed  specifically at the particular document  under discussion, and
are not meant to favor or disfavor any particular solution.