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

[Robert Raszuk <[e-mail]>]

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.