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

From: "Tomotaki, Luis M." <[email-masked]>
Date: Thu, 17 Nov 2011 19:43:04 -0500

Yes/Support

My comments coming from a large service provider regarding the adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document are the following:

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

Luis Tomotaki
Verizon PIP
Senior Engineer - Network Planning

On Nov 16, 2011, at 5:04 PM, "John Scudder" <jgs at juniper.net> wrote:

> Folks,
>
> We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.
>
> Thanks,
>
> --John
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Nov 2011 02:07:00 +0100

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.

---

From: "Tomotaki, Luis M." <[email-masked]>
Date: Mon, 21 Nov 2011 12:23:40 -0500

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:[email-masked]] 
Sent: Thursday, November 17, 2011 7:07 PM
To: Tomotaki, Luis M.
Cc: [email-masked]
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Luis,

> to multiple reasons such as end-of-life scenarios or costly hardware 

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Nov 2011 19:03:37 +0100

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:[email-masked]] Sent: Thursday, November 17, 2011 7:07 PM
>  To: Tomotaki, Luis M. Cc: [email-masked] 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.
>
>
>

---

From: <[email-masked]>
Date: Tue, 22 Nov 2011 10:48:21 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de Robert Raszuk
Envoyé : lundi 21 novembre 2011 19:04
À : Tomotaki, Luis M.
Cc : [email-masked]
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 ...

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

> 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.
>
> roles.  P and RR routers are considered core infrastructure which only 
> a few selected groups have access to for security issues.
>
> Luis

>  To: Tomotaki, Luis M. Cc: [email-masked] Subject: Re: [Idr] Adoption of 
> draft-l3vpn-legacy-rtc-00 as IDR WG document?
>
> Luis,
>
> 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.
>
> 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.
>
>> 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.
>

[email-masked]

_________________________________________________________________________________________________________________________

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.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Nov 2011 11:07:41 +0100

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.

---

From: <[email-masked]>
Date: Tue, 22 Nov 2011 11:33:20 +0100

>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:[email-masked]] 
Envoyé : mardi 22 novembre 2011 11:08
À : LITKOWSKI Stephane DTF/DERX
Cc : Tomotaki, Luis M.; [email-masked]
Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Hi Stephane,

Few comments ...

> 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 

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.

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

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.