Re: Advancing the Protocol and Morin Drafts

[Robert Raszuk <[e-mail]>]

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:
> "Chase, Chris" <[e-mail]>
> Date:
> Tue, 14 Oct 2008 14:50:35 -0500
> To:
> "Yakov Rekhter" <[e-mail]>, "RAMACHANDRAN, PRASANNA (ATTOPS)" 
> <[e-mail]>
> 
> To:
> "Yakov Rekhter" <[e-mail]>, "RAMACHANDRAN, PRASANNA (ATTOPS)" 
> <[e-mail]>
> CC:
> "Marshall Eubanks" <[e-mail]>, <[e-mail]>, "Ross 
> Callon" <[e-mail]>
> 
> 
> 
>> -----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
> 
> 
> 
>