RE: Advancing the Protocol and Morin Drafts

["NAPIERALA, MARIA H, ATTLABS" <[e-mail]>]

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

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Robert Raszuk
>Sent: Tuesday, October 14, 2008 4:18 PM
>To: CHASE, CHRIS, ATTLABS
>Cc: Ross Callon; Yakov Rekhter; [e-mail]
>Subject: Re: Advancing the Protocol and Morin Drafts
>
>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
>> 
>> 
>> 
>> 
>
>