Subject: [Idr] draft-keyur-bgp-enhanced-route-refresh-00.xt

From: <[email-masked]>
Date: Fri, 12 Nov 2010 12:33:00 +0100

Keyur,
 
I have a major question regarding your proposal.
My question is concerning the processing in parallel of transient
updates and route-refresh RIB out advertisement.
Consider a BGP speaker that is receiving transient updates from some
peers and that will serve a route-refresh to another peer.
It's very impacting to wait for the route-refresh service to be finished
before sending transient updates to the peer receiving the route-refresh
as it may impact customer convergence time if the RIB-OUT is huge
(hundreds of thousands of prefixes). For example, a new update
advertising a customer backup route to be used will be delayed to that
peer.
Can you confirm that in your proposal, the BGP speaker serving the
route-refresh will wait to for RIB-out advertisement to be finished,
then send demarcation end, finally will serve transient updates ?
 
Thanks
 
Stephane

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Keyur Patel <[email-masked]>
Date: Fri, 12 Nov 2010 14:25:11 -0700

Hi Stephane,

Comments inlined #Keyur.

On 11/12/10 4:33 AM, "[email-masked]"
<[email-masked]> wrote:

> My question is concerning the processing in parallel of transient updates and
> route-refresh RIB out advertisement.
> Consider a BGP speaker that is receiving transient updates from some peers and
> that will serve a route-refresh to another peer.
> before sending transient updates to the peer receiving the route-refresh as it
> may impact customer convergence time if the RIB-OUT is huge (hundreds of
> thousands of prefixes). For example, a new update advertising a customer
> backup route to be used will be delayed to that peer.
> route-refresh will wait to for RIB-out advertisement to be finished, then send
> demarcation end,
> 
> #Keyur: Yes. Route Refresh EOR should be announced after table announcement is
> done (Refresh + Incremental updates).
> 
>  finally will serve transient updates ?
> 
> #Keyur They should be able to serve transient updates unless the churn is
> abnormal such that the complete table is not announced for hours in which case
> one could:
> 1. Delay the announcement of Refresh End of Rib.
> 2. Have a timer to have an upper-bound on a generation of Refresh End of Rib.
> 3. Throttle inbound processing.
> 
> Best Regards,
> Keyur