Subject: RE: Advancing the Protocol and Morin Drafts,

From: [email-masked]
Date: Thu, 9 Oct 2008 13:02:02 +0200

>From: "RAMACHANDRAN, PRASANNA, ATTOPS" <prasanna at att.com>
>
>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

Hold up, wait a minute.

How does PIM-BiDir fix any of this? In mVPN, the number of PIM 
adjacencies does not scale in any large network. How is this better when 
each individual PE router must establish a PIM adjacency to every OTHER 
single PE router per VPN in a network?

PIM constantly squawking away every 60 seconds on each of those adjacencies 
is nothing to write home about. Why have that when you can solve this with 
a BGP session transported in TCP?

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

First, I think AT&T is contradicting itself. Just a few months ago a draft was put 
forward to allow for a router to accept a BGP update with its own originator or 
next-hop. 

This behavior, which is a very important part of freaking loop prevention was 
now becoming optional. I'd say thats a pretty big fundamental tweak in comparison 
to what is going on here.

Secondly, BGP is the right place to address scale of this nature. Just like 
you mentioned, BGP handles millions of routes today. Though I wonder, is that 
all on a single route reflector? My guess is, those 2 million VPNv4 routes are 
spread across multiple routers. The same design could apply here where you could 
have separate routers just handling mVPN information.

>"This email and any files transmitted with it are AT&T property, are

You probably want to turn that off when sending to a mailing list.

As for my vote, I support it just like I support Obama.

Calvin "Snoop" Broadus Jr.
     =Still G.R.E.=

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 9 Oct 2008 17:41:09 +0200

> How does PIM-BiDir fix any of this? In mVPN, the number of PIM

You may want to read up on the proposals AT&T has been submitting to  
IETF before drawing conclusions.

> single PE router per VPN in a network?

Please check out the MS-PMSI proposal.

> have separate routers just handling mVPN information.

PIM does not need route reflectors to make the protocol scale,...

Thx,

Ice.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 09 Oct 2008 10:15:36 -0700

Hi Ice,

> PIM does not need route reflectors to make the protocol scale,...

BGP does not need route reflectors to scale nor to operate.

Reflectors have came to BGP in order to:

* reduce IBGP configuration overhead

-> Can be address with IBGP auto-discovery proposal I have and which 
some version of that have already been presented to IDR

* reduce number of paths distributed to BGP speakers

-> Apparently this is causing more pain then gain (fast connectivity 
restoration, oscillations, multipath etc ...). There are proposals on 
the table already to distribute all/some paths to all clients. Example 
draft-walton with it's add-path

* reduce number of TCP sessions & peers per BGP speaker

-> That with moder CPUs is no longer the concern.

Cheers,
R.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 9 Oct 2008 13:26:43 -0400

>-> That with moder CPUs is no longer the concern.

Exactly. Look at PIM Over Reliable Transport (PORT). 

Maria

---

From: Renwei Li <[email-masked]>
Date: Thu, 09 Oct 2008 11:18:02 -0700

> BGP does not need route reflectors to scale nor to operate.

It doesn't need RR to operate, but it does need RR to scale in multiple
aspects such as scaling in config, TCP sessions, etc. Moreover, RR sometimes
can create routing loops if your MEDs are not configured well!

Cheers,

Renwei

---

From: "Serbest, Yetik" <[email-masked]>
Date: Tue, 14 Oct 2008 10:05:59 -0500

I agree with Maria, there is already work going on to improve PIM. I
believe we should solve the problem at its root.

Hence, my vote is no to the current proposal.

Thanks,
yetik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of NAPIERALA, MARIA H (ATTLABS)
Sent: Thursday, October 09, 2008 12:27 PM
To: [email-masked]; IJsbrand Wijnands
Cc: [email-masked]
Subject: RE: Advancing the Protocol and Morin Drafts,

Maria

---

From: "Serbest, Yetik" <[email-masked]>
Date: Mon, 13 Oct 2008 16:33:45 -0500

Thanks,
yetik

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

Maria