Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt

Samita Chakrabarti <> Wed, 17 August 2011 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64C8611E8089 for <>; Wed, 17 Aug 2011 13:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.606
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 82nx4AtK4kcB for <>; Wed, 17 Aug 2011 13:50:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B569611E8082 for <>; Wed, 17 Aug 2011 13:50:11 -0700 (PDT)
Received: from ([]) by (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 ([]) by ([]) with mapi; Wed, 17 Aug 2011 16:50:55 -0400
From: Samita Chakrabarti <>
To: "" <>
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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt
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 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.


-----Original Message-----
From: [] On Behalf Of
Sent: Wednesday, August 17, 2011 11:36 AM
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. 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 &#39;BGP next-hop reachability&#39;
   as one of the key &#39;Route Resolvability Condition&#39; 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 &quot;Route Resolvability Condition&quot;
   to facilitate the next-hop to be resolved in the chosen data plane.

A URL for this Internet-Draft is:

Internet-Drafts are also available by anonymous FTP at:

This Internet-Draft can be retrieved at:
Idr mailing list