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

[tnadeau at lucidvision.com]

> Tom,
>
> I think that splitting the current solutions document into two is a
> great idea.  The current solutions document is pretty much unreadable.
>
> Presumably, the one solutions document would consist of the mandatory
> elements defined in draft morin?
>
> Thanks,
>
> John

       John,


	Ideally that is what I think we all want; however, the mandatory elements
of  each approach specified in draft-morin are parts of two actual
solutions, and it seems at least last night that no agreement will happen
on that combined set within our lifetimes. What I was suggesting is to
have two separate WG documents: one for each solution. Within each
document we want to clearly specify the mandatory bits of each approach.
In particular, wherever there is an option to do 2 or more things, there
must be 1 mandatory approach spelled out in the solution document. This I
hope, would foster better interoperability. This way both camps
officially spell-out the mandatory parts of implementing their solution,
and then the market can decide on which approach to use.

	--Tom




>
>>-----Original Message-----
>>From: Nadeau Thomas [mailto:tnadeau at lucidvision.com]
>>Sent: Monday, March 10, 2008 3:55 PM
>>To: Rosen Eric; Yakov Rekhter; l3vpn at ietf.org
>>Subject: Re: Comments on draft-morin-l3vpn-mvpn-considerations-01.txt
>>
>>
>>	Guys,
>>
>>	As entertaining as this sparring is, it is not brining
>>us any closer to resolution. Can't we all just get along? *)
>>
>>	What we (at BT) want from this document is pretty
>>simple and is achievable within the confines of a WG document:
>>one set of mandatory operations/constructs with the rest set
>>to optional. It seems the only way to achieve this is to write
>>two WG solutions documents and let the market decide.
>>
>>	--Tom
>>
>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>