Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt

["Rajiv Asati (rajiva)" <[e-mail]>]

Samita,

No additional latency expected. Thanks.

Cheers,
Rajiv


> -----Original Message-----
> From: Robert Raszuk (raszuk)
> Sent: Wednesday, August 17, 2011 6:44 PM
> To: Samita Chakrabarti
> Cc: Rajiv Asati (rajiva); [e-mail]
> Subject: Re: [Idr] I-D Action:
draft-ietf-idr-bgp-bestpath-selection-criteria-
> 04.txt
> 
> Hi Samita,
> 
> Allow me to make an observation that today BGP already validates
> reachability to next hops, before considering path with such next hop
to
> be valid and to be eligible for best path selection.
> 
> In the light of the above Rajiv's proposal does not introduce any
> additional delay nor does it cause any impact on "bgp convergence".
> 
> The only place which changes for some applications of BGP is the place
> where you validate such next hop liveness/reachabilty. And as this is
> very implementation dependent I think we should not discuss those
> aspects on this mailing list.
> 
> Best regards,
> R.
> 
> > Hi Rajiv,
> >
> > This is a good work clarifying the path-availability check in BGP
> > path selection. Is this document supposed to update RFC 4271 section
> > 9.1.2 in general? I wonder, if you have any data or thoughts on
> > whether the additonal check at the data-plane level will add any
> > latency in BGP path selection process and thus have any effect on
> > convergence? A short paragraph on the impact on timing might be
> > useful for implementors as it seems running BFD or any other
> > mechanism to keep an up-to-date information of path-availability at
> > the data-plane will avoid any delay in the path selection process.
> >
> > -Samita