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

From: Nadeau Thomas <[email-masked]>
Date: Mon, 10 Mar 2008 18:54:48 -0400

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

---

From: Mark Townsley <[email-masked]>
Date: Mon, 10 Mar 2008 19:24:02 -0400

How about this:

1. Agree on what can be made mandatory in the architecture draft. If it 
can't be agreed upon, it's not mandatory.

 2. Specify which combinations of options don't work or make sense, in 
as concise a manner as possible.

 3. Document the applicability/tradeoffs of remaining options or sets of 
options.

Let me emphasize that ideally we produce as few sets of options as 
possible. The more options you have, the better your applicability 
statements and tradeoff analysis needs to be.

- Mark

Nadeau Thomas wrote:
>
>     Guys,
>
>     As entertaining as this sparring is, it is not brining us any 
> closer to resolution. Can't we all just get along? *)
>
>> I was  prepared for someone to  say that the  issues I raised can  be 
>> worked
>> he,  at least,  wants to  suppress discussion  of all  the  remaining 
>> issues
>> 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
>> argue  that the  latency increase  isn't significant,  or that  it's  
>> a good
>> I did  not state that  BGP will significantly  increase the latency,  
>> I said
>> A "significant  increase" would be one  that causes a visible  effect 
>> to the
>> that would benefit from more analysis in any "considerations" document.
>>
>> I'm glad  you remembered that I'm  a co-conspirator (err,  co-author) 
>> of the
>> both  BGP and  PIM have  merits, and  that it  is important  to do  a 
>> pretty
>> 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)
>> changes and  not by  enduser activity.  MVPN  introduces a different  
>> set of
>> I  think the  choice between  the two  schemes should  be based  not  
>> on the
>> routing, and  there is  no history of  success in  combining the two  
>> into a
>> thereof  for  BSR  is  something  that a  "considerations"  document  
>> should
>> examine.
>>
>>>> realistically, for  the foreseeable future, the use  of an MI-PMSI is
>> I would highly recommend that before eliminating the MI-PMSI, the SPs 
>> should
>>>> it is not clear that segmented inter-AS  S-PMSIs are scalable at all.
>>

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 11 Mar 2008 06:25:29 -0700

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 

>-----Original Message-----
>From: Nadeau Thomas [mailto:[email-masked]] 
>Sent: Monday, March 10, 2008 3:55 PM
>To: Rosen Eric; Yakov Rekhter; [email-masked]
>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
>
>	
>> document as a WG document at the current time is premature.
>>
>> this WG was that of a FUD-provider, but YMMV ;-)
>>
>> 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.
>>
>> 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.
>>
>>> 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
>> 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
>intermediate 
>> point
>> that  the latency increase exists!
>>
>latency,  
>> I said that we  do not have  the data to  determine whether 
>BGP  will 
>> significantly increase the latency.
>>
>>> routes  does not impede the multicast join latency observed by MVPN 
>>> customers,"
>>
>> 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.
>>
> used for 
>>> VPN-IP routes
>> 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".
>>
>> of how the VPN-IP routes affect BGP generally (and how much "BGP 
>> churn"
>> they cause)
>> 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.
>>
>> 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 ?
>>
>> supported, and (b) how much operational impact they have on the SP.
>>
>> 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
>> 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.
>>
>> solutions which  turned out  to  be  unsatisfactory.  
>Certainly  the  
>> support or  lack
>> should get solid  delivery dates from  their vendors for  
>> upstream-assigned labels!
>> ;-)
>>
>> solution at all.
>> 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
>>> (and you are part of the latter, not the former).
>>
>> work for a  vendor.  If  any  do  feel that  way,  I'm sure  
>they  can  
>> speak up  for themselves.
>>
>>
>>
>>
>>
>>
>
>

---

From: [email-masked]
Date: Tue, 11 Mar 2008 12:18:08 -0700 (PDT)

> elements defined in draft morin?

       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