Subject: Advancing the Protocol and Morin Drafts

From: Marshall Eubanks <[email-masked]>
Date: Wed, 1 Oct 2008 10:04:07 -0400

This email starts a 3 week call for input, to expire October 23, 2008,  
for the following steps:

1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working
group document;  and

2.) To turn this document into a requirements draft, with mandatory to
implement features for an interoperable implementation. The authors
have indicated that they are willing to do this.

Our intention is, if this approach is accepted, to then begin WG last
call to submit to the IESG for publication:

draft-ietf-l3vpn-2547bis-mcast
draft-ietf-l3vpn-2547bis-mcast-bgp

We expect that these two documents will be submitted more or less as is
(i.e., certainly with any new bug fixes or other necessary corrections  
and
improvements, but without specific mandatory to implement feature
description in those drafts).

Please respond to the list with your recommendations for these two
courses of action.

Regards
Marshall & Danny

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 1 Oct 2008 07:38:01 -0700

Yes 

>-----Original Message-----
>From: Marshall Eubanks [mailto:[email-masked]] 
>Sent: Wednesday, October 01, 2008 7:04 AM
>To: [email-masked]
>Cc: Ross Callon
>Subject: Advancing the Protocol and Morin Drafts 
>
>This email starts a 3 week call for input, to expire October 
>23, 2008, for the following steps:
>
>1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a 
>working group document;  and
>
>2.) To turn this document into a requirements draft, with 
>mandatory to implement features for an interoperable 
>implementation. The authors have indicated that they are 
>willing to do this.
>
>Our intention is, if this approach is accepted, to then begin 
>WG last call to submit to the IESG for publication:
>
>We expect that these two documents will be submitted more or 
>less as is (i.e., certainly with any new bug fixes or other 
>necessary corrections and improvements, but without specific 
>mandatory to implement feature description in those drafts).
>
>Please respond to the list with your recommendations for these 
>two courses of action.
>
>Regards
>Marshall & Danny
>
>

---

From: Thomas Morin <[email-masked]>
Date: Wed, 01 Oct 2008 18:05:48 +0200

Support this approach.

(detailed input from chairs will be welcome on the precise changes that
are needed.)

Thanks,

-Thomas

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 01 Oct 2008 09:15:22 -0700

Support.

---

From: David Ward <[email-masked]>
Date: Wed, 1 Oct 2008 11:16:01 -0500

Should #2 come before #1?

-DWard

On Oct 1, 2008, at 11:05 AM, Thomas Morin wrote:

>> mandatory to

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 01 Oct 2008 17:38:48 +0100

Support.  Ben

---

From: Ina Minei <[email-masked]>
Date: Wed, 1 Oct 2008 09:47:25 -0700 (PDT)

Support.

On Wed, 1 Oct 2008, Marshall Eubanks wrote:

> This email starts a 3 week call for input, to expire October 23, 2008, for 
> the following steps:
>
> (i.e., certainly with any new bug fixes or other necessary corrections and

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 1 Oct 2008 13:44:13 -0400

Support.

	--Tom

---

From: "Marco Rodrigues" <[email-masked]>
Date: Wed, 1 Oct 2008 14:16:21 -0400

I'm in support of this direction.

-mpr

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Marshall Eubanks
> Sent: Wednesday, October 01, 2008 10:04 AM
> To: [email-masked]
> Cc: Ross Callon

---

From: "Ross Callon" <[email-masked]>
Date: Wed, 1 Oct 2008 14:49:53 -0400

Dave;

Prior to its becoming a working group document, the change authority
rests with the authors.  Once the WG accepts the document as a WG
document, then change control goes to the working group.  Then the WG
has authority to change the document according to consensus, and the
authors don't have the authority to refuse to make a change so long as
there is clear consensus in the working group for the change.  

Ross

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: 01 October 2008 12:16
To: Thomas Morin
Cc: David Ward; Marshall Eubanks; Ross Callon; [email-masked]
Subject: Re: Advancing the Protocol and Morin Drafts

-DWard

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 1 Oct 2008 12:49:15 -0700 (PDT)

I support this approach.

-) This email starts a 3 week call for input, to expire October 23, 2008, for
-) the following steps:
-) 
-) 1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working
-) group document;  and
-) 
-) 2.) To turn this document into a requirements draft, with mandatory to
-) implement features for an interoperable implementation. The authors
-) have indicated that they are willing to do this.
-) 
-) Our intention is, if this approach is accepted, to then begin WG last
-) call to submit to the IESG for publication:
-) 
-) draft-ietf-l3vpn-2547bis-mcast
-) draft-ietf-l3vpn-2547bis-mcast-bgp
-) 
-) We expect that these two documents will be submitted more or less as is
-) (i.e., certainly with any new bug fixes or other necessary corrections and
-) improvements, but without specific mandatory to implement feature
-) description in those drafts).
-) 
-) Please respond to the list with your recommendations for these two
-) courses of action.
-) 
-) Regards
-) Marshall & Danny
-)

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 01 Oct 2008 14:35:13 -0700

Yes

R.

---

From: Shane Amante <[email-masked]>
Date: Wed, 1 Oct 2008 22:03:43 -0600

Support.

-shane

On Oct 1, 2008, at 8:04 AM, Marshall Eubanks wrote:
> This email starts a 3 week call for input, to expire October 23,  
> 2008, for the following steps:
>

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 09:40:48 +0200

Folks,

I support this approach.

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Marshall Eubanks
Envoyé : mercredi 1 octobre 2008 16:04
À : [email-masked]
Cc : Ross Callon
Objet : Advancing the Protocol and Morin Drafts 

This email starts a 3 week call for input, to expire October 23, 2008, for the following steps:

1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working group document;  and

2.) To turn this document into a requirements draft, with mandatory to implement features for an interoperable implementation. The authors have indicated that they are willing to do this.

Our intention is, if this approach is accepted, to then begin WG last call to submit to the IESG for publication:

We expect that these two documents will be submitted more or less as is (i.e., certainly with any new bug fixes or other necessary corrections and improvements, but without specific mandatory to implement feature description in those drafts).

Please respond to the list with your recommendations for these two courses of action.

Regards
Marshall & Danny

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 09:47:18 +0200

Hello, 

I support this approach. 

Regards, 

	Dina SOL 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Marshall Eubanks
Envoyé : mercredi 1 octobre 2008 16:04
À : [email-masked]
Cc : Ross Callon
Objet : Advancing the Protocol and Morin Drafts 

Regards
Marshall & Danny

---

From: Ron Bonica <[email-masked]>
Date: Thu, 02 Oct 2008 16:03:42 -0400

support

---

From: "HEMIGE Venu" <[email-masked]>
Date: Fri, 3 Oct 2008 05:00:27 -0500

Support. 

-----Original Message-----
Of Marshall Eubanks

2.) To turn this document into a requirements draft, with mandatory to
implement features for an interoperable implementation. The authors have
indicated that they are willing to do this.

We expect that these two documents will be submitted more or less as is
(i.e., certainly with any new bug fixes or other necessary corrections
and improvements, but without specific mandatory to implement feature
description in those drafts).

Regards
Marshall & Danny

---

From: Renwei Li <[email-masked]>
Date: Fri, 03 Oct 2008 11:52:51 -0700

I support it...

Renwei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marshall Eubanks
Sent: Wednesday, October 01, 2008 7:04 AM
To: [email-masked]
Cc: Ross Callon
Subject: Advancing the Protocol and Morin Drafts

Regards
Marshall & Danny

---

From: "Joorde, Uwe" <[email-masked]>
Date: Mon, 6 Oct 2008 10:10:58 +0200

Support.

Uwe Joorde

Deutsche Telekom AG
T-Com, Technology Engineering Center
Uwe Joorde
Technik Internet Backbone, TE142-12
Hammer Str. 216 - 226, 48153 Münster
+49 251 7985 406 (Tel.)  
+49 251 7985 109 (Fax)
E-Mail: [email-masked]
http://www.t-com.de

Registerrechtliche Unternehmensangaben:
Deutsche Telekom AG
Aufsichtsrat: . Dr. Ulrich Lehner (Vorsitzender)
Vorstand: René Obermann (Vorsitzender), 
Dr. Karl-Gerhard Eick (stellvertretender Vorsitzender),
Hamid Akhavan, Timotheus Höttges, Thomas Sattelberger
Handelsregister: Amtsgericht Bonn HRB 6794,
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.: DE50478376

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Marshall Eubanks
> Gesendet: Mittwoch, 1. Oktober 2008 16:04
> An: [email-masked]
> Cc: Ross Callon
> Betreff: Advancing the Protocol and Morin Drafts 
> 
> less as is

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 7 Oct 2008 10:18:42 -0400

I agree with Dave. What is needed is a complete and solid requirements
draft representing service providers offering MVPN service. The
recommendations draft is not going to be useful.

Maria

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of David Ward
>Sent: Wednesday, October 01, 2008 12:16 PM
>To: Thomas Morin
>Cc: Ross Callon; David Ward; [email-masked]

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 7 Oct 2008 17:42:36 +0200

In the introduction of draft-morin-l3vpn-mvpn-considerations-03 it  
says that this document is intended ensure interoperable solutions  
across vendors. But when I read the body of the document it turns out  
to be a comparison document between most the available options, and  
the author preferred options are listed as should or must. I've a few  
comments on that:

1. By listing what is a MUST does not guarantee interoperable  
solutions. Its like giving the ingredients for baking a pie, without  
saying how to put it together. As a result you'll see many different  
pie's and you'll be surprised how many variations are possible.

2. The document does not make any recommendation for the core tree  
building, it recommends all options to be implemented. But if one  
vendor implements TE and the other vendor implements mLDP, you don't  
have an interoperable solution.

3. Comparing the different options, like PIM vs BGP for route  
signaling, is controversial. Its similar to OSPF vs ISIS or RSVP-TE  
vs CR-LDP.

So I don't think this draft in its current form provides a solution  
to the real problem, so I vote no.

What I would suggest is to step over the whole comparison of options  
and just create a draft that documents how a particular solution fits  
together based on the protocol drafts that have been written. Then a  
customer can go to the vendor and ask for the solution they want  
implemented.

Thx,

Ice.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Oct 2008 17:08:00 -0700

Hey Ice,

Wonderful analogy !!!

> 1. By listing what is a MUST does not guarantee interoperable solutions. 
> Its like giving the ingredients for baking a pie, without saying how to 
> put it together. As a result you'll see many different pie's and you'll 
> be surprised how many variations are possible.

Is this a good thing or bad thing ? After all variations in pie making 
should be encouraged. This is what make the taste or service really 
good. Do you like to have the same taste of a pie when you go to a 
different restaurant ?

Have you ever seen a real chef who opens a cook-book to cook ? If he is 
a good one he knows how to cook by heart.

With this in mind let's don't underestimate the skills of our customers. 
  In my opinion ISPs and service providers can cook really well just 
with ingredients they possess. They do not need to be told how to 
engineer their networks by any vendor or IETF. If anything is missing 
they will surely ask for it either you and me.

So since you agree and admit that you can end up with a pie(s) based on 
current ingredients I really don't see why we should cut the imagination 
on how to mix them together :).

Cheers,
R.

PS. It beats me why you have not used the "pudding" analogy :)))

---

From: Eric Rosen <[email-masked]>
Date: Wed, 08 Oct 2008 09:10:42 -0400

Opposed.

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 15:36:13 +0200

I support this approach.

Greg

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De 
la part de Marshall Eubanks
Envoyé : mercredi 1 octobre 2008 16:04
À : [email-masked]
Cc : Ross Callon
Objet : Advancing the Protocol and Morin Drafts 

Regards
Marshall & Danny

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 17:56:41 +0200

Support.

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 14:43:09 -0400

Fully support the two step approach outlined below. 

Zubair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marshall Eubanks
Sent: Wednesday, October 08, 2008 1:59 AM
To: [email-masked]
Cc: Ross Callon
Subject: Advancing the Protocol and Morin Drafts

Regards
Marshall & Danny

---

From: "SUNDT, MARK R, ATTLABS" <[email-masked]>
Date: Wed, 8 Oct 2008 15:54:45 -0400

Opposed.  I do not support this approach.

Mark

-----Original Message-----

Regards
Marshall & Danny

---

From: "RAMACHANDRAN, PRASANNA, ATTOPS" <[email-masked]>
Date: Wed, 8 Oct 2008 19:19:08 -0400

I vote NO.

Being in AT&T Advanced Tier support group and having supported the MVPN
core for the last 2 years, I can clearly say that we need a solution
such as PIM-BiDir that can reduce the number of multicast states in the
PEs to be able to scale the Groups X Sources x OILs explosion for our
very large Enterprise customers.   We definitely do not want to tweak a
crucial protocol like BGP of which our scale is 2 Million VPNV4 routes
in the US alone.

Prasanna Ramachandran
Advanced Technical Support - Internet Edge
AT&T Global Network Operations
Voice# 732-420-6439
Email # [email-masked]
"This email and any files transmitted with it are AT&T property, are
confidential, and are intended solely for the use of the individual or
entity to whom this email is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received
this message in error, please notify the sender and delete this message
immediately from your computer. Any other use, retention, dissemination,
forwarding, printing, or copying of this email is strictly prohibited."

-----Original Message-----

Regards
Marshall & Danny

---

From: "Paul Wall" <[email-masked]>
Date: Wed, 8 Oct 2008 20:56:19 -0400

Support.

Drive slow,

Paul Wall.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 8 Oct 2008 18:42:04 -0700

Hi Marshall & Danny,

On Oct 1, 2008, at 7:04 AM, Marshall Eubanks wrote:

Support.

> Please respond to the list with your recommendations for these two

Kireeti.

---

From: "ROSENBERG, ERIC, ATTLABS" <[email-masked]>
Date: Wed, 8 Oct 2008 13:44:30 -0400

opposed - I do not support  this approach

Eric Rosenberg

-----Original Message-----

Regards
Marshall & Danny

---

From: "Abdul Rahim (arahim)" <[email-masked]>
Date: Wed, 8 Oct 2008 20:20:30 -0700

Oppose  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marshall Eubanks
Sent: Wednesday, October 01, 2008 8:04 PM
To: [email-masked]
Cc: Ross Callon
Subject: Advancing the Protocol and Morin Drafts 

Regards
Marshall & Danny

---

From: "Alia Atlas" <[email-masked]>
Date: Thu, 9 Oct 2008 06:04:39 -0400

Support.

Alia

---

From: Rajiv Papneja <[email-masked]>
Date: Thu, 09 Oct 2008 09:44:16 -0400

Support. /R

On 10/1/08 10:04 AM, "Marshall Eubanks" <[email-masked]>
wrote:Marshall Eubanks

---

From: <[email-masked]>
Date: Thu, 9 Oct 2008 10:00:12 -0400

Hi

I support.

Thanks

Ketan.

Ketan Paralkar MIET , CCIE 12179, JNCIS
Sr. Network Architect
BELL SYSTEMS & TECHNOLOGY
Technology Development
Bell Canada
76 Adelaide Street West, 15th Floor
Toronto, Ontario
M5H 1P6
Office  (416)-353-3227
e-mail : [email-masked]

---

From: "RAMSAROOP, JEEWAN P, ATTLABS" <[email-masked]>
Date: Thu, 9 Oct 2008 10:06:16 -0400

I vote NO.

The correct sequence is to agree on the MVPN requirements which are
stated in draft-mnapierala-part-reqt, which represents the requirements
from a large service provider, with many hundreds of in-service M-VPNs,
many thousands of MVPN ports, and many different multicast application
on those M-VPNs. Our requirements come from several years of experience
with this technology.

Jeewan Ramsaroop
Director New Technology Development
AT&T Labs.  

-----Original Message-----

Regards
Marshall & Danny

---

From: "SZELA, MATEUSZ W (MATT), ATTLABS" <[email-masked]>
Date: Thu, 9 Oct 2008 11:42:15 -0400

>  Marshall & Danny et al,
> 
> I do NOT SUPPORT this draft.
> 
> The proposed draft, does not consider the needs and requirements of
> large Service Providers with huge MVPN deployed base that services
> critical business customers.
> 
> The correct approach is to poll Service Providers, who use MVPN now,
> first and agree on a set of requirements that consider the needs of
> the SP and end customers.
> The requirements must consider the needs of the Business Customers who
> use large SP MVPN networks.
> 
> 
> Tx,
> 
> Matt W. Szela
> Director,
> New Technology Product Dev. Eng.
> AT&T Laboratories
> [email-masked]
> v: 732-420-6828
> c: 732-208-5341
>

---

From: "SZELA, MATEUSZ W (MATT), ATTLABS" <[email-masked]>
Date: Thu, 9 Oct 2008 11:14:07 -0400

Marshall & Danny et al,

The correct approach is to poll Service Providers, who use MVPN now,
first and agree on a set of requirements that consider the needs of the
SP and end customers.
The requirements must consider the needs of the Business Customers who
use large SP MVPN networks.

Tx,

Matt W. Szela
Director,

-----Original Message-----

Regards
Marshall & Danny

---

From: Thomas Morin <[email-masked]>
Date: Fri, 10 Oct 2008 11:50:55 +0200

Hello,

RAMACHANDRAN, PRASANNA, ATTOPS :
> such as PIM-BiDir that can reduce the number of multicast states in
> the PEs to be able to scale the Groups X Sources x OILs explosion for
> our very large Enterprise customers.   

Let me split your comment into the "requirement" and the suggested
"solution".

Your requirement: "[...] reduce the number of multicast states in the
PEs to be able to scale the Groups X Sources x OILs explosion for our
very large Enterprise customers"

  --> PE scalability is certainly a requirement common to all operators
      interested in mVPN. It isn't new, and is already explicitly
      expressed in RFC4834. Your statement, based on a large deployment,
      confirms that current solutions based on draft-rosen are not
      satisfying. This is 100% in line with the analysis in
      draft-morin-l3vpn-mvpn-considerations which concludes that mVPN
      routing with the PIM LAN procedures is not the most efficient 
      architecture for PE scalability.

The solution you suggest: "a solution such as PIM-BiDir [...]"

  -> this statement is technically quite vague, but the helpful
  interpretation provided by Ice indicates that you favor the 
  MS-PMSI approach 

  Let me insist on a few points:
  - that solution breaks an important requirement of RFC4834, section
    5.2.4.1  (a multicast vpn requirement document, that had a long time
    to mature, and on which AT&T participated)
  - if you look closely that solution does not provide any PE
    scalability benefit over mvpn routing done with BGP, and provides
    roughly the same P scalability benefit (though it can, in some
    scenarios, provide an improvement over PIM LAN procedures like in
    draft-rosen) -- I don't think it can be a solution to the
    requirement you exposed
  - that solution is not in the scope of items being worked on by the
    working group ; we can see multiple reasons explaining this: among
    others, this proposal comes late compared to other proposals, and
    didn't receive much support among vendors or operators (not
    unrelated to the reasons mentioned above)

  By any means, the fact that you happen to prefer the MS-PMSI approach,
  looks to me as quite unrelated to the adoption of
  draft-morin-l3vpn-mvpn-considerations, which is focused on current
  work items of the working group and does not state anything related to
  any future new work (that may or may not happen to provide a benefit)

> We definitely do not want to tweak a crucial protocol like BGP of
> which our scale is 2 Million VPNV4 routes in the US alone.

How is this related to opposing adoption of
draft-morin-l3vpn-mvpn-considerations ?

Let me remind that draft-morin-l3vpn-mvpn-considerations does *not*
preclude the use of PIM for multicast VPN routing.  It merely
identifies, as you do based on operational experience, the limitations
of this approach compared to BGP-based mvpn routing.

Thank you,

-Thomas Morin

---

From: Thomas Morin <[email-masked]>
Date: Fri, 10 Oct 2008 12:00:01 +0200

Hello,

You could have sent this mail three times (instead of merely two) and
not only with underlined capitalized HTML text, but also a bold red
font. Few people know about this, but it can be counted as a dozen of
"votes"... ;)

Cheers,

-Thomas

SZELA, MATEUSZ W (MATT), ATTLABS :
>         The proposed draft, does not consider the needs and
>         requirements of large Service Providers with huge MVPN
>         deployed base that services critical business customers.
>         
>         The correct approach is to poll Service Providers, who use
>         MVPN now, first and agree on a set of requirements that
>         consider the needs of the SP and end customers.
>         
>         The requirements must consider the needs of the Business
>         Customers who use large SP MVPN networks.
>         
>         
>         Tx,
>         
>         Matt W. Szela 
>         Director, 
>         On Behalf Of Marshall Eubanks 
>         WG last 
>         two

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 10 Oct 2008 09:22:16 -0400

Thomas,

>      architecture for PE scalability.
This is not about PE-PE PIM scaling. This is about CE-PE PIM scaling. 

>  interpretation provided by Ice indicates that you favor the 

It is not vague. It is asking for PIM-Bidir support in MVPN context.
This is nothing to do with favoring MS-PMSI approach. MS-PMSI is just
one of possible approaches to support Bidir.
Maria

---

From: Thomas Morin <[email-masked]>
Date: Fri, 10 Oct 2008 16:44:56 +0200

Hi Maria,

> one of possible approaches to support Bidir.

(Sorry for misinterpreting, I got mislead by Ice comment wrt. MS-PMSI.)

But, well, then how was the comment related to adopting/not adopting 
draft-morin-l3vpn-mvpn-considerations ?

( The draft is in no way precluding any further work for PE-CE scaling
and certainly does not make any recommandation against the use of
Bidir-PIM... )

-Thomas

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 10 Oct 2008 09:08:05 -0700

Prasanna,

> crucial protocol like BGP of which our scale is 2 Million VPNV4 routes

On the subject of "we definitely do not want to tweak", I'd like
to remind you that during the early days of 2547 VPNs some of its
opponents were saying that they are against 2547 VPNs because they
do not want to "tweak" such a crucial protocol as BGP to carry VPNv4
routes.

Today AT&T has "2 million VPNv4 routes in the US alone" all carried
in BGP, and a successful 2547 VPN service. None of this would be
possible if we would not tweak BGP.

Yakov.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 10 Oct 2008 13:10:39 -0400

I support the original proposal.

Chers,
Andy

---

From: "Paul Wall" <[email-masked]>
Date: Fri, 10 Oct 2008 13:51:51 -0400

I'm not sure this draft is worth advancing either.

In fact, I'm not sure it's worth the paper it's printed on.

Drive Slow,
Paul Wall

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 10 Oct 2008 13:19:19 -0700

Marshall,

I support.

Yakov.

---

From: "Mike McBride (mmcbride)" <[email-masked]>
Date: Fri, 10 Oct 2008 13:26:30 -0700

Opposed.
mike

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 10 Oct 2008 23:37:06 +0200

not in favor.
-d. 

> Sent: Wednesday, October 01, 2008 4:04 PM
> To: [email-masked]
> Cc: Ross Callon

---

From: "ASIF, SAUD, ATTLABS" <[email-masked]>
Date: Thu, 9 Oct 2008 16:25:55 -0400

My Vote is :  NO
 
Unless this draft changes its structure to include the requirements and
recommendations of ISPs that has large real-life MVPN customer base and
experience I don't support this draft. We need to solve the multicast
scalability, inter-as, and interoperability issues by incorporating
recommendations from people who are already in trenches facing these on
a daily basis.

Saud Asif
[email-masked] 
v: 732-420-2062

-----Original Message-----

Regards
Marshall & Danny

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 10 Oct 2008 16:35:11 -0700

Define success Yakov?

It is not at all clear, and has never been proved to me this service  
is *profitable*. It may be generating revenue but the cost of running  
the service must be considered as well.

Dino

On Oct 10, 2008, at 9:08 AM, Yakov Rekhter wrote:

>> the

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Oct 2008 13:34:38 -0400

Dino,

When you say "this service", do you refer to the L3VPN unicast service,
the L3VPN multicast service, or an L3VPN service that includes both
unicast and multicast? Or all of the above?

                              Ron

Dino Farinacci wrote:
> Define success Yakov?
> 
> It is not at all clear, and has never been proved to me this service is
> *profitable*. It may be generating revenue but the cost of running the
> service must be considered as well.
> 
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Oct 2008 10:49:13 -0700

Yes, all of the above.

Dino

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Oct 2008 13:59:42 -0400

Hi Dino,

What leads you to believe that operators aren't making a profit on these
service?

                                Ron

---

From: "RAMSAROOP, JEEWAN P, ATTLABS" <[email-masked]>
Date: Mon, 13 Oct 2008 17:54:51 -0400

Yakov:

How does accepting of Morin's draft improve the profitability of the
current VPN/mVPN service?

Jeewan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yakov Rekhter
Sent: Friday, October 10, 2008 12:08 PM
To: RAMACHANDRAN, PRASANNA, ATTOPS
Cc: Ross Callon; [email-masked]
Subject: Re: Advancing the Protocol and Morin Drafts 

Prasanna,

> I vote NO.
> 
> Being in AT&T Advanced Tier support group and having supported the 
> MVPN core for the last 2 years, I can clearly say that we need a 
> solution such as PIM-BiDir that can reduce the number of multicast 
> states in the PEs to be able to scale the Groups X Sources x OILs
explosion for our

> in the US alone.

On the subject of "we definitely do not want to tweak", I'd like to
remind you that during the early days of 2547 VPNs some of its opponents
were saying that they are against 2547 VPNs because they do not want to
"tweak" such a crucial protocol as BGP to carry VPNv4 routes.

Today AT&T has "2 million VPNv4 routes in the US alone" all carried in
BGP, and a successful 2547 VPN service. None of this would be possible
if we would not tweak BGP.

Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 14 Oct 2008 11:13:15 +0200

> current VPN/mVPN service?

It is not exactly the question asked today, but if you understand why
standards are useful and that all solutions to a problem do not
necessarily have the same efficiency, then I think you'll find an answer
by yourself.

-Thomas

---

From: David Sinicrope <[email-masked]>
Date: Tue, 14 Oct 2008 05:24:18 -0700

Support.

On 10/1/08 10:04 AM, "Marshall Eubanks" <[email-masked]> wrote:

Regards
Marshall & Danny

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Tue, 14 Oct 2008 08:34:30 -0500

Support.

Mustapha. 
--------------
> > We expect that these two documents will be submitted more 
> or less as 
> > is (i.e., certainly with any new bug fixes or other necessary 
> > corrections and improvements, but without specific mandatory to 
> > implement feature description in those drafts).
> >

---

From: "Chase, Chris" <[email-masked]>
Date: Tue, 14 Oct 2008 14:50:35 -0500

WARNING: contains banned part

Subject: RE: Advancing the Protocol and Morin Drafts
From: "Chase, Chris" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>, "RAMACHANDRAN, PRASANNA (ATTOPS)" <[email-masked]>
Cc: "Marshall Eubanks" <[email-masked]>, <[email-masked]>, "Ross Callon" <[email-masked]>
Date: Tue, 14 Oct 2008 14:50:35 -0500

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Friday, October 10, 2008 11:08 AM
> To: RAMACHANDRAN, PRASANNA (ATTOPS)
> Cc: Marshall Eubanks; [email-masked]; Ross Callon
> MVPN
> > very large Enterprise customers.   We definitely do not want to
tweak
> a

I understand Prasanna's pain.  Indeed, we have over 2 million vpnv4
routes.  It is spread over many parallel RR planes that have to be added
to from time to time.  Not something to trifle with by doubling that
with equivalent sized state data that is far more dynamic. 

The multicast state in a private network can be much larger than the
number of WAN routes in that network.  For our IPTV backbone, there are
more multicast states than interior routes across the backbone.
Further, multicast state is application driven and not route topology
driven.  The state can be larger and much more dynamic than the route
space supporting such a network.

The recommendation is to throw the mVPN into separate, dedicated RR
planes to scale it and avoid "interfering" with the VPN route
distribution.  Ok.  But now we have an even larger RR set to manage,
while that RR plane is not even present with the PIM C-state model.  And
a separate RR plane does nothing on the endpoint PEs to separate the
interaction between multicast and route updates within a single BGP
process when there are large scale events (e.g., time to restart a PE
and get routes distributed is a big deal, so will the combination of PIM
state in the BGP process only slow down the communication of routes if
there is no prioritization of routes over C-states?).

And then there is the issue of convergence.  One of the big drawbacks to
existing unicast 2547 VPNs for enterprises has been slow convergence
CE-to-CE, which is on the order of seconds, while our PIM join latency
CE-to-CE observed in actual service is on the order of a hundred
milliseconds (that is US coast-to-coast).  While I would like to
consider moving our IPTV multicast backbone onto a multicast VPN for
various performance and resource advantages, I would not do it if the
C-state was propagated in BGP because of the slow resulting convergence.
It would not be close to meeting the requirements of our IPTV service.

Chris Chase

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Oct 2008 13:17:52 -0700

Hi Chris,

I am up to the challenge to demonstrate that in your current network .. 
only by proper configuration .. you can achieve no worse CE to CE 
connectivity restoration times for L3VPNs with using BGP and RRs to what 
you would achieve with any other protocol ie hundred milliseconds (that 
is US coast-to-coast). The same goes for atomic prefix changes.

What matters is the path redundancy and trigger. Crossing RRs would add 
at most 10s of ms delay to the picture.

Conclusion: I don't think that BGP so called "slow convergence" should 
be of any factor in this discussion thread.

Cheers,
R.

> Subject:
> RE: Advancing the Protocol and Morin Drafts
> From:
> To:
> "Yakov Rekhter" <[email-masked]>, "RAMACHANDRAN, PRASANNA (ATTOPS)" 
> <[email-masked]>
> 
> To:
> "Yakov Rekhter" <[email-masked]>, "RAMACHANDRAN, PRASANNA (ATTOPS)" 
> <[email-masked]>
> CC:
> "Marshall Eubanks" <[email-masked]>, <[email-masked]>, "Ross 
> Callon" <[email-masked]>
> 
> 
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 14 Oct 2008 16:36:33 -0400

Hi Robert,
we can achieve < 150 ms PIM Join latency (US cost-to-cost) without any
special configuration. This yet has to be demonstrated with any other
protocol in a loaded production environment...

Maria

>On Behalf Of Robert Raszuk
>Sent: Tuesday, October 14, 2008 4:18 PM
>To: CHASE, CHRIS, ATTLABS
>Cc: Ross Callon; Yakov Rekhter; [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Oct 2008 13:49:42 -0700

Hi Maria,

PIM Join latency would be in unicast world comparable to single prefix 
propagation by BGP.

Configuration I was talking about is not special .. but just correct :).

So in your network are you saying that single VPN prefix propagation in 
loaded production takes order of seconds from the moment one CE sends it 
to it's closest PE and the other CEs installs it in the RIB/FIB ? That's 
way too much I agree.

The only possible cause I could think of would be MRAI timer but most 
implementation I am familiar with have either this default to zero or it 
possible to be set as zero by single knob.

Perhaps what you are saying is that you may not have control over CEs 
and some BGP code there by default applies MRAI while PIM does not have 
such concept. That scenario indeed would be the cause of the delay for 
BGP propagation and not for PIM even if your core's BGP configuration 
would be already optimal.

Thx,
R.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Tue, 14 Oct 2008 17:17:49 -0400

Robert,

(btw, I don't think we have incorrect configurations in our network..).

I am not comparing PIM Join latency to unicast route propagation (and
the latter does not takes seconds..) I am just pointing out that
translating PIM J/Ps to BGP updates and propagating (and processing)
them via several (potentially very busy, because of data-driven nature
of PIM) RRs will increase Join latency beyond that of PIM. Wouldn't you
agree with this statement?
There is a danger that this increase in Join latency might not be
acceptable by some multicast applications. 

Maria

>From: Robert Raszuk [mailto:[email-masked]] 
>Sent: Tuesday, October 14, 2008 4:50 PM
>To: NAPIERALA, MARIA H, ATTLABS
>Cc: CHASE, CHRIS, ATTLABS; Ross Callon; Yakov Rekhter; [email-masked]

---

From: "Yuji KAMITE" <[email-masked]>
Date: Wed, 15 Oct 2008 12:04:25 +0900

Support.

Yuji

> Sent: Wednesday, October 01, 2008 11:04 PM
> To: [email-masked]
> Cc: Ross Callon

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 10:22:06 +0200

Hi Marshall & Danny,

I fully SUPPORT this approach.

Michel Laudet
Complex Solutions - Advanced IP Networking 
Senior Solution Architect - Large accounts

Tel. +33 4 92 96 65 23
[email-masked]
Orange Business Services
1041 Route des Dolines Sophia Antipolis 06560 Valbonne France
www.orange-business.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marshall Eubanks
Sent: mercredi 8 octobre 2008 10:59
To: [email-masked]
Cc: Ross Callon
Subject: Advancing the Protocol and Morin Drafts

Regards
Marshall & Danny

---

From: "Ahmed Omran" <[email-masked]>
Date: Sat, 18 Oct 2008 23:10:31 +0100

SUPPORT

Cheers,

/Ahmed 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marshall Eubanks
Sent: Wednesday, October 01, 2008 3:04 PM
To: [email-masked]
Cc: Ross Callon
Subject: Advancing the Protocol and Morin Drafts 

Regards
Marshall & Danny

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Oct 2008 20:03:40 +0100

Hi,

Support.

> have indicated that they are willing to do this.

I support your intention here, but not your choice of words.

Requirements drafts can state functions that must be provided by a solution.
Solutions drafts can state implementation requirements.

> draft-ietf-l3vpn-2547bis-mcast-bgp

I'm a bit cautious here. I think you will have to wait until you see the 
result of 2) before you know whether you are ready for last call or need 
further updates.

> description in those drafts).

For the reasons stated above, I think your expectations are not 
well-founded.

---

From: ycai <[email-masked]>
Date: Tue, 21 Oct 2008 21:07:48 -0700

Marshall,  Danny,

> 1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working

No.

> have indicated that they are willing to do this.

Given where the two solution drafts are,  I'm not sure we need another
requirement draft. 

> draft-ietf-l3vpn-2547bis-mcast-bgp

I think these two drafts can progress without 1) or 2) above.

Thanks.

-- 
Yiqun

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 22 Oct 2008 20:43:23 -0700 (PDT)

Hi Marshall,

Support.

rahul