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

[Keyur Patel <[e-mail]>]

Hi Stephane,

Comments inlined #Keyur.


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

> 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,
> 
> #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