Re: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension
Enke Chen <enkechen@cisco.com> Tue, 09 August 2011 19:13 UTC
Return-Path: <enkechen@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC911E80EF for <idr@ietfa.amsl.com>; Tue, 9 Aug 2011 12:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+i5hVIGBLWp for <idr@ietfa.amsl.com>; Tue, 9 Aug 2011 12:13:16 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1D79911E80E0 for <idr@ietf.org>; Tue, 9 Aug 2011 12:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=3682; q=dns/txt; s=iport; t=1312917226; x=1314126826; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AbcXCOUwWFFnBOHF36VMKdjHyc93QL3YB4hGWa/Qks4=; b=LPvotYS8wrno6h9syGoW1kdwHg019YcOndQB9VsMUZo4k0WyydT1cOSJ Z6QU8FupapcChxUE/xifqpWmUZoGIygDQ+qGUrmRsZgcfMmu9O2cvW4Cl rrCXDeldCVDdGXZV1PUfcbXd3Jjf8QevugEMlnixhYWZb0X3W4OSZS+od E=;
X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="11436645"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 09 Aug 2011 19:13:45 +0000
Received: from dhcp-171-71-139-199.cisco.com (dhcp-171-71-139-199.cisco.com [171.71.139.199]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79JDipn024009; Tue, 9 Aug 2011 19:13:44 GMT
Message-ID: <4E4186ED.4070001@cisco.com>
Date: Tue, 09 Aug 2011 12:13:49 -0700
From: Enke Chen <enkechen@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Jie Dong <dongjie_dj@huawei.com>
References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr@ietf.org
Subject: Re: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2011 19:13:16 -0000
Hi, Jie: IMO RFC 4724 is sufficiently clear about the use of EOR, and also specifies the use of the GR capability without AFI/SAFI for indicating the EOR support without performing GR. Please see excerpt from RFC 4724 below. Granted there are some inconsistencies in RFC 4724. A re-spin of RFC 4724 seems in order. Actually a re-spin is already on the IDR WG status report presented at the IETF-81. There is no need for a new capability, though, as there is no backward compatibility issue for sending and receiving the GR capability (with or without AFI/SAFI). In short, I do not see a need for draft-dong-idr-end-of-rib-use-extension. -- Enke ------------------------------------------------------- RFC 4724 (GR) 2. Marker for End-of-RIB ..... 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. In addition, it would be beneficial for routing convergence if a BGP speaker can indicate to its peer up-front that it will generate the End-of-RIB marker, regardless of its ability to preserve its forwarding state during BGP restart. This can be accomplished using the Graceful Restart Capability described in the next section. 4. Operation A BGP speaker MAY advertise the Graceful Restart Capability for an address family to its peer if it has the ability to preserve its forwarding state for the address family when BGP restarts. In addition, even if the speaker does not have the ability to preserve its forwarding state for any address family during BGP restart, it is still recommended that the speaker advertise the Graceful Restart Capability to its peer (as mentioned before this is done by not including any<AFI, SAFI> in the advertised capability). There are two reasons for doing this. The first is to indicate its intention of generating the End-of-RIB marker upon the completion of its initial routing updates, as doing this would be useful for routing convergence in general. The second is to indicate its support for a peer which wishes to perform a graceful restart. ----------------------------------------------------------------------- On 8/9/11 12:46 AM, Jie Dong wrote: > Dear all, > > Internet-Draft draft-dong-idr-end-of-rib-use-extension was submitted before Quebec IETF. The url is: http://tools.ietf.org/html/draft-dong-idr-end-of-rib-use-extension-00 > > Since BGP End-of-Rib (EoR) would be useful for general BGP convergence, this draft proposes to define a EoR capability to negotiate the use of EoR between BGP peers. This makes EoR an independent feature and could be used without supporting or enabling GR capability. As according to BGP GR (RFC4724), BGP peers can only negotiate the combination of EoR and GR capability. > > We've received some offline comments, one of which suggested an alternative solution: respin GR specification and cover this scenario: negotiate only EoR, no GR. > > Thus we would have two alternatives here: > either we define a simple and dedicated capability for EoR, > or we respin BGP GR with some further capability negotiation functionality to cover this case. > > We would like to solicit feedbacks and opinions on this draft and also the alternatives. > > Many thanks, > Jie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- [Idr] Solicit feedbacks on draft-dong-idr-end-of-… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Enke Chen
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Pradosh Mohapatra
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jakob Heitz
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Robert Raszuk
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Robert Raszuk
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Enke Chen
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Robert Raszuk
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Cayle Spandon
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jakob Heitz
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Cayle Spandon
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Robert Raszuk
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jakob Heitz
- Re: [Idr] Solicit feedbacks on draft-dong-idr-end… Jie Dong