Re: [Idr] Fwd: I-D Action:draft-keyur-bgp-enhanced-route-refresh-00.txt

[Martin Djernaes <[e-mail]>]

Hi Enke, Keyur et al,

The concept of a new route fresh message with clear demarcation markers is a useful concept. 

I do have a few things I think we should consider changing.

In section 3 you write:

   In the case of continuous churn of the BGP table, an implementation
   SHALL impose an upper bound on how long it would take to complete the
   route refresh.  Once the upper bound is reached, the implementation
   SHOULD suspend the processing of the received UPDATE messages briefly
   until the route refresh to the peer is complete.

I think adding any information into an official document stating that it is ok to suspend processing of incoming updates for even a small bit of time. This gives an uncontrollable delay in the propagation of updates and won't be good for the networks.

I think it would be beneficial to clarify how "begin" and "end" marker are send and processed is required. Especially if subsequent refresh requests, received in the time period from the first "begin" marker is send and until the corresponding "end" marker is send. What is the proper handling.

Also, along the same line, I think it should be said that the side sending a "begin" marker may end up dropping the "end" marker (or delaying it so long that it becomes mood). How this is handled on the requesting side is probably left up to the implementation to handle.

In section 2.2 you write:

   The "Reserved" field of the ROUTE-REFRESH message specified in
   [RFC2918] is re-defined as the "Message Subtype" with the following
   values:


          0 - Normal route refresh request [RFC2918], or ORF [RFC5291]
          1 - Demarcation of the beginning of a route refresh
          2 - Demarcation of the ending of a route refresh

I would suggest that instead of overloading the empty octet that instead an extended route refresh message is expanded with a TLV field where either a "type start" TLV or a "type end" TLV  can be placed. This, imho, gives more flexibility in the long run.

Martin





From: [e-mail] [mailto:[e-mail]] On Behalf Of Enke Chen
Sent: 06 October 2010 20:43
To: [e-mail]
Cc: Keyur Patel
Subject: [Idr] Fwd: I-D Action:draft-keyur-bgp-enhanced-route-refresh-00.txt

FYI.  Will appreciate comments.

-- Enke

-------- Original Message -------- 
Subject: 
I-D Action:draft-keyur-bgp-enhanced-route-refresh-00.txt
Date: 
Tue, 5 Oct 2010 22:00:02 -0700 (PDT)
From: 
[e-mail]
Reply-To: 
[e-mail]
To: 
[e-mail]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Enhanced Route Refresh Capability for BGP-4
	Author(s)       : K. Patel, et al.
	Filename        : draft-keyur-bgp-enhanced-route-refresh-00.txt
	Pages           : 6
	Date            : 2010-10-05

In this document we enhance the existing BGP route refresh mechanisms
to provide for the demarcation of the beginning and the ending of a
route refresh.  The enhancement can be used to facilitate on-line,
non-disruptive consistency validations of BGP routing updates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-keyur-bgp-enhanced-route-refresh-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.