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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Feb 2014 10:25:55 -0500

On Thu, Jan 30, 2014 at 01:23:07PM -0500, Susan Hares wrote:
> IDR WG:
> 
> We will have a 1 week WG LC on this version of the
> draft-ietf-idr-bgp-enhanced-route-refresh-06.txt 
> 
> Please comment.  It would help if you would indicate: support/no-support in
> your discussion. 

I continue to support the draft.  I think the clarifications for covering
end-of-rib procedures (regardless of whether GR is being used or not) are
valuable.

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.)

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Feb 2014 10:39:27 -0500

Jeff: 

Please provide more details on your opinion on this information to the list:

"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.)

Sue Hares

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 10:26 AM
To: Susan Hares
Cc: 'Keyur Patel (keyupate)'; [email-masked]
Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt

On Thu, Jan 30, 2014 at 01:23:07PM -0500, Susan Hares wrote:
> Please comment.  It would help if you would indicate: 
> support/no-support in your discussion.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Feb 2014 11:10:54 -0500

> Please provide more details on your opinion on this information to the list:

Sure. :-)

> 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

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 6 Feb 2014 17:51:10 +0000

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" <[email-masked]> wrote:

>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 6 Feb 2014 18:06:18 +0000

support

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

Hi Jeff,

<snip>

<snip>

Regards,
Keyur

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

>> 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.)
>
>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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Feb 2014 15:12:54 -0500

Keyur,

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

It was this text that brought the case to mind.

>    an error of the condition for further analysis.

The distinction is that I think we shouldn't ask for enhanced RRs (or
process them if restarting) until restart procedures are concluded.  The
above text makes it ok to request one for a given afi/safi once that
afi/safi has sent eor.

-- Jeff

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 6 Feb 2014 20:23:49 +0000

>above text makes it ok to request one for a given afi/safi once that

Right. I don't know if we can control the "ask". But the text above
ensures (like you said) that the refresh reply will be delayed till EOR is
serviced.

Regards,
Keyur

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Feb 2014 15:31:02 -0500

> ensures (like you said) that the refresh reply will be delayed till EOR is

Just to close this loop for Sue, as I said in my original reply, the
existing text is sufficient.  If we were going to add text, it'd basically
say "do not process received refresh requests until GR procedures are
complete".

I'm not going to press heavily for such a thing in the spec.  But it's
likely what I'd suggest we put in our implementation.

-- Jeff