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

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Jeff,

As part of rev 6, we added the following to Section 4:

<snip>
The following procedures are specified in order to simplify the
   interaction with the BGP Graceful Restart [RFC4724].  For a BGP
   speaker that supports the BGP Graceful Restart, it MUST NOT send a
   BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the
   AFI/SAFI to the neighbor.  A BGP speaker that has received the
   Graceful Restart Capability from its neighbor, MUST ignore any BoRRs
   for an AFI/SAFI from the neighbor before the speaker receives the EoR
   for the given AFI/SAFI from the neighbor.  The BGP speaker SHOULD log
   an error of the condition for further analysis.

<snip>

Regards,
Keyur


On 2/6/14 8:10 AM, "Jeffrey Haas" <[e-mail]> wrote:

>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
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr