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

Robert Raszuk <> Wed, 17 August 2011 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3BE111E8095 for <>; Wed, 17 Aug 2011 15:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.935
X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L0UY4tnpOCKk for <>; Wed, 17 Aug 2011 15:42:38 -0700 (PDT)
Received: from ( []) by (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;;; 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 ([]) by with ESMTP; 17 Aug 2011 22:43:30 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p7HMhSTS027047; Wed, 17 Aug 2011 22:43:29 GMT
Message-ID: <>
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: Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: Samita Chakrabarti <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 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,

> 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