Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

[<[e-mail]>]

>Let me point out that RT-Constrain only triggers reception of what is needed by the PE when new RT is added or deleted. If legacy RTC still requires to >send route refresh from the PE that means that such PE each time RT change occurs will be still bombarded with all VPNv4/v6 routes as specified in 
>route-target filter list for a given entire PE.
>Agreed that this may be less then overall amount of VPNv4 routes stored on the RR however this is much much more then needed by PE by any given atomic RT >change.

[SLI] you are right, it's not as optimal as RTC is able to do, but it's less than the entire RIB out (between 30% and 60% of the entire RIB-out for us, depending of the PE config/load)

 >assume this "time difference" is due to a fact that PE will be receiving only subset of all VPN routes in the network ... but still much more then would >be needed for newly modified customer VRF. But again this is the same "gain" as above.

[SLI] Yes


>If as you say there is no NSR/GR on the RR I do not know how you are going to accomplish that benefit. AFAIK there is no mechanism on _existing_ PEs to 
>mandate that routes from some VRFs are send before routes from other VRFs. So effectively your special VRF's filters may be send last and RR will not 
>wait after session is establish, but will start sending "thousands or million VPN routes" towards restarting PE.

[SLI] You are right, I missed that point, there is no VRF priorisation when sending routes, so legacy RTC has no effect at session startup (while RTC is doing this well, as you mentionned).

Best Regards,

Stephane


-----Message d'origine-----
De : Robert Raszuk [mailto:[e-mail]] 
Envoyé : mardi 22 novembre 2011 11:08
À : LITKOWSKI Stephane DTF/DERX
Cc : Tomotaki, Luis M.; [e-mail]
Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Hi Stephane,

Few comments ...

> In some scenarios (clearing depending of vendor RR BGP code), it 
> should optimize BGP update propagation time (and so end to end 
> convergence for customers) for transient update while RR is serving a 
> route-refresh to the PE. Route-refresh will take less time to be 
> served from RR to PE as there is less prefixes to send, so transient 
> update that must be served while the route-refresh is running, will be 
> served faster. But as I explained , it clearly depends on how the 
> vendor BGP code is dealing with this scenarios (serving transient 
> updates while RIB-out is sent due to route-refresh), but as far as I 
> know (due to personal experience in this area ;) ) there is some code 
> that are causing issues ... But in this case, legacy RTC is a 
> workaround for BGP update propagation time, not a solution, the 
> solution is clearly to optimize RR code behavior.

Let me point out that RT-Constrain only triggers reception of what is needed by the PE when new RT is added or deleted. If legacy RTC still requires to send route refresh from the PE that means that such PE each time RT change occurs will be still bombarded with all VPNv4/v6 routes as specified in route-target filter list for a given entire PE.

Agreed that this may be less then overall amount of VPNv4 routes stored on the RR however this is much much more then needed by PE by any given atomic RT change.

> Another scenario is that , when adding a new RT in the customer VRF, 
> it will take less time to import routes into the customer VRF. It's 
> important especially during some customer migrations (some customer 
> support center already reported to us some issues about time to import 
> routes into VRFs).

I assume this "time difference" is due to a fact that PE will be receiving only subset of all VPN routes in the network ... but still much more then would be needed for newly modified customer VRF. But again this is the same "gain" as above.


> Last scenario, is that when PE is crashing (considering legacy PE with 
> no NSR or GR), it's taking time to receive routes from the RR, and 
> during this time, some customer (not dual homed) are isolated.
>
> Globally, when there is thousands or million VPN routes in the RR 
> RIB-out (especially if RR and PE are far, so there could be high RTDs 
> and potential few packet loss if there are low speed links on the 
> path), it's taking minutes to propagate them to PE.

If as you say there is no NSR/GR on the RR I do not know how you are going to accomplish that benefit. AFAIK there is no mechanism on _existing_ PEs to mandate that routes from some VRFs are send before routes from other VRFs. So effectively your special VRF's filters may be send last and RR will not wait after session is establish, but will start sending "thousands or million VPN routes" towards restarting PE.

That is why we have specifically added a capability to RFC4684 to protect from this case by waiting for RTC to send filters first once RTC capability has been negotiated.

Regards,
R.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.