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

Hi Enke:
Thanks for your comments and please see my further replies inline with [Qing1].

Best Regards!
 Qing

----- 原始邮件 ----- 
发件人: "Enke Chen" <enkechen@cisco.com>
收件人: "Qing Zeng" <zengqing@huawei.com>
抄送: <idr@ietf.org>; "Keyur Patel" <keyupate@cisco.com>; "Enke Chen" <enkechen@cisco.com>
发送时间: 2010年10月11日 16:06
主题: Re: [Idr] Fwd: I-D Action:draft-keyur-bgp-enhanced-route-refresh-00.txt

> Hi, Qing:
> 
> Please see my comments inline.
> 
> On 10/9/10 1:03 AM, Qing Zeng wrote:
>> Hi All:
>>
>> I have some questions:
>> 1. This is the method to checking for possible missing withdraws between BGP speakers,
>> what's the most likely to occur application scenario of  possible missing withdraws?
> 
> It provides a way to detect inconsistencies and to force consistency 
> over a established session.  Dealing with missing withdraws (caused by 
> software bugs) is one of the applications.  Yes, there have been a few 
> occurrences in the past.

[Qing1]
OK, I think it is a valuable requirements for maintenance.
But,if it's caused by software bugs or some other reason, there are also possible missing updates.
For the possible missing updates, using route refresh will recovery the failure directly without detecting.
So is that only with "force consistency" more appropriate than with "detect inconsistencies"?
As an aside,
" All the routes that were not re-advertised in the route refresh MUST be
purged, and SHOULD be logged for further analysis." 
How to further analysis? Manual deleting or on-line?

> 
>>
>>
>> 2. Why don't consider that using End-of-RIB(EOR) or extension-UPDATE message to
>> mark the beginning and the ending of a route refresh? After all, the EOR is more often
>> used to mark completion of the whole Rib update for routing convergence.
>>    
> 
> The End-of-Rib as currently defined and used for GR is not adequate for 
> the current purpose as:
[Qing1]
   The End-of-Rib should not be used only for GR.
   From RFC4724
   "   Although the End-of-RIB marker is specified for the purpose of BGP
   graceful restart, it is noted that the generation of such a marker
   upon completion of the initial update would be useful for routing
   convergence in general, and thus the practice is recommended."
> 
>      - there is no beginning.
[Qing1]
      Agree. 
      But could we consider extending the one special attribute for UPDATE message? 
      at the same time, some routes will be packing with this flag in one UPDATE.

>      - in the case of continuous churn, we do not want the End-of-Rib 
> to be delayed like the end-of-refresh.
[Qing1]
      How to understand the "delayed"?  
      In the case of continuous churn, is there difference between the End-of-Rib and the end-of-refresh?

> 
> Also, extending the route refresh seems more logical than extending the 
> UPDATE message in this case.
> 
>> 3. How to operate when BGP speaker is sending Adj-Rib-Out due to refresh with route oscillation?
>> For correctly identifing the beginning and the ending of a route refresh , should route selection be hold on the speaker?
>>    
> 
> In case of continuous churn,  an implementation should support a locally 
> configurable upper bound for generating the end-of-refresh.  One way is 
> to suspend the inbound processing briefly.  That should be optional 
> (will revise in the next version).   Another way is to just generate the 
> end-of-refresh.   There is little practical difference between the 
> approaches for a route that keeps churning.
> 
[Qing1]
OK,I see. And if I had to choose one between these two, I choose the former.
I think the latter will make the results of detecting inconsistencies more inaccurate.
In my understanding, The goal of suspending the inbound processing briefly 
after the upper bound is reached is to speed up refresh process, 
but why not consider suspending the inbound processing when begining of the refresh?   

> Thanks.   -- Enke
> 
>> Best Regards!
>> Qing
>>
>>
>>
>>
>> ----- 原始邮件 -----
>> 发件人: "Enke Chen"<enkechen@cisco.com>
>> 收件人:<idr@ietf.org>
>> 抄送: "Keyur Patel"<keyupate@cisco.com>
>> 发送时间: 2010年10月7日 2:42
>> 主题: [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: Internet-Drafts@ietf.org
>>> Reply-To: internet-drafts@ietf.org
>>> To: i-d-announce@ietf.org
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>      
>>
>> --------------------------------------------------------------------------------
>>
>>
>>    
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>      
>> >
>