Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt

[Jeffrey Haas <[e-mail]>]

On Thu, Feb 06, 2014 at 10:39:27AM -0500, Susan Hares wrote:
> Jeff: 
> 
> Please provide more details on your opinion on this information to the list:

Sure. :-)

> "Personally, I think it'd be wise to not process the enhanced RR procedures
> until GR is complete but I think that can be an implementation decision."
> (The justification is that there's a *lot* of work going on while processing
> GR and it's more valuable to get RIBs in some initial state of
> synchronization rather than worry about trying to fill in holes that might
> be present in the midst of it.)

When a router that is assisting with a graceful restart, it has to do
several expensive things:
- Mark all routes received from that peer stale.
- Receive all routes again from that peer.
- Upon EoR (per family), sweep all stale routes not otherwise refreshed.

In a non-multisession peering environment, you have one TCP socket between
you and the restarting peer.  Presuming more than one AFI/SAFI negotiated
(lets say IPv4 unicast and L3VPN), even if you've finished refreshing IPv4
unicast and could service a enhanced route refresh for that family, you're
still doing a lot of work trying to shove routes down the socket for L3VPN.

Even if you presume you ignore CPU or route-queueing efficiencies for an
implementation (let's say that some IPv4 Unicast is queued ahead of other
stuff), to service the refresh for those important routes you'd still push
off initial convergence of L3VPN.  Whether this is wise is clearly an
implementation choice.

Implementations are free to interleave queued routes as they wish and there
are competing motivations as to why they'd want to servicing things in a
given way.  But in abstract, delaying initial convergence seems unwise.

An implementation would be free to queue the work requested for a enhanced
route refresh and not interrupt GR resync.  That requires no changes to the
spec.

The spec could offer the opinion that you probably should do this, rather
than allowing a refresh to interrupt GR procedures (which impact timers) by
reinserting routes that have been sent at least once into the queue.  But
that gets pretty deep into implementation.  Trying to be normative here (RFC
2119 language) seems unwise since it simply puts an implementor into a
pedantic vice useful only to make test tool vendors happy. 

-- Jeff