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

[Eric Rosen <erosen at cisco.com>]

I think Yakov's  reply makes it pretty clear that  adoption of this document
as a WG document at the current time is premature.

I was  prepared for someone to  say that the  issues I raised can  be worked
after the  document is accepted.  However,  we see from  Yakov's answer that
he,  at least,  wants to  suppress discussion  of all  the  remaining issues
(after all, they're  all FUD ;-)).  I didn't think my  reputation in this WG
was that of a FUD-provider, but YMMV ;-)

For the kind of document that draft-morin seems to be, I think it is the job
of the authors to investigate all  the issues, not to say "we won't consider
any issue until some  else proves beyond a shadow of a  doubt that there's a
real problem".  Of  course, I'll be happy to work with  the authors to flesh
out  all the  arguments  pro and  con.  I'm  not  trying to  prove that  the
BGP-based scheme won't  work, but I'd have thought  that everyone knows that
all proposals have  pros and cons; a "considerations"  document should bring
out all the issues.

In fairness, Yakov isn't one of the  authors of the document, so it would be
interesting to know whether the authors  of the document agree that there is
no need to discuss any of the issues I've raised.

A few of the more outrageous comments do require some reply:

> why should the draft talk about this [variety of factors for which we lack
> hard data] since facts are scarce ?

Any choice  which is based  on opinion  rather than facts  is a risk,  and a
"considerations"  document should certainly  make it  clear when  such risks
exist.

> Moreover since PIM is based on unreliable message exchange, "join latency"
> with PIM could be in 10s of seconds.

The worst  case join latency in  either case could be  arbitrarily long, but
I'm sure everyone knows ((well, almost everyone ;-)) that's it's the average
join latency that is important.  Since packets don't usually get lost in the
backbone, that's  not much of  an issue.   I don't think  it takes a  lot of
fancy analysis  to determine  that it's  faster to send  a data  packet from
point A  to point B then  to send it from  point A to  an intermediate point
where it  is processed and then afterwards  sent along to point  C.  One can
argue  that the  latency increase  isn't significant,  or that  it's  a good
tradeoff  against something  else,  but it's  just  silly to  deny that  the
latency increase exists!

> could  please  quantify  "significantly"  as  you assert  that  "BGP  will
> significantly increase the latency".

I did  not state that  BGP will significantly  increase the latency,  I said
that we  do not have  the data to  determine whether BGP  will significantly
increase the latency.

A "significant  increase" would be one  that causes a visible  effect to the
users of a multicast-based application.

>  "Dampening of  withdrawals [as opposed to updates]  of C-multicast routes
>   does not impede the multicast join latency observed by MVPN customers,"

Sure, but  it doesn't have the same  effect on churn reduction  as does join
dampening, and it has other side-effects as well.  This is certainly an area
that would benefit from more analysis in any "considerations" document.

> Since you are a co-author on that draft, you should be aware of this.

I'm glad  you remembered that I'm  a co-conspirator (err,  co-author) of the
BGP-based multicast control plane.  As  a co-author, I am familiar with lots
of  issues  that  might  not  necessarily  be  obvious  to  the  authors  of
draft-morin.  Further,  I appear  to be the  only co-author who  thinks that
both  BGP and  PIM have  merits, and  that it  is important  to do  a pretty
thorough and unbiased comparison.

> As for the last "effect on existing L3VPN route reflector systems",
> please note the the following text in Section 15 of
> draft-ietf-l3vpn-2547bis-mcast-bgp:

>   Moreover, Route Reflectors used for MVPN do not have to be 
>   used for VPN-IP routes

> And as a reminder, you are a co-author on that draft !

Yes, I am well aware that you  can add new RRs expressly to handle multicast
routes.  In  a "considerations" document, the  need (or lack of  need) to do
this is one of the considerations  that should be discussed.  Unless the SPs
are willing to say up front "not to worry, we don't care how many additional
RRs we need, they come for free and do not increase our operational burden".

As you know, I am a big fan of the 2547 technology :-), but the issue of how
the VPN-IP routes affect BGP generally (and how much "BGP churn" they cause)
has  always  been with  us.   At  least VPN-IP  routes  do  not behave  much
differently than  IP routes, since  updates are still triggered  by topology
changes and  not by  enduser activity.  MVPN  introduces a different  set of
dynamics to BGP and the impact on  the rest of the BGP system is certainly a
consideration that needs to be better understood.

It is fair  to point out that additional BGP activity  is at least partially
compensated for by reduced PIM activity.  On the other hand, PIM activity 
doesn't impact the BGP system, so this comparison is not straightforward.

> In fact, can you explain why having one architecture for unicast
> VPN (aggregated routing) and another architecture for multicast VPN
> (virtual routers) is any better than having the same architecture
> for both unicast and multicast VPN ?

I  think the  choice between  the two  schemes should  be based  not  on the
elegance of  the architecture but on  the multitude of  facts that determine
(a) how well the multicast applications in the enterprise will be supported,
and (b) how much operational impact they have on the SP.  

Further, multicast  routing is  really a very  different thing  than unicast
routing, and  there is  no history of  success in  combining the two  into a
single architecture (e.g., MOSPF).

This is  not to say  that BGP is  a poor choice, but  just to explain  why I
don't  think that  the  uniformity  of the  architecture  is the  overriding
considerations. 

> First of all, autoRP is a cisco proprietary technology. Asking
> standards to support cisco proprietary technology is inappropriate.

If  an enterprise  is using  proprietary technology,  and if  a SP  wants to
provide MVPN service to that enterprise,  then I think the SP will certainly
want to know whether he has to  tell the enterprise "no MVPN service for you
until you change your deployed technologies" ;-)

A large number of enterprises use Cisco technology, and I imagine that other
vendors would like to be able to provide PEs that support those enterprises.

> supporting BSR without  MI-PMSI has been explained in  the presentation at
> the  L3VPN  WG  meeting  (with  you  as one  of  the  co-authors  on  that
> presentation).

Many of  the presentations  we've given over  the years  presented solutions
which  turned out  to  be  unsatisfactory.  Certainly  the  support or  lack
thereof  for  BSR  is  something  that a  "considerations"  document  should
examine.

>> realistically, for  the foreseeable future, the use  of an MI-PMSI is
>>     going  to remain  the  only  method of  aggregation.

> Do you speak just for cisco, or for all other vendors as well ?

I would highly recommend that before eliminating the MI-PMSI, the SPs should
get solid  delivery dates from  their vendors for  upstream-assigned labels!
;-)

>> it is not clear that segmented inter-AS  S-PMSIs are scalable at all.

> Are they less scalable than non-segmented inter-AS S-PMSIs ?

In my mind, the issue is whether there's a real good inter-provider solution
at all. 

> If less work for the PEs is the goal, then one should not run 2547 VPNs,

Well, I'd like to hear the SPs  say that they don't care how much additional
work  the PEs  have to  do!  Or  that they  don't care  how  much additional
coordination they have  to do with their customers, or  that they don't care
how many  changes the customers  have to make  before they can buy  the SPs'
service. 

> the recommendations should  reflect position of SPs, not  vendors (and you
> are part of the latter, not the former).

I've yet to hear any SP say that they don't want my input because I work for
a  vendor.  If  any  do  feel that  way,  I'm sure  they  can  speak up  for
themselves.