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

[Thomas Morin <thomas.morin at orange-ftgroup.com>]

Hi Eric,

Eric Rosen :
> 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 ;-)).  
[...]
> 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.

Please let me restate that the intent indeed is to rationally treat all
issues that can help make recommandations on the preferred approaches.

> I didn't think my reputation in this WG was that of a FUD-provider, but YMMV ;-)

What is sure is that, for some of the points you raised, it will be
useful to have more facts and/or explanations so that we can cover them
in our document.

Have a good week-end,

-Thomas



> 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.
> 

> 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.
> 
> 
> 
> 
>