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

support

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel (keyupate)
Sent: Thursday, February 06, 2014 9:51 AM
To: Jeffrey Haas; Susan Hares
Cc: idr@ietf.org
Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt

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" <jhaas@pfrc.org> 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
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr