Re: [Idr] WG Last Call for AS-wide Unique BGP Identifier for BGP-4

Enke Chen <enkechen@cisco.com> Sun, 07 February 2010 21:04 UTC

Return-Path: <enkechen@cisco.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5825D28C118 for <idr@core3.amsl.com>; Sun, 7 Feb 2010 13:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYo8iSER8OdG for <idr@core3.amsl.com>; Sun, 7 Feb 2010 13:04:38 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 797513A729B for <idr@ietf.org>; Sun, 7 Feb 2010 13:04:38 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.49,423,1262563200"; d="scan'208";a="296834924"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Feb 2010 21:05:38 +0000
Received: from [10.21.119.114] ([10.21.119.114]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o17L5bnm029341; Sun, 7 Feb 2010 21:05:37 GMT
Message-ID: <4B6F2B22.6080905@cisco.com>
Date: Sun, 07 Feb 2010 13:05:38 -0800
From: Enke Chen <enkechen@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <172894AC-00C8-4BDC-A95C-E9C00E6B881A@juniper.net> <05A7ECE1-DEA5-4829-BBB3-C3A32451C68D@tcb.net>
In-Reply-To: <05A7ECE1-DEA5-4829-BBB3-C3A32451C68D@tcb.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr List <idr@ietf.org>
Subject: Re: [Idr] WG Last Call for AS-wide Unique BGP Identifier for BGP-4
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 07 Feb 2010 21:04:39 -0000

Hi, Danny:

There is no impact on RFC 5004 as RFC 5004 talks about the steps *prior 
to*  the BGP identifier comparison in the route selection:

----------------------------------------------------------------------------------------
RFC 5004:

3.  The Algorithm

   Consider the case in which the existing best path A is from an
   external peer, and another external path B is then selected as the
   new best path by the route selection algorithm described in [BGP].
   When comparing all the paths in route selection, if neither Path A
   nor Path B is eliminated by the route selection algorithm prior to
   Step f) -- BGP identifier comparison (Section 9.1.2.2, [BGP]) -- we
   propose that the existing best path (Path A) be kept as the best path
   (thus avoiding switching the best path to Path B).
---------------------------------------------------------------------


Also, with respect to the bestpath calculation, RFC 4271 covers the case 
where the BGP identifiers are identical:

9.1.2.2.  Breaking Ties (Phase 2)

            ....

      f) Remove from consideration all routes other than the route that
         was advertised by the BGP speaker with the lowest BGP
         Identifier value.

      g) Prefer the route received from the lowest peer address.

------------------------

Regards,   -- Enke


Danny McPherson wrote:
> On Feb 5, 2010, at 5:37 AM, John G. Scudder wrote:
>
>   
>> This is to start the IDR WG Last Call on advancing draft-ietf-idr-bgp-identifier-11.txt as a Proposed Standard RFC. The deadline for comments is February 19, 2010.
>>
>> A URL for the draft is http://www.ietf.org/id/draft-ietf-idr-bgp-identifier-11.txt
>>     
>
> I don't see any mention of the impact on RFC 5004 that
> this mechanism might introduce (i.e., the algorithm 
> assumes different BGP identifiers from external peers, and
> currently provides no provision for an additional key of 
> external AS number).
>
> -danny
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>