Re: Comments on draft-morin-l3vpn-mvpn-considerations-01.txt

[Eric Rosen <erosen at cisco.com>]

> I'm interested in understanding why you have such a strong feeling about
> a statement that only recommends a relatively minor optional feature,

I am uncomfortable with it for a number of reasons:

- If an SP  wants to offer "outsourced RP" service  to its customers, that's
  fine.  That does  not necessarily require that the PEs  serve as RPs.  The
  "PE  as RP"  model  is a  particular  way of  deploying  an outsourced  RP
  service.   How best  to deploy  an outsourced  RP service  is a  topic for
  discussion between  an SP and  its vendors, and not  necessarily something
  that the IETF even needs to be involved in.

- I  cannot believe  that "PE  as RP"  is really  going to  be  the superior
  "outsourced RP" deployment model at scale.  

- The draft  gives the  appearance of recommending  (even if  not requiring)
  both the "outsourced RP" model and this particular method of deploying it.

- The  model itself  has what  I consider  to be  significant disadvantages,
  especially if  you try to deploy it  with a customer that  has an existing
  multicast infrastructure.

- I  don't think  the impression  you get  from the  draft is  that it  is a
  "relatively minor optional feature".   That sort of minor optional feature
  would typically get a "may" rather than a "should".

> The mVPN requirements (RFC4834) actually talk in terms of "MAY" about
> this feature. Is it the difference between "MAY" and "should", that
> makes you so strongly react ?

No objection to MAY.

> can you  explain how  implementing this optional  feature is  "primarily a
> simplification for the vendor" ?

It allows a vendor to ship product which supports only the "PE as RP" model,
while  still claiming  to have  ASM support  in its  MVPN product.   This is
considerably less  of an  implementation effort than  is required  to really
provide ASM support.