RE: Advancing the Protocol and Morin Drafts

["Chase, Chris" <[e-mail]>]

WARNING: contains banned part

--- Begin Message ---

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, October 10, 2008 11:08 AM
> To: RAMACHANDRAN, PRASANNA (ATTOPS)
> Cc: Marshall Eubanks; [e-mail]; Ross Callon
> 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
> > 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.
> 
> 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.


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

--- End Message ---