Re: [Idr] Solicit feedbacks on draft-dong-idr-end-of-rib-use-extension

Robert Raszuk <raszuk@cisco.com> Wed, 10 August 2011 06:10 UTC

Return-Path: <raszuk@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB6521F873D for <idr@ietfa.amsl.com>; 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 <idr@ietfa.amsl.com>; 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 <idr@ietf.org>; 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 <raszuk@cisco.com>
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 <jie.dong@huawei.com>
References: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C9270B76B48C@szxeml509-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 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
>