From jie.dong@huawei.com Tue Aug 9 00:46:41 2011 Return-Path: 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 69E4D21F8AF6 for ; Tue, 9 Aug 2011 00:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oKp3kcScWL7Y for ; Tue, 9 Aug 2011 00:46:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8830E21F8A80 for ; Tue, 9 Aug 2011 00:46:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN00E8MHMBWR@szxga05-in.huawei.com> for idr@ietf.org; Tue, 09 Aug 2011 15:46:59 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN009HUHKP8Z@szxga05-in.huawei.com> for idr@ietf.org; Tue, 09 Aug 2011 15:46:59 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADA50925; Tue, 09 Aug 2011 15:46:58 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 09 Aug 2011 15:46:54 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 09 Aug 2011 15:46:58 +0800 Date: Tue, 09 Aug 2011 07:46:57 +0000 From: Jie Dong X-Originating-IP: [10.110.98.148] To: "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 07:46:41 -0000 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 From enkechen@cisco.com Tue Aug 9 12:13:16 2011 Return-Path: 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 ; 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From pmohapat@cisco.com Tue Aug 9 12:20:17 2011 Return-Path: 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 042495E8010 for ; Tue, 9 Aug 2011 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 fHtQXgg4GSZY for ; Tue, 9 Aug 2011 12:20:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFEB5E800F for ; Tue, 9 Aug 2011 12:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1902; q=dns/txt; s=iport; t=1312917646; x=1314127246; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5QNKuG/HPr67zspgOhMQRb78+/q3uy/fTGR1GgDrudQ=; b=BY6X+VMr9bkOQOaWgWiekyN9CiuYdAybr/Je3wS36o9TgmUFrQont204 AR/pEXT3I4IfSTCz9AsTGBczeYczHOzEy37Fqx4oQ3OO/AYPJd0nsxhux +NbONJbjwCLbfocvOCfFemFkQvvPbhmyMQKS94TmaIgZTv0/Uuz/AFZ7N 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAASIQU6rRDoJ/2dsb2JhbABCpz53gTkHAQEBAQIBEgEnPwULC0ZXBi4Hh0sEnnIBnmOFZ18Eh1yLKYUJjAI X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11443823" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2011 19:20:44 +0000 Received: from [10.155.34.146] ([10.155.34.146]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p79JKhXp032481; Tue, 9 Aug 2011 19:20:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> Date: Tue, 9 Aug 2011 12:25:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3220A0A0-3B64-41F8-A1B1-CB4EB54F8837@cisco.com> References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> To: Jie Dong X-Mailer: Apple Mail (2.1084) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 19:20:17 -0000 Hi Jie, > Dear all,=20 >=20 > 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 >=20 > 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. >=20 > 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.=20 >=20 > Thus we would have two alternatives here: > either we define a simple and dedicated capability for EoR,=20 > or we respin BGP GR with some further capability negotiation = functionality to cover this case. >=20 > We would like to solicit feedbacks and opinions on this draft and also = the alternatives. I don't think any new capability negotiation is required. The procedures = defined in the GR spec (RFC4724) sufficiently cover what you are trying = to achieve here. E.g. the following paragraph: 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. Moreover, many implementations do this already. The -bis for RFC4760 = clearly says that an UPDATE message with empty MP_UNREACH (essentially = the EOR) MUST not be treated as an error. IMO, this is an implementation detail and let's focus on fixing those = that do not do today. Thanks, - Pradosh= From jie.dong@huawei.com Tue Aug 9 18:06:42 2011 Return-Path: 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 6564521F8A96 for ; Tue, 9 Aug 2011 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3fUJUTEPBEGi for ; Tue, 9 Aug 2011 18:06:41 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CE21F8A95 for ; Tue, 9 Aug 2011 18:06:41 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00HK5TRXOH@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 09:07:09 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00AENTRXTX@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 09:07:09 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB03524; Wed, 10 Aug 2011 09:07:08 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 09:07:03 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 09:07:05 +0800 Date: Wed, 10 Aug 2011 01:07:06 +0000 From: Jie Dong In-reply-to: <3220A0A0-3B64-41F8-A1B1-CB4EB54F8837@cisco.com> X-Originating-IP: [10.110.98.148] To: Pradosh Mohapatra Message-id: <76CD132C3ADEF848BD84D028D243C9270B76B771@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAHpBIAABurM1A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <3220A0A0-3B64-41F8-A1B1-CB4EB54F8837@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 01:06:42 -0000 Hi Pradosh, Thanks for your comments, and please see replies inline. > 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. I note the word here is "recommended". It would be great if all implementations generate EoR in general cases (without need of GR capability), but I'm afraid now it is not the case. Please note EoR would help convergence only when a BGP speaker knows ALL its peers' behavior clearly (whether they will send EoR or not). One common way to know that is through capability negotiation. > Moreover, many implementations do this already. The -bis for RFC4760 > clearly says that an UPDATE message with empty MP_UNREACH > (essentially the EOR) MUST not be treated as an error. Yes this could ensure that bgp speakers would not treat EoR as error, but still this could not ensure or tell a speaker whether its peers will send EoR to itself. > IMO, this is an implementation detail and let's focus on fixing those that > do not do today. We could fix some implementations, but IMO using EoR for convergence is not only about local implementation, but also some negotiation/coordination between peers. Besides, fixing all the existing implementations may take quite a long time. Best regards, Jie From jie.dong@huawei.com Tue Aug 9 18:30:00 2011 Return-Path: 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 D6227228017 for ; Tue, 9 Aug 2011 18:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 nMxlJsX8Z4hU for ; Tue, 9 Aug 2011 18:30:00 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A3B22228016 for ; Tue, 9 Aug 2011 18:29:59 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00M1JUUSQU@szxga04-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 09:30:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO006PNUUS4Z@szxga04-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 09:30:28 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC07042; Wed, 10 Aug 2011 09:30:27 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 09:30:24 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 09:30:26 +0800 Date: Wed, 10 Aug 2011 01:30:26 +0000 From: Jie Dong In-reply-to: <4E4186ED.4070001@cisco.com> X-Originating-IP: [10.110.98.148] To: Enke Chen Message-id: <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAHOYeAAB0gGsA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 01:30:01 -0000 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 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 From jakob.heitz@ericsson.com Tue Aug 9 19:16:14 2011 Return-Path: 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 ; 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 ; 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 ; 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 To: Jie Dong , Enke Chen Date: Tue, 9 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > 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=20 > draft-dong-idr-end-of-rib-use-extension >=20 > Hi Enke,=20 >=20 > Thanks for your comments.=20 >=20 > I think we agree that RFC4724 cannot cover this case well=20 > (otherwise any respin would not be needed). With RFC4724, BGP=20 > speaker can signal: > a. capability as GR restarting speaker and use of EoR, or=20 > b. capability as GR receiving speaker and use of EoR. > Thus there is no means of negotiating only EoR. >=20 > Clearly EoR is not something tightly bound with GR, people=20 > could use EoR without GR. Thus if people want to signal only=20 > EoR and no GR, is it appropriate to signal it using GR capability? >=20 > Our basic idea is to make EoR an independent feature, which=20 > could be used in more general cases. Thus an independent=20 > capability sounds reasonable IMO. >=20 > Best regards, > Jie >=20 > > -----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 > >=20 > > Hi, Jie: > >=20 > > IMO RFC 4724 is sufficiently clear about the use of EOR, and also > > specifies the use of the GR capability without AFI/SAFI for=20 > indicating > > the EOR support without performing GR. Please see excerpt from RFC > > 4724 > > below. > >=20 > > Granted there are some inconsistencies in RFC 4724. A=20 > re-spin of RFC > > 4724 seems in order. Actually a re-spin is already on the=20 > IDR WG status > > report presented at the IETF-81. > >=20 > > There is no need for a new capability, though, as there is=20 > no backward > > compatibility issue for sending and receiving the GR=20 > capability (with or > > without AFI/SAFI). > >=20 > > In short, I do not see a need for=20 > draft-dong-idr-end-of-rib-use-extension. > >=20 > > -- Enke > >=20 > > ------------------------------------------------------- > >=20 > > RFC 4724 (GR) > >=20 > > 2. Marker for End-of-RIB > > ..... > >=20 > > Although the End-of-RIB marker is specified for the=20 > purpose of BGP > > graceful restart, it is noted that the generation of=20 > such a marker > > upon completion of the initial update would be useful=20 > for routing > > convergence in general, and thus the practice is recommended. > >=20 > > In addition, it would be beneficial for routing=20 > convergence if a BGP > > speaker can indicate to its peer up-front that it will=20 > generate the > > End-of-RIB marker, regardless of its ability to preserve its > > forwarding state during BGP restart. This can be=20 > accomplished using > > the Graceful Restart Capability described in the next section. > >=20 > >=20 > > 4. Operation > >=20 > > A BGP speaker MAY advertise the Graceful Restart=20 > 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=20 > to preserve > > its forwarding state for any address family during BGP=20 > restart, it is > > still recommended that the speaker advertise the=20 > Graceful Restart > > Capability to its peer (as mentioned before this is done by not > > including any in the advertised=20 > capability). There are > > two reasons for doing this. The first is to indicate=20 > its intention > > of generating the End-of-RIB marker upon the completion of its > > initial routing updates, as doing this would be useful=20 > for routing > > convergence in general. The second is to indicate its=20 > support for a > > peer which wishes to perform a graceful restart. > >=20 > >=20 > -------------------------------------------------------------- > --------- > >=20 > >=20 > > On 8/9/11 12:46 AM, Jie Dong wrote: > > > Dear all, > > > > > > Internet-Draft draft-dong-idr-end-of-rib-use-extension=20 > was submitted > > before Quebec IETF. The url is: > >=20 > 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=20 > BGP convergence, > > this draft proposes to define a EoR capability to negotiate=20 > the use of EoR > > between BGP peers. This makes EoR an independent feature=20 > and could be > > used without supporting or enabling GR capability. As=20 > according to BGP > > GR (RFC4724), BGP peers can only negotiate the combination=20 > of EoR and > > GR capability. > > > > > > We've received some offline comments, one of which suggested an > > alternative solution: respin GR specification and cover=20 > 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=20 > draft and also > > the alternatives. > > > > > > Many thanks, > > > Jie > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From raszuk@cisco.com Tue Aug 9 23:10:30 2011 Return-Path: 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 6BB6521F873D for ; Tue, 9 Aug 2011 23:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599] 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 N-Fd5FB79d5j for ; Tue, 9 Aug 2011 23:10:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AF7DB21F8726 for ; Tue, 9 Aug 2011 23:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1820; q=dns/txt; s=iport; t=1312956660; x=1314166260; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=ubcAkv6/TcyHD3OGoMLD/aUAjf1EOG7nX7XJ6Jwygr0=; b=Sbn6arPL1fS6TcMDMizbLqo5cmBPZIqJj9NYRn9QByg9cbX/SBC+WBV9 IlaBOB6pNy3tyJ54t0O8mzDUBUsHxMn/A53Kxo3YPC2ybESyV+uP5NAq3 x1MvjLJiiJHrI2E8++oBnkmLRUAc9VqKGhpLFCMbE/HCfJxUjYyRdgehp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALgfQk6rRDoH/2dsb2JhbABBp0V3gTkHAQEBAQIBAQEBDwECASI2EAsLISUPAhYwBgEMBgIBARcHh0sEnzwBgxwPAZsUhkYEkwmFCotl X-IronPort-AV: E=Sophos;i="4.67,349,1309737600"; d="scan'208";a="11625614" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2011 06:11:00 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7A6AwRF006463; Wed, 10 Aug 2011 06:10:59 GMT Message-ID: <4E422113.708@cisco.com> Date: Wed, 10 Aug 2011 08:11:31 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: idr@ietf.org, Jie Dong 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 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 Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 06:10:30 -0000 Hi Jie, As we have discussed already offline I also do not see a need for new spec to define EoR capability as a separate document. Text clarification of re-spined RFC4724 (with possible addition of new flag) would be in my opinion sufficient to address any potential doubts one could have reg explicit helper behaviour signaling when sending GR capability with null set of AFI/SAFIs. I am of the opinion that it is always much better to focus on one clear specification rather then define the same functionality in multiple and independent documents. Best regards, R. > 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 > From jie.dong@huawei.com Tue Aug 9 23:31:42 2011 Return-Path: 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 A51C05E8003 for ; Tue, 9 Aug 2011 23:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 y13A9R6QUn6P for ; Tue, 9 Aug 2011 23:31:41 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56722800E for ; Tue, 9 Aug 2011 23:31:41 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPP003I88R8YN@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 14:30:44 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPP008WK8R7NR@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 14:30:44 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB33348; Wed, 10 Aug 2011 14:30:43 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 14:30:38 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 14:30:42 +0800 Date: Wed, 10 Aug 2011 06:30:41 +0000 From: Jie Dong In-reply-to: <7309FCBCAE981B43ABBE69B31C8D213914A1EBB40B@EUSAACMS0701.eamcs.ericsson.se> X-Originating-IP: [10.110.98.148] To: Jakob Heitz , Enke Chen Message-id: <76CD132C3ADEF848BD84D028D243C9270B76B878@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AQHMVwONqKw9r26raka6fQIVUiXQ15UVY78A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <7309FCBCAE981B43ABBE69B31C8D213914A1EBB40B@EUSAACMS0701.eamcs.ericsson.se> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 06:31:42 -0000 Hi Jakob, > When a BGP speaker advertises the GR capability without > including any 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. In general it is saying "I am able to perform procedures of GR receiving speaker 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'd like to provide some clarification. With EoR capability, it only negotiates the use of EoR, and no other information (e.g. whether or not retain route states) is exchanged by this capability. > Can you state a use case where the difference matters? One use case is some bgp speakers deploy NSR and do not enable GR, thus they only want EoR but do not exchange GR capability. Generally we would assume EoR has broader use cases than GR, and should NOT be bound with GR. Similarly, in LDP, GR (RFC3478) and End-of-LIB (RFC5919) are two independent features. Best regards, Jie > > -----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 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 > > From jie.dong@huawei.com Tue Aug 9 23:45:45 2011 Return-Path: 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 3409A21F84F6 for ; Tue, 9 Aug 2011 23:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 8na5JhbB4Z28 for ; Tue, 9 Aug 2011 23:45:44 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7979821F84F3 for ; Tue, 9 Aug 2011 23:45:44 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPP0098X9EFP5@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 14:44:40 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPP0098A9EFOH@szxga05-in.huawei.com> for idr@ietf.org; Wed, 10 Aug 2011 14:44:39 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC19675; Wed, 10 Aug 2011 14:44:39 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 14:44:35 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 14:44:38 +0800 Date: Wed, 10 Aug 2011 06:44:37 +0000 From: Jie Dong In-reply-to: <4E422113.708@cisco.com> X-Originating-IP: [10.110.98.148] To: "raszuk@cisco.com" , "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C9270B76B887@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAeMdOAABFwLdA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E422113.708@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 06:45:45 -0000 Hi Robert, > As we have discussed already offline I also do not see a need for new > spec to define EoR capability as a separate document. Got your opinion on this, thanks. > Text clarification of re-spined RFC4724 (with possible addition of new > flag) would be in my opinion sufficient to address any potential doubts > one could have reg explicit helper behaviour signaling when sending GR > capability with null set of AFI/SAFIs. If you choose to re-spin RFC4724, adding new flags would definitely be needed, which is more than "text clarification". And remember this would be for negotiating features "outside" GR. Not sure if this sounds reasonable. > I am of the opinion that it is always much better to focus on one clear > specification rather then define the same functionality in multiple and > independent documents. Correct if they are exactly the same functionality:) Please note that LDP End-of-LIB and LDP GR are not the same functionality and are defined in separate documents. Best regards, Jie > > > 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 > > From raszuk@cisco.com Wed Aug 10 00:26:57 2011 Return-Path: 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 52C7C21F84E5 for ; Wed, 10 Aug 2011 00:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599] 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 qwgIzmenUy31 for ; Wed, 10 Aug 2011 00:26:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEF821F84FE for ; Wed, 10 Aug 2011 00:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=3051; q=dns/txt; s=iport; t=1312961247; x=1314170847; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bIRqjOgATgkp3tYxSPTNTzK8g06p+LQG7MJxKPEqlF0=; b=bUNsnODNFCKcpl9YUeWMDyCSVniYxH9Mqdw0G9qMchtOikBcRmd+K6Mn FJll5UHDrc4EZHGw3xjwSm5oaYWaYT/2jaGNmyVM2VP3xSBKMtu2roxh/ FyX6GEmggBZXehr74/8gzZh9ZwPF5+xCuN2RM8Tv0lEB5DvezPY2neHml w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG4yQk6rRDoG/2dsb2JhbABBp0l3gTkHAQEBAQIBAQEBDwECASI2CgEFCwshFg8JAwIBAgEVMAYNAQUCAQEXB4dLBJ9HAYMcDwGbFIZGBJMJhQqLZQ X-IronPort-AV: E=Sophos;i="4.67,349,1309737600"; d="scan'208";a="11643781" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2011 07:27:27 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7A7RP7u018106; Wed, 10 Aug 2011 07:27:25 GMT Message-ID: <4E4232FE.3040704@cisco.com> Date: Wed, 10 Aug 2011 09:27:58 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jie Dong References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E422113.708@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B887@szxeml509-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76B887@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 Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 07:26:57 -0000 Hi Jie, > Please note that LDP End-of-LIB and LDP GR are not the same > functionality and are defined in separate documents. Allow me to make an observation that LDP GR is timer driven without any LDP EOR marker involved in the restart procedures as described in rfc3478. Most likely authors of rfc3478 assumed that the amount of binding information as exchanged by LDP allows for such approach. However as we all know BGP GR does define EOR as number of BGP routes to be exchanged during the restart of the session is >> then number of LDP bindings therefor IMHO comparison of LDP GR/EOR to BGP GR/EOR is not really apple to apple case. Best regards, R. > Hi Robert, > >> As we have discussed already offline I also do not see a need for new >> spec to define EoR capability as a separate document. > > Got your opinion on this, thanks. > >> Text clarification of re-spined RFC4724 (with possible addition of new >> flag) would be in my opinion sufficient to address any potential doubts >> one could have reg explicit helper behaviour signaling when sending GR >> capability with null set of AFI/SAFIs. > > If you choose to re-spin RFC4724, adding new flags would definitely be needed, which is more than "text clarification". And remember this would be for negotiating features "outside" GR. Not sure if this sounds reasonable. > >> I am of the opinion that it is always much better to focus on one clear >> specification rather then define the same functionality in multiple and >> independent documents. > > Correct if they are exactly the same functionality:) Please note that LDP End-of-LIB and LDP GR are not the same functionality and are defined in separate documents. > > Best regards, > Jie > >> >>> 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 >>> > > From enkechen@cisco.com Wed Aug 10 16:20:02 2011 Return-Path: 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 87D6B21F8B98 for ; Wed, 10 Aug 2011 16:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 LswsyApC0uMb for ; Wed, 10 Aug 2011 16:20:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 877B821F8B94 for ; Wed, 10 Aug 2011 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=7594; q=dns/txt; s=iport; t=1313018434; x=1314228034; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1q5w6PMSrLV1IHXM74nxLI7bBcJ8XWppd9U8e9x6i8M=; b=PZbYzoD2X5LUPSaoY38iaYzoyWDERP2Lq9/ewtnvM4Xw4RUXhD85fpoY cYQn3Q9cG9GHEEWuHPCQIJ9RIBZwDK2CeC31m6mExNHVw7GPEpgFYtuAn p6M7BRkaNLyvL2DTi5eAYc2KlkRDTszRLM4OWTojbHKcJArK1fSU/VDYv g=; X-IronPort-AV: E=Sophos;i="4.67,353,1309737600"; d="scan'208";a="11958270" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2011 23:20:34 +0000 Received: from dhcp-171-71-139-199.cisco.com (dhcp-171-71-139-199.cisco.com [171.71.139.199]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7ANKX8A014328; Wed, 10 Aug 2011 23:20:33 GMT Message-ID: <4E431244.5050206@cisco.com> Date: Wed, 10 Aug 2011 16:20:36 -0700 From: Enke Chen 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 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> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 23:20:02 -0000 Hi, Jie: There is no dispute about using EOR without performing the GR procedures (i.e., retaining stale routes). That had always been the intention during the GR design. The semantics of the GR capability without any AFI/SAFI was designed specifically for that purpose. Unfortunately there are some inconsistencies in this area between Sect 3 and 4 of RFC 4724. The first two paragraphs in Section 4 talks about the general rules of advertising the GR cap and sending EOR. But the reference in Section 3 jumps directly to Section 4.2. The inconsistency needs to be fixed in a re-spin. It a local decision whether a speaker retains stale routes from a remote speaker, and the decision has no impact on how the remote speaker would behave. Thus no backward compatibility issue would arise from the local decision. That is something that should be clarified in a re-spin. Regards, -- Enke ----------------------------------------- 3. Graceful Restart Capability ... When a sender of this capability does not include any in the capability, it means that the sender is not capable of preserving its forwarding state during BGP restart, but supports procedures for the Receiving Speaker (as defined in Section 4.2 of this document). In that case, the value of the "Restart Time" field advertised by the sender is irrelevant. --- 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 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. The End-of-RIB marker MUST be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established. -------------------------- On 8/9/11 6:30 PM, Jie Dong wrote: > 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 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 From internet-drafts@ietf.org Wed Aug 10 19:06:55 2011 Return-Path: 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 21FEC21F8B3D; Wed, 10 Aug 2011 19:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aKOoQqvkzq29; Wed, 10 Aug 2011 19:06:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DEC21F8B32; Wed, 10 Aug 2011 19:06:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811020654.16291.91461.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2011 19:06:54 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-fsm-subcode-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 02:06:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Subcodes for BGP Finite State Machine Error Author(s) : Jie Dong Mach Chen Anantharamu Suryanarayana Filename : draft-ietf-idr-fsm-subcode-02.txt Pages : 5 Date : 2011-08-10 This document defines several subcodes for BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-02.txt From jie.dong@huawei.com Thu Aug 11 02:40:39 2011 Return-Path: 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 21FE821F8AF3 for ; Thu, 11 Aug 2011 02:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 BeNm1A641dt4 for ; Thu, 11 Aug 2011 02:40:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E621F8AE4 for ; Thu, 11 Aug 2011 02:40:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR007HMB720I@szxga04-in.huawei.com> for idr@ietf.org; Thu, 11 Aug 2011 17:18:38 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR00KAXB72J1@szxga04-in.huawei.com> for idr@ietf.org; Thu, 11 Aug 2011 17:18:38 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC69235; Thu, 11 Aug 2011 17:18:38 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 17:18:32 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 17:18:38 +0800 Date: Thu, 11 Aug 2011 09:18:37 +0000 From: Jie Dong In-reply-to: <4E4232FE.3040704@cisco.com> X-Originating-IP: [10.110.98.148] To: "raszuk@cisco.com" Message-id: <76CD132C3ADEF848BD84D028D243C9270B76BD64@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAeMdOAABFwLdD//4naAP/9zO7g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E422113.708@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B887@szxeml509-mbs.china.huawei.com> <4E4232FE.3040704@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:40:39 -0000 Hi Robert, > Allow me to make an observation that LDP GR is timer driven without any > LDP EOR marker involved in the restart procedures as described in > rfc3478. Most likely authors of rfc3478 assumed that the amount of > binding information as exchanged by LDP allows for such approach. RFC5919 specifies usage guidelines of LDP End-of-LIB for LDP GR: "Receiving End-of-LIB Notification from a peer in an LDP Graceful Restart scenario enables an LDP speaker to stop using stale forwarding information learned from that peer and to recover the resources it requires without having to wait until the time period expiry. The time period expiry can still be used if the End-of-LIB Notification message is not received. " > However as we all know BGP GR does define EOR as number of BGP routes > to > be exchanged during the restart of the session is >> then number of LDP > bindings therefor IMHO comparison of LDP GR/EOR to BGP GR/EOR is not > really apple to apple case. Yes the amount of information to be exchanged may be different, but for LDP it would also be beneficial to reduce the time in GR mode and exit GR ASAP. Regards, Jie > > > Hi Robert, > > > >> As we have discussed already offline I also do not see a need for new > >> spec to define EoR capability as a separate document. > > > > Got your opinion on this, thanks. > > > >> Text clarification of re-spined RFC4724 (with possible addition of new > >> flag) would be in my opinion sufficient to address any potential doubts > >> one could have reg explicit helper behaviour signaling when sending GR > >> capability with null set of AFI/SAFIs. > > > > If you choose to re-spin RFC4724, adding new flags would definitely be > needed, which is more than "text clarification". And remember this would > be for negotiating features "outside" GR. Not sure if this sounds > reasonable. > > > >> I am of the opinion that it is always much better to focus on one clear > >> specification rather then define the same functionality in multiple and > >> independent documents. > > > > Correct if they are exactly the same functionality:) Please note that LDP > End-of-LIB and LDP GR are not the same functionality and are defined in > separate documents. > > > > Best regards, > > Jie > > > >> > >>> 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 > >>> > > > > From jie.dong@huawei.com Thu Aug 11 04:16:54 2011 Return-Path: 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 D72C721F8A97 for ; Thu, 11 Aug 2011 04:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 xySFcFZWXbmN for ; Thu, 11 Aug 2011 04:16:54 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 98BFB21F8A95 for ; Thu, 11 Aug 2011 04:16:53 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR00FKAGMTHW@szxga05-in.huawei.com> for idr@ietf.org; Thu, 11 Aug 2011 19:16:05 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR0049XGMJVQ@szxga05-in.huawei.com> for idr@ietf.org; Thu, 11 Aug 2011 19:16:05 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC53660; Thu, 11 Aug 2011 19:16:05 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 19:16:00 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 19:16:05 +0800 Date: Thu, 11 Aug 2011 11:16:03 +0000 From: Jie Dong In-reply-to: <4E431244.5050206@cisco.com> X-Originating-IP: [10.110.98.148] To: Enke Chen Message-id: <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AcxWaIOGlX/cLil9Quelmj6EiTtLxwAHOYeAAB0gGsAAHcjrAAAlzNuQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 11:16:54 -0000 Hi Enke, Thanks for your replies. > There is no dispute about using EOR without performing the GR > procedures > (i.e., retaining stale routes). That had always been the intention > during the GR design. The semantics of the GR capability without any > AFI/SAFI was designed specifically for that purpose. It's good that we agree on this scenario. IMO now GR capability with null AFI/SAFI is for signaling "GR helper and EoR". If we want to use it to signal EoR only, we may need another way to signal the GR helper capability. > Unfortunately there are some inconsistencies in this area between Sect 3 > and 4 of RFC 4724. The first two paragraphs in Section 4 talks about > the general rules of advertising the GR cap and sending EOR. But the > reference in Section 3 jumps directly to Section 4.2. The inconsistency > needs to be fixed in a re-spin. IMO the two scenarios mentioned in sec 4 cannot be signaled separately through one single capability format. Thus some additional flag needs be defined if you choose to re-spin GR RFC, and such extension would be for scenarios NOT enabling GR. That's why the draft proposes a dedicate capability for EoR only scenario. > It a local decision whether a speaker retains stale routes from a remote > speaker, and the decision has no impact on how the remote speaker > would > behave. Thus no backward compatibility issue would arise from the local > decision. That is something that should be clarified in a re-spin. IMO whether a speaker would retain stale routes SHOULD be signaled to its peer, then the peer (and peer's operator) could know whether GR is deployed and would take effect between the two BGP speakers. Otherwise the operator cannot tell where in the network GR is deployed and where only EoR is used. Best regards, Jie > ----------------------------------------- > 3. Graceful Restart Capability > > ... > > When a sender of this capability does not include any in > the capability, it means that the sender is not capable of preserving > its forwarding state during BGP restart, but supports procedures for > the Receiving Speaker (as defined in Section 4.2 of this document). > In that case, the value of the "Restart Time" field advertised by the > sender is irrelevant. > > --- > > 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 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. > > The End-of-RIB marker MUST be sent by a BGP speaker to its peer > once > it completes the initial routing update (including the case when > there is no update to send) for an address family after the BGP > session is established. > > -------------------------- > > > On 8/9/11 6:30 PM, Jie Dong wrote: > > 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 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 From raszuk@cisco.com Thu Aug 11 06:15:37 2011 Return-Path: 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 6B34D21F87FC for ; Thu, 11 Aug 2011 06:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599] 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 U0M+HXXmlBcb for ; Thu, 11 Aug 2011 06:15:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BC9EB21F87ED for ; Thu, 11 Aug 2011 06:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1130; q=dns/txt; s=iport; t=1313068571; x=1314278171; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ScPWoCSW8fLBy1HehLtYB9MTIgAgSZULRU0aKScEkRQ=; b=NFWGDYausjGeAHMh6RCoGIvLOau6+ZLAwCXErk5AGaxCMF/S6bg2BG2G 7ufesj6icKLOSh3E54uhtJ2ekDzL4rEulmwzsIFmpvgPTs1XClETyVN9r /P/tVArcYxZTVrzk2oj0As3QH+uw96XN4u+40iNpgtxuEWFhuJ/OUAhQm k=; X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208";a="12172766" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 11 Aug 2011 13:16:10 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7BDG801030558; Thu, 11 Aug 2011 13:16:08 GMT Message-ID: <4E43D60C.3000906@cisco.com> Date: Thu, 11 Aug 2011 15:15:56 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jie Dong References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76BE40@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 Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 13:15:37 -0000 Hi Jie, > It's good that we agree on this scenario. IMO now GR capability with > null AFI/SAFI is for signaling "GR helper and EoR". I would not agree with that. It is in fact just the opposite. > If we want to use it to signal EoR only, we may need another way to > signal the GR helper capability. + > IMO the two scenarios mentioned in sec 4 cannot be signaled > separately through one single capability format. Thus some additional > flag needs be defined While I did suggested the addition of flag after rethinking this a bit more I do not think it is necessary. Here is my idea: -- * When you signal GR capability with null AFI/SAFI list - it just means use of EOR - it does not mean you support helper mode. * When you signal GR capability with non-null AFI/SAFI (at least one AFI/SAFI included) - it will mean use of EOR, helper mode support + GR support for this/those AFI/SAFIs. -- If the GR RFC will clarify that to reflect such semantics I think all confusions are addressed and all cases covered without any need for protocol extension. Thoughts ? Thx, R. From iesg-secretary@ietf.org Thu Aug 11 08:47:22 2011 Return-Path: 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 9947021F8571; Thu, 11 Aug 2011 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZVgpp0ZsPCDW; Thu, 11 Aug 2011 08:47:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC6D21F8520; Thu, 11 Aug 2011 08:47:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811154722.11750.88395.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 08:47:22 -0700 Cc: idr@ietf.org Subject: [Idr] Last Call: (Deprecation of the use of BGP AS_SET, AS_CONFED_SET.) to Informational RFC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:47:22 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Deprecation of the use of BGP AS_SET, AS_CONFED_SET.' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document deprecates the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu Aug 11 08:48:43 2011 Return-Path: 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 A1ABD21F8561; Thu, 11 Aug 2011 08:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hABAQA+Qfy1G; Thu, 11 Aug 2011 08:48:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D0921F8B6B; Thu, 11 Aug 2011 08:48:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110811154843.12814.57713.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2011 08:48:43 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-issues-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 15:48:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Issues in Revising BGP-4 (RFC1771 to RFC4271) Author(s) : Andrew S. Lange Filename : draft-ietf-idr-bgp-issues-05.txt Pages : 170 Date : 2011-08-11 This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The document focuses on the changes tracked from August 2002 when the last major push for revision began. The results of these efforts are encoded in RFC4271, which should be taken as normative for any of the issues that were discussed. The discussion here is intended to record how and why some of the changes to BGP were made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-05.txt From jgs@juniper.net Thu Aug 11 12:07:08 2011 Return-Path: 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 A75D321F8B7D for ; Thu, 11 Aug 2011 12:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 8Jfol5M5ehNh for ; Thu, 11 Aug 2011 12:07:08 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E5A0D21F8B74 for ; Thu, 11 Aug 2011 12:07:07 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTkQofngHYKsKzJxtNCa/6j+x4jtOkZVz@postini.com; Thu, 11 Aug 2011 12:07:43 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 11 Aug 2011 12:07:15 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 11 Aug 2011 12:07:20 -0700 Thread-Topic: Abbreviated comment period on draft-ietf-idr-fsm-subcode-02.txt Thread-Index: AcxYWeGuqCb7ueW1SQiocKH+QwVpDg== Message-ID: <467A4831-1992-45D9-8D70-76452BF8862B@juniper.net> References: <20110811020654.16291.91461.idtracker@ietfa.amsl.com> In-Reply-To: <20110811020654.16291.91461.idtracker@ietfa.amsl.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 Subject: [Idr] Abbreviated comment period on draft-ietf-idr-fsm-subcode-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:07:08 -0000 Folks, At the request of the document shepherd the authors updated the IANA Consid= erations section and made a few editorial fixes. One change, while minor, = still seems substantive enough to warrant a comment period before advancing= the document. The draft creates a new registry for FSM Error subcodes and= proposes that the registration procedures be "Standards Action process or = the Early IANA Allocation process". This is consistent with the other subc= ode registries. =20 If you have any comments please send them by August 18. Thanks, --John On Aug 10, 2011, at 10:06 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Inter-Domain Routing Working Group = of the IETF. >=20 > Title : Subcodes for BGP Finite State Machine Error > Author(s) : Jie Dong > Mach Chen > Anantharamu Suryanarayana > Filename : draft-ietf-idr-fsm-subcode-02.txt > Pages : 5 > Date : 2011-08-10 >=20 > This document defines several subcodes for BGP Finite State Machine > (FSM) Error that could provide more information to help network > operators in diagnosing BGP FSM issues and correlating network > events. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-fsm-subcode-02.txt > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Thu Aug 11 12:47:26 2011 Return-Path: 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 75B5421F8AFF for ; Thu, 11 Aug 2011 12:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 CFEsF4NrOzbI for ; Thu, 11 Aug 2011 12:47:26 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8D821F8AFB for ; Thu, 11 Aug 2011 12:47:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTkQx7fDfSh0FNXX0ZdkdG1pvULwl/HXz@postini.com; Thu, 11 Aug 2011 12:48:01 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 11 Aug 2011 12:47:17 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 11 Aug 2011 12:47:22 -0700 Thread-Topic: Document track for draft-ietf-idr-bgp-bestpath-selection-criteria-03.txt Thread-Index: AcxYX3nHHQPvN9s6Qrez23bRqZdgKw== Message-ID: <2E65D1B2-4F75-4E76-9BD2-A8C165043B76@juniper.net> References: <20110726183618.27816.25778.idtracker@ietfa.amsl.com> In-Reply-To: <20110726183618.27816.25778.idtracker@ietfa.amsl.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: "draft-ietf-idr-bgp-bestpath-selection-criteria@tools.ietf.org" Subject: [Idr] Document track for draft-ietf-idr-bgp-bestpath-selection-criteria-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:47:26 -0000 Folks, In advancing draft-ietf-idr-bgp-bestpath-selection-criteria, our AD request= ed we move the document from Informational to Standards track, and add 'Upd= ates: RFC 4271'. This makes sense since the document does provide advice t= o implementors of the standard. Rajiv, can you make the updates and reissue the doc? List members, if you have any comments regarding the change in document tra= ck, please send them to the list by August 18. Thanks, --John and Sue On Jul 26, 2011, at 2:36 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Inter-Domain Routing Working Group = of the IETF. >=20 > Title : BGP Bestpath Selection Criteria > Author(s) : Rajiv Asati > Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-03.txt > Pages : 9 > Date : 2011-07-26 >=20 > BGP specification [RFC4271] prescribes 'BGP next-hop reachability&#= 39; > as one of the key 'Route Resolvability Condition' that must be > satisfied before the BGP bestpath candidate selection. This > condition, however, may not be sufficient (as explained in the > Appendix section) and desire further granularity. >=20 > This document defines enhances the "Route Resolvability Condition&= quot; > to facilitate the next-hop to be resolved in the chosen data plane. >=20 >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection= -criteria-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-= criteria-03.txt > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Thu Aug 11 15:11:24 2011 Return-Path: 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 0C25C21F8AAC; Thu, 11 Aug 2011 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NYZsa2RC5AMs; Thu, 11 Aug 2011 15:11:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A38C021F8AA8; Thu, 11 Aug 2011 15:11:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QrdTq-000Did-Ae; Thu, 11 Aug 2011 22:11:58 +0000 Date: Fri, 12 Aug 2011 07:11:57 +0900 Message-ID: From: Randy Bush To: IETF Disgust , IETF IDR In-Reply-To: <20110811154722.11750.88395.idtracker@ietfa.amsl.com> References: <20110811154722.11750.88395.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Idr] Last Call: (Deprecation of the use of BGP AS_SET, AS_CONFED_SET.) to Informational RFC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:11:24 -0000 > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'Deprecation of the use of BGP AS_SET, AS_CONFED_SET.' > as an Informational RFC i have read and support this document. AS-Sets are essentially unused, the deprecation is needed for the sidr work, and their removal will make many research and ops tools which run against bgp announcements easier. randy From mrossi@swin.edu.au Thu Aug 11 16:47:41 2011 Return-Path: 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 0FBCA11E809B for ; Thu, 11 Aug 2011 16:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 dW33ft5OAx7X for ; Thu, 11 Aug 2011 16:47:40 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91511E8090 for ; Thu, 11 Aug 2011 16:47:40 -0700 (PDT) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p7BNm1QY015537 for ; Fri, 12 Aug 2011 09:48:14 +1000 Message-ID: <4E446A31.1000804@swin.edu.au> Date: Fri, 12 Aug 2011 09:48:01 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20110811154722.11750.88395.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Last Call: (Deprecation of the use of BGP AS_SET, AS_CONFED_SET.) to Informational RFC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:47:41 -0000 On 12/08/2011 08:11, Randy Bush wrote: >> The IESG has received a request from the Inter-Domain Routing WG (idr) to >> consider the following document: >> - 'Deprecation of the use of BGP AS_SET, AS_CONFED_SET.' >> as an Informational RFC > > i have read and support this document. AS-Sets are essentially unused, > the deprecation is needed for the sidr work, and their removal will make > many research and ops tools which run against bgp announcements easier. > Writing and working with such research tools I can only support this document as well. In fact I'm usually ignoring AS-Sets, as their use is already extremely rare, and they just complicate the code. Mat From internet-drafts@ietf.org Mon Aug 15 16:16:21 2011 Return-Path: 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 0370B21F8D03; Mon, 15 Aug 2011 16:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 Etdk18AmVJYw; Mon, 15 Aug 2011 16:16:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48821F8CDF; Mon, 15 Aug 2011 16:16:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110815231620.1960.74584.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2011 16:16:20 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4760bis-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 23:16:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : Tony Bates Ravi Chandra Dave Katz Filename : draft-ietf-idr-rfc4760bis-02.txt Pages : 13 Date : 2011-08-15 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-02.txt From cayle.spandon@gmail.com Tue Aug 16 04:31:20 2011 Return-Path: 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 8FB8C21F8AD3 for ; Tue, 16 Aug 2011 04:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gas72RxvPsCA for ; Tue, 16 Aug 2011 04:31:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6221F8A95 for ; Tue, 16 Aug 2011 04:31:19 -0700 (PDT) Received: by wwf5 with SMTP id 5so3868217wwf.13 for ; Tue, 16 Aug 2011 04:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Mx4/f1jXPAZQzuqu/wHeaStodnAc2oGfZ7IXyf+qXQk=; b=bsQA6z4CqOgKCjtaoJ+Ulms+STcU08zqJeOnpd9XFyH1kHSyLFtpmddLaGRzOhZwqo nVBoVK9UkzDOpgXzcQEwjvO6+58Q2YQ9jEK7xlrpzfQdSzq6he3Js2eX93rKUCrmX3B4 oAb5f23CgwMzJWbD4AdynDkQyHTV13TdFM3WI= MIME-Version: 1.0 Received: by 10.216.233.7 with SMTP id o7mr4499721weq.7.1313494327150; Tue, 16 Aug 2011 04:32:07 -0700 (PDT) Received: by 10.216.170.71 with HTTP; Tue, 16 Aug 2011 04:32:07 -0700 (PDT) In-Reply-To: <4E43D60C.3000906@cisco.com> References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> Date: Tue, 16 Aug 2011 07:32:07 -0400 Message-ID: From: Cayle Spandon To: "idr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 11:31:20 -0000 I think it is fair to say that everyone agrees that EoR makes sense without GR. With 20/20 hindsight, it would probably have been "cleaner" to define a separate capability for EoR and GR. But we have to play the cards we have been dealt, and at this point I can sympathize with the position that clarifying/tweaking the existing specs would minimize churn and confusion. (That said, I would not object to "doing the right thing from an architecture point of view" and creating a new EoR capability even though doing so would create a new set of confusions on how the new EoR capability would interact with the existing GR capability.) Regardless of what we decide to do (tweak GR capability or add EoR capability) I think that the following 3 problems need to fixed: 1. There must be a way of negotiating EoR in such a way that the receiver can be 100% certain that it will receive an EoR at the end of initial convergence. As pointed out by earlier posters, there are some inconsistencies in the current GR spec which cause it to be unclear (for certain scenarios, notably when is included) whether an EOR should be sent after initial convergence. 2. It is not sufficient to simply clarify the language in a respin of the GR spec without any protocol changes. If we did that, the receiver of a GR capability would have no way to know 100% sure that the remote side intends to send an EoR after initial convergence (because it doesn't know whether the remote side was implemented before or after the "clarifications"). Thus, we need to add "something" (either a new flag in the existing GR capability to a new EoR capability) which conveys to the other side: "I guarantee that I will send EoR after initial convergence". 3. We also need to clarify the behavior for router-refresh. In my opinion it would be good to also indicate end-of-route-refresh with an EoR (or similar) message. -- Bruno PS to muddle the waters some more: If we do end up going down the path of a new EoR capability, then I would suggest that the authors of draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could be enhanced to include SoR (Start-of-RIB) as well which would cover the need for start-of-route-refresh and end-of-route-refresh. On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk wrote: > Hi Jie, > >> It's good that we agree on this scenario. IMO now GR capability with >> null AFI/SAFI is for signaling "GR helper and EoR". > > I would not agree with that. It is in fact just the opposite. > >> If we want to use it to signal EoR only, we may need another way to > >> signal the GR helper capability. > > + > >> IMO the two scenarios mentioned in sec 4 cannot be signaled >> separately through one single capability format. Thus some additional >> flag needs be defined > > While I did suggested the addition of flag after rethinking this a bit more > I do not think it is necessary. > > Here is my idea: > > -- > > * When you signal GR capability with null AFI/SAFI list - it just means use > of EOR - it does not mean you support helper mode. > > * When you signal GR capability with non-null AFI/SAFI (at least one > AFI/SAFI included) - it will mean use of EOR, helper mode support + GR > support for this/those AFI/SAFIs. > > -- > > If the GR RFC will clarify that to reflect such semantics I think all > confusions are addressed and all cases covered without any need for protocol > extension. > > Thoughts ? > > Thx, > R. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From internet-drafts@ietf.org Tue Aug 16 06:31:55 2011 Return-Path: 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 6D60C21F8AE1; Tue, 16 Aug 2011 06:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 E1niSxWjhIYB; Tue, 16 Aug 2011 06:31:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215B821F8A71; Tue, 16 Aug 2011 06:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110816133155.32171.97924.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2011 06:31:55 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4760bis-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:31:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : Tony Bates Ravi Chandra Dave Katz Filename : draft-ietf-idr-rfc4760bis-03.txt Pages : 13 Date : 2011-08-16 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-03.txt From jakob.heitz@ericsson.com Tue Aug 16 07:22:29 2011 Return-Path: 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 52D6621F8713 for ; Tue, 16 Aug 2011 07:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, 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 gexawS4q1s1j for ; Tue, 16 Aug 2011 07:22:28 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5D721F86DE for ; Tue, 16 Aug 2011 07:22:28 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7GENAnm024783; Tue, 16 Aug 2011 09:23:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 16 Aug 2011 10:23:13 -0400 From: Jakob Heitz To: Cayle Spandon Date: Tue, 16 Aug 2011 10:23:47 -0400 Thread-Topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-Index: AcxcIAezo0Y+32d7RRStS/hzMTfx6Q== Message-ID: References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:22:29 -0000 QWdhaW46DQoNCldoZW4gYSBCR1Agc3BlYWtlciBhZHZlcnRpc2VzIHRoZSBHUiBjYXBhYmlsaXR5 IHdpdGhvdXQNCmluY2x1ZGluZyBhbnkgPEFGSSxTQUZJPiBpdCBpcyBzYXlpbmcgdG8gdGhlIHBl ZXI6DQpJIHdpbGwgc2VuZCBhbiBFT1Igd2hlbiBteSBpbml0aWFsIHVwZGF0ZSBpcyBjb21wbGV0 ZSBhbmQNCkkgTUFZIHJldGFpbiB5b3VyIHJvdXRlcyB3aGVuIHlvdSByZXN0YXJ0Lg0KDQpXaGVu IGEgQkdQIHNwZWFrZXIgYWR2ZXJ0aXNlcyB5b3VyIGV4dGVuc2lvbiwNCml0IGlzIHNheWluZyB0 byB0aGUgcGVlcjoNCkkgd2lsbCBzZW5kIGFuIEVPUiB3aGVuIG15IGluaXRpYWwgdXBkYXRlIGlz IGNvbXBsZXRlIGFuZA0KSSBXSUxMIE5PVCByZXRhaW4geW91ciByb3V0ZXMgd2hlbiB5b3UgcmVz dGFydC4NCg0KQ2FuIHlvdSBzdGF0ZSBhIHVzZSBjYXNlIHdoZXJlIHRoZSBkaWZmZXJlbmNlIG1h dHRlcnM/DQoNCi0tDQpKYWtvYiBIZWl0ei4NCg0KDQpPbiBBdWcgMTYsIDIwMTEsIGF0IDQ6MzIg QU0sICJDYXlsZSBTcGFuZG9uIiA8Y2F5bGUuc3BhbmRvbkBnbWFpbC5jb208bWFpbHRvOmNheWxl LnNwYW5kb25AZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgdGhpbmsgaXQgaXMgZmFpciB0byBzYXkg dGhhdCBldmVyeW9uZSBhZ3JlZXMgdGhhdCBFb1IgbWFrZXMgc2Vuc2UNCndpdGhvdXQgR1IuDQoN CldpdGggMjAvMjAgaGluZHNpZ2h0LCBpdCB3b3VsZCBwcm9iYWJseSBoYXZlIGJlZW4gImNsZWFu ZXIiIHRvIGRlZmluZQ0KYSBzZXBhcmF0ZSBjYXBhYmlsaXR5IGZvciBFb1IgYW5kIEdSLg0KDQpC dXQgd2UgaGF2ZSB0byBwbGF5IHRoZSBjYXJkcyB3ZSBoYXZlIGJlZW4gZGVhbHQsIGFuZCBhdCB0 aGlzIHBvaW50IEkNCmNhbiBzeW1wYXRoaXplIHdpdGggdGhlIHBvc2l0aW9uIHRoYXQgY2xhcmlm eWluZy90d2Vha2luZyB0aGUgZXhpc3RpbmcNCnNwZWNzIHdvdWxkIG1pbmltaXplIGNodXJuIGFu ZCBjb25mdXNpb24uDQoNCihUaGF0IHNhaWQsIEkgd291bGQgbm90IG9iamVjdCB0byAiZG9pbmcg dGhlIHJpZ2h0IHRoaW5nIGZyb20gYW4NCmFyY2hpdGVjdHVyZSBwb2ludCBvZiB2aWV3IiBhbmQg Y3JlYXRpbmcgYSBuZXcgRW9SIGNhcGFiaWxpdHkgZXZlbg0KdGhvdWdoIGRvaW5nIHNvIHdvdWxk IGNyZWF0ZSBhIG5ldyBzZXQgb2YgY29uZnVzaW9ucyBvbiBob3cgdGhlIG5ldw0KRW9SIGNhcGFi aWxpdHkgd291bGQgaW50ZXJhY3Qgd2l0aCB0aGUgZXhpc3RpbmcgR1IgY2FwYWJpbGl0eS4pDQoN ClJlZ2FyZGxlc3Mgb2Ygd2hhdCB3ZSBkZWNpZGUgdG8gZG8gKHR3ZWFrIEdSIGNhcGFiaWxpdHkg b3IgYWRkIEVvUg0KY2FwYWJpbGl0eSkgSSB0aGluayB0aGF0IHRoZSBmb2xsb3dpbmcgMyBwcm9i bGVtcyBuZWVkIHRvIGZpeGVkOg0KDQoxLiBUaGVyZSBtdXN0IGJlIGEgd2F5IG9mIG5lZ290aWF0 aW5nIEVvUiBpbiBzdWNoIGEgd2F5IHRoYXQgdGhlDQpyZWNlaXZlciBjYW4gYmUgMTAwJSBjZXJ0 YWluIHRoYXQgaXQgd2lsbCByZWNlaXZlIGFuIEVvUiBhdCB0aGUgZW5kIG9mDQppbml0aWFsIGNv bnZlcmdlbmNlLiBBcyBwb2ludGVkIG91dCBieSBlYXJsaWVyIHBvc3RlcnMsIHRoZXJlIGFyZSBz b21lDQppbmNvbnNpc3RlbmNpZXMgaW4gdGhlIGN1cnJlbnQgR1Igc3BlYyB3aGljaCBjYXVzZSBp dCB0byBiZSB1bmNsZWFyDQooZm9yIGNlcnRhaW4gc2NlbmFyaW9zLCBub3RhYmx5IHdoZW4gPEFG SSxTQUZJPiBpcyBpbmNsdWRlZCkgd2hldGhlcg0KYW4gRU9SIHNob3VsZCBiZSBzZW50IGFmdGVy IGluaXRpYWwgY29udmVyZ2VuY2UuDQoNCjIuIEl0IGlzIG5vdCBzdWZmaWNpZW50IHRvIHNpbXBs eSBjbGFyaWZ5IHRoZSBsYW5ndWFnZSBpbiBhIHJlc3BpbiBvZg0KdGhlIEdSIHNwZWMgd2l0aG91 dCBhbnkgcHJvdG9jb2wgY2hhbmdlcy4gSWYgd2UgZGlkIHRoYXQsIHRoZSByZWNlaXZlcg0Kb2Yg YSBHUiBjYXBhYmlsaXR5IHdvdWxkIGhhdmUgbm8gd2F5IHRvIGtub3cgMTAwJSBzdXJlIHRoYXQg dGhlIHJlbW90ZQ0Kc2lkZSBpbnRlbmRzIHRvIHNlbmQgYW4gRW9SIGFmdGVyIGluaXRpYWwgY29u dmVyZ2VuY2UgKGJlY2F1c2UgaXQNCmRvZXNuJ3Qga25vdyB3aGV0aGVyIHRoZSByZW1vdGUgc2lk ZSB3YXMgaW1wbGVtZW50ZWQgYmVmb3JlIG9yIGFmdGVyDQp0aGUgImNsYXJpZmljYXRpb25zIiku IFRodXMsIHdlIG5lZWQgdG8gYWRkICJzb21ldGhpbmciIChlaXRoZXIgYSBuZXcNCmZsYWcgaW4g dGhlIGV4aXN0aW5nIEdSIGNhcGFiaWxpdHkgdG8gYSBuZXcgRW9SIGNhcGFiaWxpdHkpIHdoaWNo DQpjb252ZXlzIHRvIHRoZSBvdGhlciBzaWRlOiAiSSBndWFyYW50ZWUgdGhhdCBJIHdpbGwgc2Vu ZCBFb1IgYWZ0ZXINCmluaXRpYWwgY29udmVyZ2VuY2UiLg0KDQozLiBXZSBhbHNvIG5lZWQgdG8g Y2xhcmlmeSB0aGUgYmVoYXZpb3IgZm9yIHJvdXRlci1yZWZyZXNoLiBJbiBteQ0Kb3BpbmlvbiBp dCB3b3VsZCBiZSBnb29kIHRvIGFsc28gaW5kaWNhdGUgZW5kLW9mLXJvdXRlLXJlZnJlc2ggd2l0 aCBhbg0KRW9SIChvciBzaW1pbGFyKSBtZXNzYWdlLg0KDQotLSBCcnVubw0KDQpQUyB0byBtdWRk bGUgdGhlIHdhdGVycyBzb21lIG1vcmU6IElmIHdlIGRvIGVuZCB1cCBnb2luZyBkb3duIHRoZSBw YXRoDQpvZiBhIG5ldyBFb1IgY2FwYWJpbGl0eSwgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB0 aGUgYXV0aG9ycyBvZg0KZHJhZnQtaWV0Zi1pZHItYmdwLWVuaGFuY2VkLXJvdXRlLXJlZnJlc2gg am9pbiB0aGUgZWZmb3J0OyBFb1IgY291bGQNCmJlIGVuaGFuY2VkIHRvIGluY2x1ZGUgU29SIChT dGFydC1vZi1SSUIpIGFzIHdlbGwgd2hpY2ggd291bGQgY292ZXINCnRoZSBuZWVkIGZvciBzdGFy dC1vZi1yb3V0ZS1yZWZyZXNoIGFuZCBlbmQtb2Ytcm91dGUtcmVmcmVzaC4NCg0KT24gVGh1LCBB dWcgMTEsIDIwMTEgYXQgOToxNSBBTSwgUm9iZXJ0IFJhc3p1ayA8cmFzenVrQGNpc2NvLmNvbTxt YWlsdG86cmFzenVrQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgSmllLA0KDQpJdCdzIGdvb2QgdGhh dCB3ZSBhZ3JlZSBvbiB0aGlzIHNjZW5hcmlvLiBJTU8gbm93IEdSIGNhcGFiaWxpdHkgd2l0aA0K bnVsbCBBRkkvU0FGSSBpcyBmb3Igc2lnbmFsaW5nICJHUiBoZWxwZXIgYW5kIEVvUiIuDQoNCkkg d291bGQgbm90IGFncmVlIHdpdGggdGhhdC4gSXQgaXMgaW4gZmFjdCBqdXN0IHRoZSBvcHBvc2l0 ZS4NCg0KSWYgd2Ugd2FudCB0byB1c2UgaXQgdG8gc2lnbmFsIEVvUiBvbmx5LCB3ZSBtYXkgbmVl ZCBhbm90aGVyIHdheSB0bw0KDQpzaWduYWwgdGhlIEdSIGhlbHBlciBjYXBhYmlsaXR5Lg0KDQor DQoNCklNTyB0aGUgdHdvIHNjZW5hcmlvcyBtZW50aW9uZWQgaW4gc2VjIDQgY2Fubm90IGJlIHNp Z25hbGVkDQpzZXBhcmF0ZWx5IHRocm91Z2ggb25lIHNpbmdsZSBjYXBhYmlsaXR5IGZvcm1hdC4g VGh1cyBzb21lIGFkZGl0aW9uYWwNCmZsYWcgbmVlZHMgYmUgZGVmaW5lZA0KDQpXaGlsZSBJIGRp ZCBzdWdnZXN0ZWQgdGhlIGFkZGl0aW9uIG9mIGZsYWcgYWZ0ZXIgcmV0aGlua2luZyB0aGlzIGEg Yml0IG1vcmUNCkkgZG8gbm90IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeS4NCg0KSGVyZSBpcyBteSBp ZGVhOg0KDQotLQ0KDQoqIFdoZW4geW91IHNpZ25hbCBHUiBjYXBhYmlsaXR5IHdpdGggbnVsbCBB RkkvU0FGSSBsaXN0IC0gaXQganVzdCBtZWFucyB1c2UNCm9mIEVPUiAtIGl0IGRvZXMgbm90IG1l YW4geW91IHN1cHBvcnQgaGVscGVyIG1vZGUuDQoNCiogV2hlbiB5b3Ugc2lnbmFsIEdSIGNhcGFi aWxpdHkgd2l0aCBub24tbnVsbCBBRkkvU0FGSSAoYXQgbGVhc3Qgb25lDQpBRkkvU0FGSSBpbmNs dWRlZCkgLSBpdCB3aWxsIG1lYW4gdXNlIG9mIEVPUiwgaGVscGVyIG1vZGUgc3VwcG9ydCArIEdS DQpzdXBwb3J0IGZvciB0aGlzL3Rob3NlIEFGSS9TQUZJcy4NCg0KLS0NCg0KSWYgdGhlIEdSIFJG QyB3aWxsIGNsYXJpZnkgdGhhdCB0byByZWZsZWN0IHN1Y2ggc2VtYW50aWNzIEkgdGhpbmsgYWxs DQpjb25mdXNpb25zIGFyZSBhZGRyZXNzZWQgYW5kIGFsbCBjYXNlcyBjb3ZlcmVkIHdpdGhvdXQg YW55IG5lZWQgZm9yIHByb3RvY29sDQpleHRlbnNpb24uDQoNClRob3VnaHRzID8NCg0KVGh4LA0K Ui4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGll dGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkcg0K From jie.dong@huawei.com Tue Aug 16 20:13:16 2011 Return-Path: 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 5D3C121F8829 for ; Tue, 16 Aug 2011 20:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 VhXa62hrZY0i for ; Tue, 16 Aug 2011 20:13:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 71C8121F8853 for ; Tue, 16 Aug 2011 20:13:15 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ1008KMYBF43@szxga03-in.huawei.com> for idr@ietf.org; Wed, 17 Aug 2011 11:14:03 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ100F3GYBF09@szxga03-in.huawei.com> for idr@ietf.org; Wed, 17 Aug 2011 11:14:03 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADF96976; Wed, 17 Aug 2011 11:14:02 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 11:13:56 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.150]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 11:13:58 +0800 Date: Wed, 17 Aug 2011 03:13:56 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.110.98.148] To: Jakob Heitz , Cayle Spandon Message-id: <76CD132C3ADEF848BD84D028D243C9270B778C9D@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AQHMXCAZ8rM7umfJk0uaJkw7keJ+3JUgTaAg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 03:13:16 -0000 Hi Jakob, One could use BGP GR for graceful session reset. 1) If the speaker which performs GR session reset knows its peer would perform GR receiving speaker procedure, it would keep forwarding states with stale routes when the session is reset and update the forwarding state when GR is finished. 2) If the speaker which performs session reset knows its peer would not perform GR helper procedure, when the session resets it would immediately withdraw all the routes received from that peer and update forwarding states. So if the speaker which performs session reset does not know whether its peer supports GR helper mode or not , it would first keep stale routes in forwarding table for a while, then it would fail to finish GR and withdraw that peer's routes and update the forwarding table with routes from other peers. This could consume more resources and may impact the data traffic. Besides, if operator knows whether one BGP peer support GR helper or not, it may choose different mechanisms for maintenance. Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Jakob Heitz > Sent: Tuesday, August 16, 2011 10:24 PM > To: Cayle Spandon > Cc: idr@ietf.org > Subject: Re: [Idr] Solicit feedbacks on > draft-dong-idr-end-of-rib-use-extension > > Again: > > When a BGP speaker advertises the GR capability without > including any 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. > > Can you state a use case where the difference matters? > > -- > Jakob Heitz. > > > On Aug 16, 2011, at 4:32 AM, "Cayle Spandon" > > wrote: > > I think it is fair to say that everyone agrees that EoR makes sense > without GR. > > With 20/20 hindsight, it would probably have been "cleaner" to define > a separate capability for EoR and GR. > > But we have to play the cards we have been dealt, and at this point I > can sympathize with the position that clarifying/tweaking the existing > specs would minimize churn and confusion. > > (That said, I would not object to "doing the right thing from an > architecture point of view" and creating a new EoR capability even > though doing so would create a new set of confusions on how the new > EoR capability would interact with the existing GR capability.) > > Regardless of what we decide to do (tweak GR capability or add EoR > capability) I think that the following 3 problems need to fixed: > > 1. There must be a way of negotiating EoR in such a way that the > receiver can be 100% certain that it will receive an EoR at the end of > initial convergence. As pointed out by earlier posters, there are some > inconsistencies in the current GR spec which cause it to be unclear > (for certain scenarios, notably when is included) whether > an EOR should be sent after initial convergence. > > 2. It is not sufficient to simply clarify the language in a respin of > the GR spec without any protocol changes. If we did that, the receiver > of a GR capability would have no way to know 100% sure that the remote > side intends to send an EoR after initial convergence (because it > doesn't know whether the remote side was implemented before or after > the "clarifications"). Thus, we need to add "something" (either a new > flag in the existing GR capability to a new EoR capability) which > conveys to the other side: "I guarantee that I will send EoR after > initial convergence". > > 3. We also need to clarify the behavior for router-refresh. In my > opinion it would be good to also indicate end-of-route-refresh with an > EoR (or similar) message. > > -- Bruno > > PS to muddle the waters some more: If we do end up going down the path > of a new EoR capability, then I would suggest that the authors of > draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could > be enhanced to include SoR (Start-of-RIB) as well which would cover > the need for start-of-route-refresh and end-of-route-refresh. > > On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk > > wrote: > Hi Jie, > > It's good that we agree on this scenario. IMO now GR capability with > null AFI/SAFI is for signaling "GR helper and EoR". > > I would not agree with that. It is in fact just the opposite. > > If we want to use it to signal EoR only, we may need another way to > > signal the GR helper capability. > > + > > IMO the two scenarios mentioned in sec 4 cannot be signaled > separately through one single capability format. Thus some additional > flag needs be defined > > While I did suggested the addition of flag after rethinking this a bit more > I do not think it is necessary. > > Here is my idea: > > -- > > * When you signal GR capability with null AFI/SAFI list - it just means use > of EOR - it does not mean you support helper mode. > > * When you signal GR capability with non-null AFI/SAFI (at least one > AFI/SAFI included) - it will mean use of EOR, helper mode support + GR > support for this/those AFI/SAFIs. > > -- > > If the GR RFC will clarify that to reflect such semantics I think all > confusions are addressed and all cases covered without any need for > protocol > extension. > > Thoughts ? > > Thx, > R. > > > _______________________________________________ > 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Wed Aug 17 11:36:07 2011 Return-Path: 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 1E57611E809C; Wed, 17 Aug 2011 11:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 r9pM0VEiuC1R; Wed, 17 Aug 2011 11:36:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3A21F8B61; Wed, 17 Aug 2011 11:36:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 11:36:06 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:36:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Bestpath Selection Criteria Enhancement Author(s) : Rajiv Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Pages : 9 Date : 2011-08-17 BGP specification [RFC4271] prescribes 'BGP next-hop reachability= 9; as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition&q= uot; to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-c= riteria-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-cr= iteria-04.txt From samita.chakrabarti@ericsson.com Wed Aug 17 13:50:12 2011 Return-Path: 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 64C8611E8089 for ; Wed, 17 Aug 2011 13:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, 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 82nx4AtK4kcB for ; Wed, 17 Aug 2011 13:50:11 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B569611E8082 for ; Wed, 17 Aug 2011 13:50:11 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p7HKoqjn023667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Aug 2011 15:51:03 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.182]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 17 Aug 2011 16:50:55 -0400 From: Samita Chakrabarti To: "rajiva@cisco.com" Date: Wed, 17 Aug 2011 16:50:53 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxdDKw2umOTOePlTiaBbsbfU3xTtQAD9Jdg Message-ID: <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> In-Reply-To: <20110817183606.4053.38107.idtracker@ietfa.amsl.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" Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:50:12 -0000 Hi Rajiv, This is a good work clarifying the path-availability check in BGP path sele= ction. Is this document supposed to update RFC 4271 section 9.1.2 in general? I wonder, if you have any data or thoughts on whether the additonal check a= t the data-plane level will add any latency in BGP path selection process a= nd thus have any effect on convergence? A short paragraph on the impact on timing might be useful for implementors = as it seems running BFD or any other mechanism to keep an up-to-date inform= ation of path-availability at the data-plane will avoid any delay in the pa= th selection process. -Samita -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Wednesday, August 17, 2011 11:36 AM To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-0= 4.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Bestpath Selection Criteria Enhancement Author(s) : Rajiv Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Pages : 9 Date : 2011-08-17 BGP specification [RFC4271] prescribes 'BGP next-hop reachability= 9; as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition&q= uot; to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-c= riteria-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-cr= iteria-04.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed Aug 17 15:42:38 2011 Return-Path: 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 C3BE111E8095 for ; Wed, 17 Aug 2011 15:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599] 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 L0UY4tnpOCKk for ; Wed, 17 Aug 2011 15:42:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 24DD211E8090 for ; Wed, 17 Aug 2011 15:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1259; q=dns/txt; s=iport; t=1313621010; x=1314830610; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WBpu263LSDSrDR4F+klefNXs5M89IVnIT4Za5axGyb0=; b=DA8W1nhEIv0nJJ65eZegwMmqpNqqthyRKBn2AOZn6bItZ/D0Hrb+Y1wn bMOJF+uEYe1kt8yLkkIMYQZ509tEt2nLM/qZnkMW8f/209agY+hn+1+Es 8VxJsxwkmubYadFWIwNCzhAy+2f0LW9SvOak70Xx4fWjE4lLOAlkOxVnF M=; X-IronPort-AV: E=Sophos;i="4.68,242,1312156800"; d="scan'208";a="14125981" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 17 Aug 2011 22:43:30 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7HMhSTS027047; Wed, 17 Aug 2011 22:43:29 GMT Message-ID: <4E4C4438.2090702@cisco.com> Date: Thu, 18 Aug 2011 00:44:08 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Samita Chakrabarti References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 22:42:38 -0000 Hi Samita, Allow me to make an observation that today BGP already validates reachability to next hops, before considering path with such next hop to be valid and to be eligible for best path selection. In the light of the above Rajiv's proposal does not introduce any additional delay nor does it cause any impact on "bgp convergence". The only place which changes for some applications of BGP is the place where you validate such next hop liveness/reachabilty. And as this is very implementation dependent I think we should not discuss those aspects on this mailing list. Best regards, R. > Hi Rajiv, > > This is a good work clarifying the path-availability check in BGP > path selection. Is this document supposed to update RFC 4271 section > 9.1.2 in general? I wonder, if you have any data or thoughts on > whether the additonal check at the data-plane level will add any > latency in BGP path selection process and thus have any effect on > convergence? A short paragraph on the impact on timing might be > useful for implementors as it seems running BFD or any other > mechanism to keep an up-to-date information of path-availability at > the data-plane will avoid any delay in the path selection process. > > -Samita From cayle.spandon@gmail.com Thu Aug 18 04:42:58 2011 Return-Path: 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 3EDBF21F88B6 for ; Thu, 18 Aug 2011 04:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PY+s6KRL62Rg for ; Thu, 18 Aug 2011 04:42:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D519321F8888 for ; Thu, 18 Aug 2011 04:42:56 -0700 (PDT) Received: by wyg8 with SMTP id 8so1552493wyg.31 for ; Thu, 18 Aug 2011 04:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IxX6LQOqTU/Nm9+LKoeGuNkqnCI62/Sz+XzJEoBbdf8=; b=rAH6ysYrnwB/tICHtGqTNEca5TOEX6WjJ4oWHOgK+iZNIoLrSrE4OSfMXGgmSu2rbj 7SIfcVs+c6Xw2Wvtog0/+nRgdnW3zvaSQxu/JWSo899bJgllJTMfQ8jyvHM1SYiWD+sq YoHSkql4hPF2lGntbPhvQL8c33MsVee+prxec= MIME-Version: 1.0 Received: by 10.216.233.7 with SMTP id o7mr541518weq.7.1313667828595; Thu, 18 Aug 2011 04:43:48 -0700 (PDT) Received: by 10.216.170.71 with HTTP; Thu, 18 Aug 2011 04:43:48 -0700 (PDT) In-Reply-To: References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> Date: Thu, 18 Aug 2011 07:43:48 -0400 Message-ID: From: Cayle Spandon To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:42:58 -0000 Jakob Heitz> When a BGP speaker advertises the GR capability without Jakob Heitz> including any it is saying to the peer: Jakob Heitz> I will send an EOR when my initial update is complete and Jakob Heitz> I MAY retain your routes when you restart. Jakob Heitz> When a BGP speaker advertises your extension, Jakob Heitz> it is saying to the peer: Jakob Heitz> I will send an EOR when my initial update is complete and Jakob Heitz> I WILL NOT retain your routes when you restart. One nitpick (not relevant to the discussion at hand): if we have a new separate EoR capability, sending it would not make any statement about whether or not router are retained after a restart. That would be an orthogonal issue handled by the GR capability. Jakob Heitz> Can you state a use case where the difference matters? I see your point, which is (I think) that we can use the existing GR capability without an to advertise "I will (a MUST) send an EoR after initial convergence". I believe there is a problem with this approach. Let's say that a BGP speaker wants to announce the following: (a) I am able to preserve forwarding state for during a restart. This requires sending a GR capability with . (b) I will (a MUST) send an EoR after initial convergence. This requires sending a GR capability without an . Since a single GR capability cannot have and not have an at the same time, this would require sending two separate GR capabilities in a single OPEN message (one GR cap with one or more and one GR cap without). This is explicitly forbidden in the 2nd to last paragraph of section 3 of RFC 4724. On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz wrote: > Again: > > When a BGP speaker advertises the GR capability without > including any 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. > > Can you state a use case where the difference matters? > > -- > Jakob Heitz. > > > On Aug 16, 2011, at 4:32 AM, "Cayle Spandon" > wrote: > > I think it is fair to say that everyone agrees that EoR makes sense > without GR. > > With 20/20 hindsight, it would probably have been "cleaner" to define > a separate capability for EoR and GR. > > But we have to play the cards we have been dealt, and at this point I > can sympathize with the position that clarifying/tweaking the existing > specs would minimize churn and confusion. > > (That said, I would not object to "doing the right thing from an > architecture point of view" and creating a new EoR capability even > though doing so would create a new set of confusions on how the new > EoR capability would interact with the existing GR capability.) > > Regardless of what we decide to do (tweak GR capability or add EoR > capability) I think that the following 3 problems need to fixed: > > 1. There must be a way of negotiating EoR in such a way that the > receiver can be 100% certain that it will receive an EoR at the end of > initial convergence. As pointed out by earlier posters, there are some > inconsistencies in the current GR spec which cause it to be unclear > (for certain scenarios, notably when is included) whether > an EOR should be sent after initial convergence. > > 2. It is not sufficient to simply clarify the language in a respin of > the GR spec without any protocol changes. If we did that, the receiver > of a GR capability would have no way to know 100% sure that the remote > side intends to send an EoR after initial convergence (because it > doesn't know whether the remote side was implemented before or after > the "clarifications"). Thus, we need to add "something" (either a new > flag in the existing GR capability to a new EoR capability) which > conveys to the other side: "I guarantee that I will send EoR after > initial convergence". > > 3. We also need to clarify the behavior for router-refresh. In my > opinion it would be good to also indicate end-of-route-refresh with an > EoR (or similar) message. > > -- Bruno > > PS to muddle the waters some more: If we do end up going down the path > of a new EoR capability, then I would suggest that the authors of > draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could > be enhanced to include SoR (Start-of-RIB) as well which would cover > the need for start-of-route-refresh and end-of-route-refresh. > > On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk > wrote: > Hi Jie, > > It's good that we agree on this scenario. IMO now GR capability with > null AFI/SAFI is for signaling "GR helper and EoR". > > I would not agree with that. It is in fact just the opposite. > > If we want to use it to signal EoR only, we may need another way to > > signal the GR helper capability. > > + > > IMO the two scenarios mentioned in sec 4 cannot be signaled > separately through one single capability format. Thus some additional > flag needs be defined > > While I did suggested the addition of flag after rethinking this a bit more > I do not think it is necessary. > > Here is my idea: > > -- > > * When you signal GR capability with null AFI/SAFI list - it just means use > of EOR - it does not mean you support helper mode. > > * When you signal GR capability with non-null AFI/SAFI (at least one > AFI/SAFI included) - it will mean use of EOR, helper mode support + GR > support for this/those AFI/SAFIs. > > -- > > If the GR RFC will clarify that to reflect such semantics I think all > confusions are addressed and all cases covered without any need for protocol > extension. > > Thoughts ? > > Thx, > R. > > > _______________________________________________ > 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 > From raszuk@cisco.com Thu Aug 18 07:43:29 2011 Return-Path: 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 141E521F8B71 for ; Thu, 18 Aug 2011 07:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=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 NmnWPt6o6P-9 for ; Thu, 18 Aug 2011 07:43:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2B21F8B6C for ; Thu, 18 Aug 2011 07:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=7189; q=dns/txt; s=iport; t=1313678662; x=1314888262; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oWy/DJUY2Toy/sTe/FvXXPl21C0oGcurXMBAQKwPg9c=; b=JKaKtykgYTtNQzlRgOxwXXlhq/tfG7fji+4xaB8ILuMqQQk0jSqbm2bT cHlIKa98Jlug9AugdNV8wk7+4ZpgNe0uySqEfTcyyFXREk/6rOzmN0AYp yHm9neeWjF8BzgO3NIfoOMg7hx/rGtkCLXM7ZZs55nRsOhcBgUorD847s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADYkTU6rRDoI/2dsb2JhbABCqHJ3gTkHAQEBAQIBAQEBDwECASI2CgEFCwsSBgkWCAcJAwIBAgEPBh8DDgYNAQUCAQEeh08EmkwBgyYPAZtYhkgEkxOFDIRqhwE X-IronPort-AV: E=Sophos;i="4.68,245,1312156800"; d="scan'208";a="14349308" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 18 Aug 2011 14:44:21 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7IEiJhE031219; Thu, 18 Aug 2011 14:44:20 GMT Message-ID: <4E4D2533.7020604@cisco.com> Date: Thu, 18 Aug 2011 16:44:03 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Cayle Spandon References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> In-Reply-To: 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 Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:43:29 -0000 Hi, > (a) I am able to preserve forwarding state for during a > restart. This requires sending a GR capability with . > > (b) I will (a MUST) send an EoR after initial convergence. This > requires sending a GR capability without an . Sending GR capability with also means that EOR is mandatory (a MUST). So I do not think I see a problem in your particular example. Best regards, R. > Jakob Heitz> When a BGP speaker advertises the GR capability without > Jakob Heitz> including any it is saying to the peer: > Jakob Heitz> I will send an EOR when my initial update is complete and > Jakob Heitz> I MAY retain your routes when you restart. > > Jakob Heitz> When a BGP speaker advertises your extension, > Jakob Heitz> it is saying to the peer: > Jakob Heitz> I will send an EOR when my initial update is complete and > Jakob Heitz> I WILL NOT retain your routes when you restart. > > One nitpick (not relevant to the discussion at hand): if we have a new > separate EoR capability, sending it would not make any statement about > whether or not router are retained after a restart. That would be an > orthogonal issue handled by the GR capability. > > Jakob Heitz> Can you state a use case where the difference matters? > > I see your point, which is (I think) that we can use the existing GR > capability without an to advertise "I will (a MUST) send an > EoR after initial convergence". > > I believe there is a problem with this approach. > > Let's say that a BGP speaker wants to announce the following: > > (a) I am able to preserve forwarding state for during a > restart. This requires sending a GR capability with. > > (b) I will (a MUST) send an EoR after initial convergence. This > requires sending a GR capability without an. > > Since a single GR capability cannot have and not have an at > the same time, this would require sending two separate GR capabilities > in a single OPEN message (one GR cap with one or more and > one GR cap without). > > This is explicitly forbidden in the 2nd to last paragraph of section 3 > of RFC 4724. > > On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz wrote: >> Again: >> >> When a BGP speaker advertises the GR capability without >> including any 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. >> >> Can you state a use case where the difference matters? >> >> -- >> Jakob Heitz. >> >> >> On Aug 16, 2011, at 4:32 AM, "Cayle Spandon"> wrote: >> >> I think it is fair to say that everyone agrees that EoR makes sense >> without GR. >> >> With 20/20 hindsight, it would probably have been "cleaner" to define >> a separate capability for EoR and GR. >> >> But we have to play the cards we have been dealt, and at this point I >> can sympathize with the position that clarifying/tweaking the existing >> specs would minimize churn and confusion. >> >> (That said, I would not object to "doing the right thing from an >> architecture point of view" and creating a new EoR capability even >> though doing so would create a new set of confusions on how the new >> EoR capability would interact with the existing GR capability.) >> >> Regardless of what we decide to do (tweak GR capability or add EoR >> capability) I think that the following 3 problems need to fixed: >> >> 1. There must be a way of negotiating EoR in such a way that the >> receiver can be 100% certain that it will receive an EoR at the end of >> initial convergence. As pointed out by earlier posters, there are some >> inconsistencies in the current GR spec which cause it to be unclear >> (for certain scenarios, notably when is included) whether >> an EOR should be sent after initial convergence. >> >> 2. It is not sufficient to simply clarify the language in a respin of >> the GR spec without any protocol changes. If we did that, the receiver >> of a GR capability would have no way to know 100% sure that the remote >> side intends to send an EoR after initial convergence (because it >> doesn't know whether the remote side was implemented before or after >> the "clarifications"). Thus, we need to add "something" (either a new >> flag in the existing GR capability to a new EoR capability) which >> conveys to the other side: "I guarantee that I will send EoR after >> initial convergence". >> >> 3. We also need to clarify the behavior for router-refresh. In my >> opinion it would be good to also indicate end-of-route-refresh with an >> EoR (or similar) message. >> >> -- Bruno >> >> PS to muddle the waters some more: If we do end up going down the path >> of a new EoR capability, then I would suggest that the authors of >> draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could >> be enhanced to include SoR (Start-of-RIB) as well which would cover >> the need for start-of-route-refresh and end-of-route-refresh. >> >> On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk> wrote: >> Hi Jie, >> >> It's good that we agree on this scenario. IMO now GR capability with >> null AFI/SAFI is for signaling "GR helper and EoR". >> >> I would not agree with that. It is in fact just the opposite. >> >> If we want to use it to signal EoR only, we may need another way to >> >> signal the GR helper capability. >> >> + >> >> IMO the two scenarios mentioned in sec 4 cannot be signaled >> separately through one single capability format. Thus some additional >> flag needs be defined >> >> While I did suggested the addition of flag after rethinking this a bit more >> I do not think it is necessary. >> >> Here is my idea: >> >> -- >> >> * When you signal GR capability with null AFI/SAFI list - it just means use >> of EOR - it does not mean you support helper mode. >> >> * When you signal GR capability with non-null AFI/SAFI (at least one >> AFI/SAFI included) - it will mean use of EOR, helper mode support + GR >> support for this/those AFI/SAFIs. >> >> -- >> >> If the GR RFC will clarify that to reflect such semantics I think all >> confusions are addressed and all cases covered without any need for protocol >> extension. >> >> Thoughts ? >> >> Thx, >> R. >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Thu Aug 18 10:40:16 2011 Return-Path: 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 2A61B11E80B3 for ; Thu, 18 Aug 2011 10:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, 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 jWXPv4q8xIYc for ; Thu, 18 Aug 2011 10:40:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4990B11E8095 for ; Thu, 18 Aug 2011 10:40:15 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7IHf5xe025629; Thu, 18 Aug 2011 12:41:08 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.94]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 18 Aug 2011 13:41:06 -0400 From: Jakob Heitz To: Cayle Spandon Date: Thu, 18 Aug 2011 13:41:04 -0400 Thread-Topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-Index: AcxdnCBtxb52T2iiTaK7pXuVB9uGFAAMS5Xw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A21EFA3E@EUSAACMS0701.eamcs.ericsson.se> References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:40:16 -0000 I think I can see a use case. A BGP speaker wants to tell its neighbors: If the BGP session to me goes down, you MUST immediately remove the routes that I advertised to you, AND when I have completed my initial update to you, I will send you an EOR. -- Jakob Heitz. =20 > -----Original Message----- > From: Cayle Spandon [mailto:cayle.spandon@gmail.com]=20 > Sent: Thursday, August 18, 2011 4:44 AM > To: Jakob Heitz > Cc: idr@ietf.org > Subject: Re: [Idr] Solicit feedbacks on=20 > draft-dong-idr-end-of-rib-use-extension >=20 > Jakob Heitz> When a BGP speaker advertises the GR capability without > Jakob Heitz> including any it is saying to the peer: > Jakob Heitz> I will send an EOR when my initial update is complete and > Jakob Heitz> I MAY retain your routes when you restart. >=20 > Jakob Heitz> When a BGP speaker advertises your extension, > Jakob Heitz> it is saying to the peer: > Jakob Heitz> I will send an EOR when my initial update is complete and > Jakob Heitz> I WILL NOT retain your routes when you restart. >=20 > One nitpick (not relevant to the discussion at hand): if we have a new > separate EoR capability, sending it would not make any statement about > whether or not router are retained after a restart. That would be an > orthogonal issue handled by the GR capability. >=20 > Jakob Heitz> Can you state a use case where the difference matters? >=20 > I see your point, which is (I think) that we can use the existing GR > capability without an to advertise "I will (a MUST) send an > EoR after initial convergence". >=20 > I believe there is a problem with this approach. >=20 > Let's say that a BGP speaker wants to announce the following: >=20 > (a) I am able to preserve forwarding state for during a > restart. This requires sending a GR capability with . >=20 > (b) I will (a MUST) send an EoR after initial convergence. This > requires sending a GR capability without an . >=20 > Since a single GR capability cannot have and not have an at > the same time, this would require sending two separate GR capabilities > in a single OPEN message (one GR cap with one or more and > one GR cap without). >=20 > This is explicitly forbidden in the 2nd to last paragraph of section 3 > of RFC 4724. >=20 > On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz=20 > wrote: > > Again: > > > > When a BGP speaker advertises the GR capability without > > including any 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. > > > > Can you state a use case where the difference matters? > > > > -- > > Jakob Heitz. > > > > > > On Aug 16, 2011, at 4:32 AM, "Cayle Spandon"=20 > > wrote: > > > > I think it is fair to say that everyone agrees that EoR makes sense > > without GR. > > > > With 20/20 hindsight, it would probably have been "cleaner"=20 > to define > > a separate capability for EoR and GR. > > > > But we have to play the cards we have been dealt, and at=20 > this point I > > can sympathize with the position that clarifying/tweaking=20 > the existing > > specs would minimize churn and confusion. > > > > (That said, I would not object to "doing the right thing from an > > architecture point of view" and creating a new EoR capability even > > though doing so would create a new set of confusions on how the new > > EoR capability would interact with the existing GR capability.) > > > > Regardless of what we decide to do (tweak GR capability or add EoR > > capability) I think that the following 3 problems need to fixed: > > > > 1. There must be a way of negotiating EoR in such a way that the > > receiver can be 100% certain that it will receive an EoR at=20 > the end of > > initial convergence. As pointed out by earlier posters,=20 > there are some > > inconsistencies in the current GR spec which cause it to be unclear > > (for certain scenarios, notably when is included) whether > > an EOR should be sent after initial convergence. > > > > 2. It is not sufficient to simply clarify the language in a=20 > respin of > > the GR spec without any protocol changes. If we did that,=20 > the receiver > > of a GR capability would have no way to know 100% sure that=20 > the remote > > side intends to send an EoR after initial convergence (because it > > doesn't know whether the remote side was implemented before or after > > the "clarifications"). Thus, we need to add "something"=20 > (either a new > > flag in the existing GR capability to a new EoR capability) which > > conveys to the other side: "I guarantee that I will send EoR after > > initial convergence". > > > > 3. We also need to clarify the behavior for router-refresh. In my > > opinion it would be good to also indicate=20 > end-of-route-refresh with an > > EoR (or similar) message. > > > > -- Bruno > > > > PS to muddle the waters some more: If we do end up going=20 > down the path > > of a new EoR capability, then I would suggest that the authors of > > draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could > > be enhanced to include SoR (Start-of-RIB) as well which would cover > > the need for start-of-route-refresh and end-of-route-refresh. > > > > On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk=20 > > wrote: > > Hi Jie, > > > > It's good that we agree on this scenario. IMO now GR capability with > > null AFI/SAFI is for signaling "GR helper and EoR". > > > > I would not agree with that. It is in fact just the opposite. > > > > If we want to use it to signal EoR only, we may need another way to > > > > signal the GR helper capability. > > > > + > > > > IMO the two scenarios mentioned in sec 4 cannot be signaled > > separately through one single capability format. Thus some=20 > additional > > flag needs be defined > > > > While I did suggested the addition of flag after rethinking=20 > this a bit more > > I do not think it is necessary. > > > > Here is my idea: > > > > -- > > > > * When you signal GR capability with null AFI/SAFI list -=20 > it just means use > > of EOR - it does not mean you support helper mode. > > > > * When you signal GR capability with non-null AFI/SAFI (at least one > > AFI/SAFI included) - it will mean use of EOR, helper mode=20 > support + GR > > support for this/those AFI/SAFIs. > > > > -- > > > > If the GR RFC will clarify that to reflect such semantics I=20 > think all > > confusions are addressed and all cases covered without any=20 > need for protocol > > extension. > > > > Thoughts ? > > > > Thx, > > R. > > > > > > _______________________________________________ > > 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 > > > = From jie.dong@huawei.com Fri Aug 19 01:50:32 2011 Return-Path: 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 C930B21F8797 for ; Fri, 19 Aug 2011 01:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 BPW0Acn+BfZ6 for ; Fri, 19 Aug 2011 01:50:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D04D021F8783 for ; Fri, 19 Aug 2011 01:50:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ600B6039I7X@szxga03-in.huawei.com> for idr@ietf.org; Fri, 19 Aug 2011 16:51:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ600KCF37WAW@szxga03-in.huawei.com> for idr@ietf.org; Fri, 19 Aug 2011 16:51:18 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH88078; Fri, 19 Aug 2011 16:51:17 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 16:51:08 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.150]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Fri, 19 Aug 2011 16:51:17 +0800 Date: Fri, 19 Aug 2011 08:51:15 +0000 From: Jie Dong In-reply-to: <7309FCBCAE981B43ABBE69B31C8D213914A21EFA3E@EUSAACMS0701.eamcs.ericsson.se> X-Originating-IP: [10.110.98.148] To: Jakob Heitz , Cayle Spandon Message-id: <76CD132C3ADEF848BD84D028D243C9270B779BA4@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension Thread-index: AQHMXc4tT3yYQFR8t0mA5TvMo0VnWZUj3HFg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com> <4E4186ED.4070001@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76B7A0@szxeml509-mbs.china.huawei.com> <4E431244.5050206@cisco.com> <76CD132C3ADEF848BD84D028D243C9270B76BE40@szxeml509-mbs.china.huawei.com> <4E43D60C.3000906@cisco.com> <7309FCBCAE981B43ABBE69B31C8D213914A21EFA3E@EUSAACMS0701.eamcs.ericsson.se> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 08:50:32 -0000 Hi Jakob, That's also what I wanted to describe in my previous mail, thanks for your summarization. This is the case to let peers know this speaker "would only send EOR for initial route update and would not behave as GR helper". Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Jakob Heitz > Sent: Friday, August 19, 2011 1:41 AM > To: Cayle Spandon > Cc: idr@ietf.org > Subject: Re: [Idr] Solicit feedbacks on > draft-dong-idr-end-of-rib-use-extension > > I think I can see a use case. > A BGP speaker wants to tell its neighbors: > > If the BGP session to me goes down, you MUST immediately > remove the routes that I advertised to you, > AND > when I have completed my initial update to you, > I will send you an EOR. > > -- > Jakob Heitz. > > > > -----Original Message----- > > From: Cayle Spandon [mailto:cayle.spandon@gmail.com] > > Sent: Thursday, August 18, 2011 4:44 AM > > To: Jakob Heitz > > Cc: idr@ietf.org > > Subject: Re: [Idr] Solicit feedbacks on > > draft-dong-idr-end-of-rib-use-extension > > > > Jakob Heitz> When a BGP speaker advertises the GR capability without > > Jakob Heitz> including any it is saying to the peer: > > Jakob Heitz> I will send an EOR when my initial update is complete and > > Jakob Heitz> I MAY retain your routes when you restart. > > > > Jakob Heitz> When a BGP speaker advertises your extension, > > Jakob Heitz> it is saying to the peer: > > Jakob Heitz> I will send an EOR when my initial update is complete and > > Jakob Heitz> I WILL NOT retain your routes when you restart. > > > > One nitpick (not relevant to the discussion at hand): if we have a new > > separate EoR capability, sending it would not make any statement about > > whether or not router are retained after a restart. That would be an > > orthogonal issue handled by the GR capability. > > > > Jakob Heitz> Can you state a use case where the difference matters? > > > > I see your point, which is (I think) that we can use the existing GR > > capability without an to advertise "I will (a MUST) send an > > EoR after initial convergence". > > > > I believe there is a problem with this approach. > > > > Let's say that a BGP speaker wants to announce the following: > > > > (a) I am able to preserve forwarding state for during a > > restart. This requires sending a GR capability with . > > > > (b) I will (a MUST) send an EoR after initial convergence. This > > requires sending a GR capability without an . > > > > Since a single GR capability cannot have and not have an at > > the same time, this would require sending two separate GR capabilities > > in a single OPEN message (one GR cap with one or more and > > one GR cap without). > > > > This is explicitly forbidden in the 2nd to last paragraph of section 3 > > of RFC 4724. > > > > On Tue, Aug 16, 2011 at 10:23 AM, Jakob Heitz > > wrote: > > > Again: > > > > > > When a BGP speaker advertises the GR capability without > > > including any 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. > > > > > > Can you state a use case where the difference matters? > > > > > > -- > > > Jakob Heitz. > > > > > > > > > On Aug 16, 2011, at 4:32 AM, "Cayle Spandon" > > > wrote: > > > > > > I think it is fair to say that everyone agrees that EoR makes sense > > > without GR. > > > > > > With 20/20 hindsight, it would probably have been "cleaner" > > to define > > > a separate capability for EoR and GR. > > > > > > But we have to play the cards we have been dealt, and at > > this point I > > > can sympathize with the position that clarifying/tweaking > > the existing > > > specs would minimize churn and confusion. > > > > > > (That said, I would not object to "doing the right thing from an > > > architecture point of view" and creating a new EoR capability even > > > though doing so would create a new set of confusions on how the new > > > EoR capability would interact with the existing GR capability.) > > > > > > Regardless of what we decide to do (tweak GR capability or add EoR > > > capability) I think that the following 3 problems need to fixed: > > > > > > 1. There must be a way of negotiating EoR in such a way that the > > > receiver can be 100% certain that it will receive an EoR at > > the end of > > > initial convergence. As pointed out by earlier posters, > > there are some > > > inconsistencies in the current GR spec which cause it to be unclear > > > (for certain scenarios, notably when is included) whether > > > an EOR should be sent after initial convergence. > > > > > > 2. It is not sufficient to simply clarify the language in a > > respin of > > > the GR spec without any protocol changes. If we did that, > > the receiver > > > of a GR capability would have no way to know 100% sure that > > the remote > > > side intends to send an EoR after initial convergence (because it > > > doesn't know whether the remote side was implemented before or > after > > > the "clarifications"). Thus, we need to add "something" > > (either a new > > > flag in the existing GR capability to a new EoR capability) which > > > conveys to the other side: "I guarantee that I will send EoR after > > > initial convergence". > > > > > > 3. We also need to clarify the behavior for router-refresh. In my > > > opinion it would be good to also indicate > > end-of-route-refresh with an > > > EoR (or similar) message. > > > > > > -- Bruno > > > > > > PS to muddle the waters some more: If we do end up going > > down the path > > > of a new EoR capability, then I would suggest that the authors of > > > draft-ietf-idr-bgp-enhanced-route-refresh join the effort; EoR could > > > be enhanced to include SoR (Start-of-RIB) as well which would cover > > > the need for start-of-route-refresh and end-of-route-refresh. > > > > > > On Thu, Aug 11, 2011 at 9:15 AM, Robert Raszuk > > > wrote: > > > Hi Jie, > > > > > > It's good that we agree on this scenario. IMO now GR capability with > > > null AFI/SAFI is for signaling "GR helper and EoR". > > > > > > I would not agree with that. It is in fact just the opposite. > > > > > > If we want to use it to signal EoR only, we may need another way to > > > > > > signal the GR helper capability. > > > > > > + > > > > > > IMO the two scenarios mentioned in sec 4 cannot be signaled > > > separately through one single capability format. Thus some > > additional > > > flag needs be defined > > > > > > While I did suggested the addition of flag after rethinking > > this a bit more > > > I do not think it is necessary. > > > > > > Here is my idea: > > > > > > -- > > > > > > * When you signal GR capability with null AFI/SAFI list - > > it just means use > > > of EOR - it does not mean you support helper mode. > > > > > > * When you signal GR capability with non-null AFI/SAFI (at least one > > > AFI/SAFI included) - it will mean use of EOR, helper mode > > support + GR > > > support for this/those AFI/SAFIs. > > > > > > -- > > > > > > If the GR RFC will clarify that to reflect such semantics I > > think all > > > confusions are addressed and all cases covered without any > > need for protocol > > > extension. > > > > > > Thoughts ? > > > > > > Thx, > > > R. > > > > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rajiva@cisco.com Fri Aug 19 12:10:27 2011 Return-Path: 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 20DE221F8B7C for ; Fri, 19 Aug 2011 12:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] 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 WlCoPtRw9mAA for ; Fri, 19 Aug 2011 12:10:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A4DAE21F8B78 for ; Fri, 19 Aug 2011 12:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1677; q=dns/txt; s=iport; t=1313781082; x=1314990682; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uIFd5fI5D5UjK8yu+1IJXcF3WpZLrhHlwOG+tg8gEIk=; b=U6VBn0d34fZ7+YopSdZnLBGFsHWx2f8V6pvBJtKk8EZuYD3y1xXfhgmn bg0X2duqqu95kyTxdwTf9GWvps/W1cHonf3TodrGGmeUCoPsQIIOVv2EJ PhGU1Ab/pJ8gy2QlpQA9ftSs6U09L3Fkg0s2JhaQSmgGlQBauWX52Y5wC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUAAOC0Tk6tJXHB/2dsb2JhbABBmCyPYXeBQAEBAQEDEgEdCjQLDAQCAQgRBAEBCwYYBgFOCAEBBAESCBqhTwGec4VpXwSHYJBIi34 X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="14784621" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 19 Aug 2011 19:11:20 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7JJBKKh004061; Fri, 19 Aug 2011 19:11:20 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Aug 2011 14:11:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2011 14:11:18 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> In-Reply-To: <4E4C4438.2090702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxdLxZwRlVcsgt/SdePE1crIJ8c9gBVYSUw References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> From: "Rajiv Asati (rajiva)" To: "Robert Raszuk (raszuk)" , "Samita Chakrabarti" X-OriginalArrivalTime: 19 Aug 2011 19:11:19.0812 (UTC) FILETIME=[C6FE0C40:01CC5EA3] Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:10:27 -0000 Samita, No additional latency expected. Thanks. Cheers, Rajiv > -----Original Message----- > From: Robert Raszuk (raszuk) > Sent: Wednesday, August 17, 2011 6:44 PM > To: Samita Chakrabarti > Cc: Rajiv Asati (rajiva); idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria- > 04.txt >=20 > Hi Samita, >=20 > Allow me to make an observation that today BGP already validates > reachability to next hops, before considering path with such next hop to > be valid and to be eligible for best path selection. >=20 > In the light of the above Rajiv's proposal does not introduce any > additional delay nor does it cause any impact on "bgp convergence". >=20 > The only place which changes for some applications of BGP is the place > where you validate such next hop liveness/reachabilty. And as this is > very implementation dependent I think we should not discuss those > aspects on this mailing list. >=20 > Best regards, > R. >=20 > > Hi Rajiv, > > > > This is a good work clarifying the path-availability check in BGP > > path selection. Is this document supposed to update RFC 4271 section > > 9.1.2 in general? I wonder, if you have any data or thoughts on > > whether the additonal check at the data-plane level will add any > > latency in BGP path selection process and thus have any effect on > > convergence? A short paragraph on the impact on timing might be > > useful for implementors as it seems running BFD or any other > > mechanism to keep an up-to-date information of path-availability at > > the data-plane will avoid any delay in the path selection process. > > > > -Samita From samita.chakrabarti@ericsson.com Fri Aug 19 12:20:49 2011 Return-Path: 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 0521811E8089 for ; Fri, 19 Aug 2011 12:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, 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 TKIYzWzYYBA3 for ; Fri, 19 Aug 2011 12:20:48 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE1D11E8082 for ; Fri, 19 Aug 2011 12:20:48 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p7JJLibi029009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Aug 2011 14:21:45 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.182]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 19 Aug 2011 15:21:44 -0400 From: Samita Chakrabarti To: "Rajiv Asati (rajiva)" , "Robert Raszuk (raszuk)" Date: Fri, 19 Aug 2011 15:21:43 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxdLxZwRlVcsgt/SdePE1crIJ8c9gBVYSUwAAf/EAA= Message-ID: <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.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" Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:20:49 -0000 Hi Rajiv, >From the document perspective, I'd like to see this statement in the draft = as an assumption or suggestion for this change. Thanks for the clarificatio= n Rajiv and Robert! -Samita=20 -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Friday, August 19, 2011 12:11 PM To: Robert Raszuk (raszuk); Samita Chakrabarti Cc: idr@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criter= ia-04.txt Samita, No additional latency expected. Thanks. Cheers, Rajiv > -----Original Message----- > From: Robert Raszuk (raszuk) > Sent: Wednesday, August 17, 2011 6:44 PM > To: Samita Chakrabarti > Cc: Rajiv Asati (rajiva); idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria- > 04.txt >=20 > Hi Samita, >=20 > Allow me to make an observation that today BGP already validates=20 > reachability to next hops, before considering path with such next hop to > be valid and to be eligible for best path selection. >=20 > In the light of the above Rajiv's proposal does not introduce any=20 > additional delay nor does it cause any impact on "bgp convergence". >=20 > The only place which changes for some applications of BGP is the place=20 > where you validate such next hop liveness/reachabilty. And as this is=20 > very implementation dependent I think we should not discuss those=20 > aspects on this mailing list. >=20 > Best regards, > R. >=20 > > Hi Rajiv, > > > > This is a good work clarifying the path-availability check in BGP=20 > > path selection. Is this document supposed to update RFC 4271 section > > 9.1.2 in general? I wonder, if you have any data or thoughts on=20 > > whether the additonal check at the data-plane level will add any=20 > > latency in BGP path selection process and thus have any effect on=20 > > convergence? A short paragraph on the impact on timing might be=20 > > useful for implementors as it seems running BFD or any other=20 > > mechanism to keep an up-to-date information of path-availability at=20 > > the data-plane will avoid any delay in the path selection process. > > > > -Samita From rajiva@cisco.com Mon Aug 22 11:35:55 2011 Return-Path: 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 C292C21F8B1D for ; Mon, 22 Aug 2011 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599] 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 Pg7dMh-r-V5N for ; Mon, 22 Aug 2011 11:35:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04A6921F8B84 for ; Mon, 22 Aug 2011 11:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2750; q=dns/txt; s=iport; t=1314038221; x=1315247821; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=aG9ZsWqBoy3dhGppeYkA7tIMwYlxqHce4gKHV+zG2TY=; b=Eurvta8HAxHbdwkDOZVSea3xIMs9NjiPp0Ms6BBQlO5VTrDFkCS+3w9t RKeGZDwT4NV1qwzH6mmjEcmg9ik/qcowtvOEaTUt4s0JBngvpNV1tmPoh 0S2ASpI4E8eamE15KC3ZplReBCNToqKOCrL2792GZbR8Iez38zwTBSW+p g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIAALmgUk6tJV2c/2dsb2JhbABBmDuPWneBQAEBAQECARIBHQo0CwUHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah0+WLgGeaIVpXwSHYJBJjAA X-IronPort-AV: E=Sophos;i="4.68,264,1312156800"; d="scan'208";a="15404475" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2011 18:37:00 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7MIb0ma024646; Mon, 22 Aug 2011 18:37:00 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 13:37:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 13:36:58 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> In-Reply-To: <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxdLxZwRlVcsgt/SdePE1crIJ8c9gBVYSUwAAf/EAAAlXETQA== References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> From: "Rajiv Asati (rajiva)" To: "Samita Chakrabarti" , "Robert Raszuk (raszuk)" X-OriginalArrivalTime: 22 Aug 2011 18:37:00.0049 (UTC) FILETIME=[7A846810:01CC60FA] Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:35:55 -0000 Samita, Sure. We can add a sentence for that whenever we are asked to publish the next version (prior to publication). Cheers, Rajiv > -----Original Message----- > From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] > Sent: Friday, August 19, 2011 3:22 PM > To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) > Cc: idr@ietf.org > Subject: RE: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria- > 04.txt >=20 > Hi Rajiv, >=20 > From the document perspective, I'd like to see this statement in the draft as > an assumption or suggestion for this change. Thanks for the clarification > Rajiv and Robert! >=20 >=20 > -Samita >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Friday, August 19, 2011 12:11 PM > To: Robert Raszuk (raszuk); Samita Chakrabarti > Cc: idr@ietf.org > Subject: RE: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria- > 04.txt >=20 > Samita, >=20 > No additional latency expected. Thanks. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Robert Raszuk (raszuk) > > Sent: Wednesday, August 17, 2011 6:44 PM > > To: Samita Chakrabarti > > Cc: Rajiv Asati (rajiva); idr@ietf.org > > Subject: Re: [Idr] I-D Action: > draft-ietf-idr-bgp-bestpath-selection-criteria- > > 04.txt > > > > Hi Samita, > > > > Allow me to make an observation that today BGP already validates > > reachability to next hops, before considering path with such next hop > to > > be valid and to be eligible for best path selection. > > > > In the light of the above Rajiv's proposal does not introduce any > > additional delay nor does it cause any impact on "bgp convergence". > > > > The only place which changes for some applications of BGP is the place > > where you validate such next hop liveness/reachabilty. And as this is > > very implementation dependent I think we should not discuss those > > aspects on this mailing list. > > > > Best regards, > > R. > > > > > Hi Rajiv, > > > > > > This is a good work clarifying the path-availability check in BGP > > > path selection. Is this document supposed to update RFC 4271 section > > > 9.1.2 in general? I wonder, if you have any data or thoughts on > > > whether the additonal check at the data-plane level will add any > > > latency in BGP path selection process and thus have any effect on > > > convergence? A short paragraph on the impact on timing might be > > > useful for implementors as it seems running BFD or any other > > > mechanism to keep an up-to-date information of path-availability at > > > the data-plane will avoid any delay in the path selection process. > > > > > > -Samita From jgs@juniper.net Tue Aug 23 11:28:45 2011 Return-Path: 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 39E1621F8C43 for ; Tue, 23 Aug 2011 11:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 i-bhGeOwmG6e for ; Tue, 23 Aug 2011 11:28:44 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5875321F8C40 for ; Tue, 23 Aug 2011 11:28:44 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTlPxnVSC0MORtgNYsMD3u/U0+Fd1hBnm@postini.com; Tue, 23 Aug 2011 11:29:53 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 23 Aug 2011 09:34:51 -0700 From: John Scudder To: "Rajiv Asati (rajiva)" Date: Tue, 23 Aug 2011 09:34:51 -0700 Thread-Topic: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxhspSL01yZhOsoRCaPOEkpFLMS5A== Message-ID: <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.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: "Robert Raszuk \(raszuk\)" , "idr@ietf.org" Subject: Re: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:28:45 -0000 Folks, The (abbreviated) WGLC has completed -- Rajiv, can you please make the agre= ed change and update the doc? =20 Thanks, --John and Sue On Aug 22, 2011, at 2:36 PM, Rajiv Asati (rajiva) wrote: > Samita, >=20 > Sure. We can add a sentence for that whenever we are asked to publish > the next version (prior to publication). >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] >> Sent: Friday, August 19, 2011 3:22 PM >> To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) >> Cc: idr@ietf.org >> Subject: RE: [Idr] I-D > Action:draft-ietf-idr-bgp-bestpath-selection-criteria- >> 04.txt >>=20 >> Hi Rajiv, >>=20 >> From the document perspective, I'd like to see this statement in the > draft as >> an assumption or suggestion for this change. Thanks for the > clarification >> Rajiv and Robert! >>=20 >>=20 >> -Samita >>=20 >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: Friday, August 19, 2011 12:11 PM >> To: Robert Raszuk (raszuk); Samita Chakrabarti >> Cc: idr@ietf.org >> Subject: RE: [Idr] I-D Action: > draft-ietf-idr-bgp-bestpath-selection-criteria- >> 04.txt >>=20 >> Samita, >>=20 >> No additional latency expected. Thanks. >>=20 >> Cheers, >> Rajiv >>=20 >>=20 >>> -----Original Message----- >>> From: Robert Raszuk (raszuk) >>> Sent: Wednesday, August 17, 2011 6:44 PM >>> To: Samita Chakrabarti >>> Cc: Rajiv Asati (rajiva); idr@ietf.org >>> Subject: Re: [Idr] I-D Action: >> draft-ietf-idr-bgp-bestpath-selection-criteria- >>> 04.txt >>>=20 >>> Hi Samita, >>>=20 >>> Allow me to make an observation that today BGP already validates >>> reachability to next hops, before considering path with such next > hop >> to >>> be valid and to be eligible for best path selection. >>>=20 >>> In the light of the above Rajiv's proposal does not introduce any >>> additional delay nor does it cause any impact on "bgp convergence". >>>=20 >>> The only place which changes for some applications of BGP is the > place >>> where you validate such next hop liveness/reachabilty. And as this > is >>> very implementation dependent I think we should not discuss those >>> aspects on this mailing list. >>>=20 >>> Best regards, >>> R. >>>=20 >>>> Hi Rajiv, >>>>=20 >>>> This is a good work clarifying the path-availability check in BGP >>>> path selection. Is this document supposed to update RFC 4271 > section >>>> 9.1.2 in general? I wonder, if you have any data or thoughts on >>>> whether the additonal check at the data-plane level will add any >>>> latency in BGP path selection process and thus have any effect on >>>> convergence? A short paragraph on the impact on timing might be >>>> useful for implementors as it seems running BFD or any other >>>> mechanism to keep an up-to-date information of path-availability > at >>>> the data-plane will avoid any delay in the path selection process. >>>>=20 >>>> -Samita >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Tue Aug 23 12:52:37 2011 Return-Path: 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 7E93821F8CCE; Tue, 23 Aug 2011 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 C8ehpY0luFAS; Tue, 23 Aug 2011 12:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A792421F8CC7; Tue, 23 Aug 2011 12:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110823195236.18408.95648.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2011 12:52:36 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:52:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Bestpath Selection Criteria Enhancement Author(s) : Rajiv Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt Pages : 9 Date : 2011-08-23 BGP specification [RFC4271] prescribes 'BGP next-hop reachability= 9; as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition&q= uot; to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-c= riteria-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-cr= iteria-05.txt From rajiva@cisco.com Tue Aug 23 12:52:50 2011 Return-Path: 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 3A96A21F8CD8 for ; Tue, 23 Aug 2011 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] 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 TBKv3GidHzOS for ; Tue, 23 Aug 2011 12:52:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB521F8CC7 for ; Tue, 23 Aug 2011 12:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3713; q=dns/txt; s=iport; t=1314129232; x=1315338832; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jymo2KFRzctWqkVGICX3Dq+240HrC3LaV5OTjHB/uBM=; b=Rp4o1ZPrn1CAYEvRebFfLQq9WNfc0k8Amp5JHihaeqQ3h9Wxqe7Zymvv srPgQS0bolg9Mxjxx/susLldUYCNHnukXkN/XjTmloXMHI/GZWCBM8+fy wmazl7wAYJUp7Dx7z/9LHlFVOWYpzViJN3dY+XxM3TMsgvwobjSwdYchl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMAAPoEVE6tJXG+/2dsb2JhbABCmBOPUneBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEEwgah1OeEwGfUYVpXwSHYZBOjAI X-IronPort-AV: E=Sophos;i="4.68,271,1312156800"; d="scan'208";a="15819788" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 23 Aug 2011 19:53:51 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7NJrpY2001050; Tue, 23 Aug 2011 19:53:51 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 14:53:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 14:53:50 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.com> In-Reply-To: <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: AcxhspSL01yZhOsoRCaPOEkpFLMS5AAG75tw References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> From: "Rajiv Asati (rajiva)" To: "John Scudder" X-OriginalArrivalTime: 23 Aug 2011 19:53:51.0390 (UTC) FILETIME=[6180F3E0:01CC61CE] Cc: "Robert Raszuk \(raszuk\)" , idr@ietf.org Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:52:50 -0000 Done. -05 version just got posted. Cheers, Rajiv > -----Original Message----- > From: John Scudder [mailto:jgs@juniper.net] > Sent: Tuesday, August 23, 2011 12:35 PM > To: Rajiv Asati (rajiva) > Cc: Samita Chakrabarti; Robert Raszuk (raszuk); idr@ietf.org > Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria- > 04.txt >=20 > Folks, >=20 > The (abbreviated) WGLC has completed -- Rajiv, can you please make the agreed > change and update the doc? >=20 > Thanks, >=20 > --John and Sue >=20 > On Aug 22, 2011, at 2:36 PM, Rajiv Asati (rajiva) wrote: >=20 > > Samita, > > > > Sure. We can add a sentence for that whenever we are asked to publish > > the next version (prior to publication). > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] > >> Sent: Friday, August 19, 2011 3:22 PM > >> To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) > >> Cc: idr@ietf.org > >> Subject: RE: [Idr] I-D > > Action:draft-ietf-idr-bgp-bestpath-selection-criteria- > >> 04.txt > >> > >> Hi Rajiv, > >> > >> From the document perspective, I'd like to see this statement in the > > draft as > >> an assumption or suggestion for this change. Thanks for the > > clarification > >> Rajiv and Robert! > >> > >> > >> -Samita > >> > >> -----Original Message----- > >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > >> Sent: Friday, August 19, 2011 12:11 PM > >> To: Robert Raszuk (raszuk); Samita Chakrabarti > >> Cc: idr@ietf.org > >> Subject: RE: [Idr] I-D Action: > > draft-ietf-idr-bgp-bestpath-selection-criteria- > >> 04.txt > >> > >> Samita, > >> > >> No additional latency expected. Thanks. > >> > >> Cheers, > >> Rajiv > >> > >> > >>> -----Original Message----- > >>> From: Robert Raszuk (raszuk) > >>> Sent: Wednesday, August 17, 2011 6:44 PM > >>> To: Samita Chakrabarti > >>> Cc: Rajiv Asati (rajiva); idr@ietf.org > >>> Subject: Re: [Idr] I-D Action: > >> draft-ietf-idr-bgp-bestpath-selection-criteria- > >>> 04.txt > >>> > >>> Hi Samita, > >>> > >>> Allow me to make an observation that today BGP already validates > >>> reachability to next hops, before considering path with such next > > hop > >> to > >>> be valid and to be eligible for best path selection. > >>> > >>> In the light of the above Rajiv's proposal does not introduce any > >>> additional delay nor does it cause any impact on "bgp convergence". > >>> > >>> The only place which changes for some applications of BGP is the > > place > >>> where you validate such next hop liveness/reachabilty. And as this > > is > >>> very implementation dependent I think we should not discuss those > >>> aspects on this mailing list. > >>> > >>> Best regards, > >>> R. > >>> > >>>> Hi Rajiv, > >>>> > >>>> This is a good work clarifying the path-availability check in BGP > >>>> path selection. Is this document supposed to update RFC 4271 > > section > >>>> 9.1.2 in general? I wonder, if you have any data or thoughts on > >>>> whether the additonal check at the data-plane level will add any > >>>> latency in BGP path selection process and thus have any effect on > >>>> convergence? A short paragraph on the impact on timing might be > >>>> useful for implementors as it seems running BFD or any other > >>>> mechanism to keep an up-to-date information of path-availability > > at > >>>> the data-plane will avoid any delay in the path selection process. > >>>> > >>>> -Samita > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Tue Aug 23 13:24:19 2011 Return-Path: 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 2359021F8D2B for ; Tue, 23 Aug 2011 13:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 KHWihTdMcb-n for ; Tue, 23 Aug 2011 13:24:18 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0299721F8D2C for ; Tue, 23 Aug 2011 13:24:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTlQMs67p+xKGgmZf3NlP/kjs4INKItew@postini.com; Tue, 23 Aug 2011 13:25:26 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 23 Aug 2011 13:24:59 -0700 From: John Scudder To: "Rajiv Asati (rajiva)" , Samita Chakrabarti Date: Tue, 23 Aug 2011 13:25:01 -0700 Thread-Topic: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: Acxh0rtD4ZPxomCqQveoXrTXYN6+oQ== Message-ID: <608DB021-EF9B-4E12-A716-7F84B3AF5B95@juniper.net> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.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: "Robert Raszuk \(raszuk\)" , "idr@ietf.org List" Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:24:19 -0000 Thanks. Samita, can you please check that the change addresses your concern? --John On Aug 23, 2011, at 3:53 PM, Rajiv Asati (rajiva) wrote: > Done. -05 version just got posted. >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: John Scudder [mailto:jgs@juniper.net] >> Sent: Tuesday, August 23, 2011 12:35 PM >> To: Rajiv Asati (rajiva) >> Cc: Samita Chakrabarti; Robert Raszuk (raszuk); idr@ietf.org >> Subject: Re: [Idr] > I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria- >> 04.txt >>=20 >> Folks, >>=20 >> The (abbreviated) WGLC has completed -- Rajiv, can you please make the > agreed >> change and update the doc? >>=20 >> Thanks, >>=20 >> --John and Sue >>=20 >> On Aug 22, 2011, at 2:36 PM, Rajiv Asati (rajiva) wrote: >>=20 >>> Samita, >>>=20 >>> Sure. We can add a sentence for that whenever we are asked to > publish >>> the next version (prior to publication). >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] >>>> Sent: Friday, August 19, 2011 3:22 PM >>>> To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) >>>> Cc: idr@ietf.org >>>> Subject: RE: [Idr] I-D >>> Action:draft-ietf-idr-bgp-bestpath-selection-criteria- >>>> 04.txt >>>>=20 >>>> Hi Rajiv, >>>>=20 >>>> From the document perspective, I'd like to see this statement in > the >>> draft as >>>> an assumption or suggestion for this change. Thanks for the >>> clarification >>>> Rajiv and Robert! >>>>=20 >>>>=20 >>>> -Samita >>>>=20 >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>>> Sent: Friday, August 19, 2011 12:11 PM >>>> To: Robert Raszuk (raszuk); Samita Chakrabarti >>>> Cc: idr@ietf.org >>>> Subject: RE: [Idr] I-D Action: >>> draft-ietf-idr-bgp-bestpath-selection-criteria- >>>> 04.txt >>>>=20 >>>> Samita, >>>>=20 >>>> No additional latency expected. Thanks. >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Robert Raszuk (raszuk) >>>>> Sent: Wednesday, August 17, 2011 6:44 PM >>>>> To: Samita Chakrabarti >>>>> Cc: Rajiv Asati (rajiva); idr@ietf.org >>>>> Subject: Re: [Idr] I-D Action: >>>> draft-ietf-idr-bgp-bestpath-selection-criteria- >>>>> 04.txt >>>>>=20 >>>>> Hi Samita, >>>>>=20 >>>>> Allow me to make an observation that today BGP already validates >>>>> reachability to next hops, before considering path with such next >>> hop >>>> to >>>>> be valid and to be eligible for best path selection. >>>>>=20 >>>>> In the light of the above Rajiv's proposal does not introduce any >>>>> additional delay nor does it cause any impact on "bgp > convergence". >>>>>=20 >>>>> The only place which changes for some applications of BGP is the >>> place >>>>> where you validate such next hop liveness/reachabilty. And as this >>> is >>>>> very implementation dependent I think we should not discuss those >>>>> aspects on this mailing list. >>>>>=20 >>>>> Best regards, >>>>> R. >>>>>=20 >>>>>> Hi Rajiv, >>>>>>=20 >>>>>> This is a good work clarifying the path-availability check in BGP >>>>>> path selection. Is this document supposed to update RFC 4271 >>> section >>>>>> 9.1.2 in general? I wonder, if you have any data or thoughts on >>>>>> whether the additonal check at the data-plane level will add any >>>>>> latency in BGP path selection process and thus have any effect on >>>>>> convergence? A short paragraph on the impact on timing might be >>>>>> useful for implementors as it seems running BFD or any other >>>>>> mechanism to keep an up-to-date information of path-availability >>> at >>>>>> the data-plane will avoid any delay in the path selection > process. >>>>>>=20 >>>>>> -Samita >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >=20 From samita.chakrabarti@ericsson.com Wed Aug 24 10:51:16 2011 Return-Path: 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 E738821F8BB9 for ; Wed, 24 Aug 2011 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, 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 kFWn1NM7W3Fr for ; Wed, 24 Aug 2011 10:51:16 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2890E21F8BC5 for ; Wed, 24 Aug 2011 10:51:16 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OHqNch026660; Wed, 24 Aug 2011 12:52:24 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 24 Aug 2011 13:52:17 -0400 From: Samita Chakrabarti To: John Scudder , "Rajiv Asati (rajiva)" Date: Wed, 24 Aug 2011 13:52:17 -0400 Thread-Topic: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt Thread-Index: Acxh0rtD4ZPxomCqQveoXrTXYN6+oQAs1n2Q Message-ID: <16D60F43CA0B724F8052D7E9323565D7243F2270CD@EUSAACMS0715.eamcs.ericsson.se> References: <20110817183606.4053.38107.idtracker@ietfa.amsl.com> <16D60F43CA0B724F8052D7E9323565D721F23B7CB6@EUSAACMS0715.eamcs.ericsson.se> <4E4C4438.2090702@cisco.com> <067E6CE33034954AAC05C9EC85E2577C05B1B438@XMB-RCD-111.cisco.com> <16D60F43CA0B724F8052D7E9323565D721F23B884C@EUSAACMS0715.eamcs.ericsson.se> <067E6CE33034954AAC05C9EC85E2577C05BBC70A@XMB-RCD-111.cisco.com> <20AA97F0-FF3C-4F27-80A9-B3DAD5FDCDA2@juniper.net> <067E6CE33034954AAC05C9EC85E2577C05BBCB60@XMB-RCD-111.cisco.com> <608DB021-EF9B-4E12-A716-7F84B3AF5B95@juniper.net> In-Reply-To: <608DB021-EF9B-4E12-A716-7F84B3AF5B95@juniper.net> 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: "Robert Raszuk \(raszuk\)" , "idr@ietf.org List" Subject: Re: [Idr] I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:51:17 -0000 =20 >Samita, can you please check that the change addresses your concern? > > --John Section 4 (Conclusion) added a line on the expectation on the convergence. Looks fine to me. Thanks, -Samita On Aug 23, 2011, at 3:53 PM, Rajiv Asati (rajiva) wrote: > Done. -05 version just got posted. >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: John Scudder [mailto:jgs@juniper.net] >> Sent: Tuesday, August 23, 2011 12:35 PM >> To: Rajiv Asati (rajiva) >> Cc: Samita Chakrabarti; Robert Raszuk (raszuk); idr@ietf.org >> Subject: Re: [Idr] > I-DAction:draft-ietf-idr-bgp-bestpath-selection-criteria- >> 04.txt >>=20 >> Folks, >>=20 >> The (abbreviated) WGLC has completed -- Rajiv, can you please make=20 >> the > agreed >> change and update the doc? >>=20 >> Thanks, >>=20 >> --John and Sue >>=20 >> On Aug 22, 2011, at 2:36 PM, Rajiv Asati (rajiva) wrote: >>=20 >>> Samita, >>>=20 >>> Sure. We can add a sentence for that whenever we are asked to > publish >>> the next version (prior to publication). >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] >>>> Sent: Friday, August 19, 2011 3:22 PM >>>> To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) >>>> Cc: idr@ietf.org >>>> Subject: RE: [Idr] I-D >>> Action:draft-ietf-idr-bgp-bestpath-selection-criteria- >>>> 04.txt >>>>=20 >>>> Hi Rajiv, >>>>=20 >>>> From the document perspective, I'd like to see this statement in > the >>> draft as >>>> an assumption or suggestion for this change. Thanks for the >>> clarification >>>> Rajiv and Robert! >>>>=20 >>>>=20 >>>> -Samita >>>>=20 >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>>> Sent: Friday, August 19, 2011 12:11 PM >>>> To: Robert Raszuk (raszuk); Samita Chakrabarti >>>> Cc: idr@ietf.org >>>> Subject: RE: [Idr] I-D Action: >>> draft-ietf-idr-bgp-bestpath-selection-criteria- >>>> 04.txt >>>>=20 >>>> Samita, >>>>=20 >>>> No additional latency expected. Thanks. >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Robert Raszuk (raszuk) >>>>> Sent: Wednesday, August 17, 2011 6:44 PM >>>>> To: Samita Chakrabarti >>>>> Cc: Rajiv Asati (rajiva); idr@ietf.org >>>>> Subject: Re: [Idr] I-D Action: >>>> draft-ietf-idr-bgp-bestpath-selection-criteria- >>>>> 04.txt >>>>>=20 >>>>> Hi Samita, >>>>>=20 >>>>> Allow me to make an observation that today BGP already validates=20 >>>>> reachability to next hops, before considering path with such next >>> hop >>>> to >>>>> be valid and to be eligible for best path selection. >>>>>=20 >>>>> In the light of the above Rajiv's proposal does not introduce any=20 >>>>> additional delay nor does it cause any impact on "bgp > convergence". >>>>>=20 >>>>> The only place which changes for some applications of BGP is the >>> place >>>>> where you validate such next hop liveness/reachabilty. And as this >>> is >>>>> very implementation dependent I think we should not discuss those=20 >>>>> aspects on this mailing list. >>>>>=20 >>>>> Best regards, >>>>> R. >>>>>=20 >>>>>> Hi Rajiv, >>>>>>=20 >>>>>> This is a good work clarifying the path-availability check in BGP=20 >>>>>> path selection. Is this document supposed to update RFC 4271 >>> section >>>>>> 9.1.2 in general? I wonder, if you have any data or thoughts on=20 >>>>>> whether the additonal check at the data-plane level will add any=20 >>>>>> latency in BGP path selection process and thus have any effect on=20 >>>>>> convergence? A short paragraph on the impact on timing might be=20 >>>>>> useful for implementors as it seems running BFD or any other=20 >>>>>> mechanism to keep an up-to-date information of path-availability >>> at >>>>>> the data-plane will avoid any delay in the path selection > process. >>>>>>=20 >>>>>> -Samita >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >=20 From enkechen@cisco.com Mon Aug 29 13:40:55 2011 Return-Path: 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 20EBD21F8C7B for ; Mon, 29 Aug 2011 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Kd-ggR4RkXgQ for ; Mon, 29 Aug 2011 13:40:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC721F8B10 for ; Mon, 29 Aug 2011 13:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=6766; q=dns/txt; s=iport; t=1314650540; x=1315860140; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=zV2fH1q8V+a4wL04OLCVOnFukImPEVKH4dFurkRSx5c=; b=QK7J6T/SsT1toLdBTJ1XNDdk79Z2Fb3gBJGU5eyqZamUgeZ2azVKpZrc k7QOkvPUTzPcTq+f17dvXm4K4XNMgBx55/nUPrMk6GLd5RnhdfE/WbpFP TlPkwApD38LFYHexwclmYNL22pkDYjJsBUR2QtyZzbLXh+MisW5SktNaX w=; X-IronPort-AV: E=Sophos;i="4.68,298,1312156800"; d="scan'208,217";a="17572498" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 29 Aug 2011 20:42:18 +0000 Received: from dhcp-171-71-139-199.cisco.com (dhcp-171-71-139-199.cisco.com [171.71.139.199]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7TKgHik004080; Mon, 29 Aug 2011 20:42:18 GMT Message-ID: <4E5BF9C0.5010100@cisco.com> Date: Mon, 29 Aug 2011 13:42:40 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "idr@ietf.org" References: <20110829181012.27989.89228.idtracker@ietfa.amsl.com> In-Reply-To: <20110829181012.27989.89228.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110829181012.27989.89228.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070500080506000502000603" Cc: Yakov Rekhter Subject: [Idr] Fwd: I-D Action: draft-chen-idr-rfc4724bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 20:40:55 -0000 This is a multi-part message in MIME format. --------------070500080506000502000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -- Enke -------- Original Message -------- Subject: I-D Action: draft-chen-idr-rfc4724bis-00.txt Date: Mon, 29 Aug 2011 11:10:12 -0700 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 : Graceful Restart Mechanism for BGP Author(s) : Srihari R. Sangli Enke Chen Rex Fernando John G. Scudder Yakov Rekhter Filename : draft-chen-idr-rfc4724bis-00.txt Pages : 14 Date : 2011-08-29 This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed"Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve its forwarding state during BGP restart, as well as to convey its intention of generating the End-of-RIB marker upon the completion of its initial routing update. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve the forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-idr-rfc4724bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-rfc4724bis-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070500080506000502000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.   -- Enke


-------- Original Message --------
Subject: I-D Action: draft-chen-idr-rfc4724bis-00.txt
Date: Mon, 29 Aug 2011 11:10:12 -0700
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           : Graceful Restart Mechanism for BGP
	Author(s)       : Srihari R. Sangli
                          Enke Chen
                          Rex Fernando
                          John G. Scudder
                          Yakov Rekhter
	Filename        : draft-chen-idr-rfc4724bis-00.txt
	Pages           : 14
	Date            : 2011-08-29

   This document describes a mechanism for BGP that would help minimize
   the negative effects on routing caused by BGP restart.  An End-of-RIB
   marker is specified and can be used to convey routing convergence
   information.  A new BGP capability, termed &quot;Graceful Restart
   Capability&quot;, is defined that would allow a BGP speaker to express its
   ability to preserve its forwarding state during BGP restart, as well
   as to convey its intention of generating the End-of-RIB marker upon
   the completion of its initial routing update.  Finally, procedures
   are outlined for temporarily retaining routing information across a
   TCP session termination/re-establishment.

   The mechanisms described in this document are applicable to all
   routers, both those with the ability to preserve the forwarding state
   during BGP restart and those without (although the latter need to
   implement only a subset of the mechanisms described in this
   document).



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-idr-rfc4724bis-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-rfc4724bis-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------070500080506000502000603--