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

[<[e-mail]>]

 Robert,

>How does support of legacy RTC on the PE helps to improve the overall experience of your customers ?

Here is my personal feedback on that :

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.

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

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. 

Best Regards,

Stephane


-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Robert Raszuk
Envoyé : lundi 21 novembre 2011 19:04
À : Tomotaki, Luis M.
Cc : [e-mail]
Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Hello Luis,

Many thx for your answer. One follow-up question as I am really keen to know ...

> As a carrier, we continue to work towards improving the overall 
> experience of our customers in these legacy PEs.

How does support of legacy RTC on the PE helps to improve the overall experience of your customers ?

If anything I would assume this helps your core infrastructure, but customers should never see any change in experience with or without legacy RTC enabled.

Best regards,
R.


> Robert, Thanks for the feedback.  I agree with your statement that 
> more than likely, many carriers that are supporting "legacy" PEs will 
> not be able to run "new" services on these routers.  However, for most 
> carriers, provisioning of new circuits/VRFs on these legacy PEs 
> continue to take place.  As a carrier, we continue to work towards 
> improving the overall experience of our customers in these legacy PEs.
>
> As it is the case in many carrier networks, automated provisioning 
> tools only have visibility to PEs and not to routers on a P or RR 
> roles.  P and RR routers are considered core infrastructure which only 
> a few selected groups have access to for security issues.
>
> Luis

> -----Original Message----- From: Robert Raszuk 
> [mailto:[e-mail]] Sent: Thursday, November 17, 2011 7:07 PM
>  To: Tomotaki, Luis M. Cc: [e-mail] Subject: Re: [Idr] Adoption of 
> draft-l3vpn-legacy-rtc-00 as IDR WG document?
>
> Luis,
>
>> - We need support for the legacy PE draft since a large number of PEs 
>> in many service provider networks will never be able to support RFC 
>> 4684 since the code upgrade of these legacy PEs is not an option due 
>> to multiple reasons such as end-of-life scenarios or costly hardware 
>> upgrades.
>
> Putting legacy RTC topic aside which is at the end of the day just an 
> optimization it seems that your legacy PEs will also never be able to 
> be upgraded with any other new functionality you or IETF may be coming 
> with.
>
> Therefor you will not be able to run any new services on those PEs.
> And this is all because vendor XYZ decided to abandon the software 
> development on a branch your and "many service providers" are using in 
> production.
>
> That seems to me like much bigger issue that effectively this is your 
> PE vendor to get to decide what services you are to offer on your PEs.
>
>> - As a representative of a large service provider, our comment is 
>> that our provisioning systems are highly automated and should easily 
>> be able to make the provisioning changes needed to specify RT 
>> membership information on the legacy PEs during the VRF configuration 
>> with no additional risk to our customer traffic. - The VPNV4/VPNV6 
>> RRs in our network are considered core infrastructure devices that 
>> should NOT be exposed to daily provisioning activity that the manual 
>> addition of filters to the core RR would require.
>
> If the provisioning is "highly automated" I fail to see why 
> provisioning in "core infrastructure" would have to be a manual 
> process.
>
> Best, R.
>
>
>

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.