Re: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension
Jakob Heitz <jakob.heitz@ericsson.com> Wed, 10 August 2011 02:16 UTC
Return-Path: <jakob.heitz@ericsson.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 3629C21F86C7 for <idr@ietfa.amsl.com>; Tue, 9 Aug 2011 19:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.657
X-Spam-Level:
X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
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 yvSv3xFyBvuc for <idr@ietfa.amsl.com>; Tue, 9 Aug 2011 19:16:13 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8121F86C3 for <idr@ietf.org>; Tue, 9 Aug 2011 19:16:13 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p7A2GXj5032227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Aug 2011 21:16:33 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 9 Aug 2011 22:16:32 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Jie Dong <jie.dong@huawei.com>, Enke Chen <enkechen@cisco.com>
Date: Tue, 09 Aug 2011 22:16:31 -0400
Thread-Topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension
Thread-Index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAHOYeAAB0gGsAAAibNIA==
Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A1EBB40B@EUSAACMS0701.eamcs.ericsson.se>
References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <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: Wed, 10 Aug 2011 02:16:14 -0000
Jie, When a BGP speaker advertises the GR capability without including any <AFI,SAFI> it is saying to the peer: I will send an EOR when my initial update is complete and I MAY retain your routes when you restart. When a BGP speaker advertises your extension, it is saying to the peer: I will send an EOR when my initial update is complete and I WILL NOT retain your routes when you restart. I think. Is that correct? Can you state a use case where the difference matters? -- Jakob Heitz. > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > Behalf Of Jie Dong > Sent: Tuesday, August 09, 2011 6:30 PM > To: Enke Chen > Cc: idr@ietf.org > Subject: Re: [Idr] Solicit feedbacks on > draft-dong-idr-end-of-rib-use-extension > > Hi Enke, > > Thanks for your comments. > > I think we agree that RFC4724 cannot cover this case well > (otherwise any respin would not be needed). With RFC4724, BGP > speaker can signal: > a. capability as GR restarting speaker and use of EoR, or > b. capability as GR receiving speaker and use of EoR. > Thus there is no means of negotiating only EoR. > > Clearly EoR is not something tightly bound with GR, people > could use EoR without GR. Thus if people want to signal only > EoR and no GR, is it appropriate to signal it using GR capability? > > Our basic idea is to make EoR an independent feature, which > could be used in more general cases. Thus an independent > capability sounds reasonable IMO. > > Best regards, > Jie > > > -----Original Message----- > > From: Enke Chen [mailto:enkechen@cisco.com] > > Sent: Wednesday, August 10, 2011 3:14 AM > > To: Jie Dong > > Cc: idr@ietf.org; Enke Chen > > Subject: Re: [Idr] Solicit feedbacks on > > draft-dong-idr-end-of-rib-use-extension > > > > 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 > > _______________________________________________ > 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