IETF Logo Mail Archive

Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document

Robert Raszuk <raszuk@juniper.net> Wed, 26 November 2008 10:37 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE3528C1AA; Wed, 26 Nov 2008 02:37:29 -0800 (PST)
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 54D5128C1AA for <idr@core3.amsl.com>; Wed, 26 Nov 2008 02:37:27 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF4brG+pDxTG for <idr@core3.amsl.com>; Wed, 26 Nov 2008 02:37:26 -0800 (PST)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id C28F93A684E for <idr@ietf.org>; Wed, 26 Nov 2008 02:37:25 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSS0mwXIq5g3rWdx2xbKiDy/bq9czn1LK@postini.com; Wed, 26 Nov 2008 02:37:24 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Wed, 26 Nov 2008 02:29:31 -0800
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 02:29:31 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 02:29:31 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 02:29:30 -0800
Received: from [172.26.250.98] ([172.26.250.98]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAQATSM56199; Wed, 26 Nov 2008 02:29:29 -0800 (PST) (envelope-from raszuk@juniper.net)
Message-ID: <492D2505.9080507@juniper.net>
Date: Wed, 26 Nov 2008 02:29:25 -0800
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Uli Bornhauser <ub@cs.uni-bonn.de>
References: <200811241951.mAOJp1M40495@magenta.juniper.net> <6D26D1FE43A66F439F8109CDD4241965023565FA@INEXC1U01.in.lucent.com> <492BA8E7.9060909@cisco.com> <492D1324.40705@cs.uni-bonn.de>
In-Reply-To: <492D1324.40705@cs.uni-bonn.de>
X-OriginalArrivalTime: 26 Nov 2008 10:29:30.0774 (UTC) FILETIME=[DDEAFB60:01C94FB1]
Cc: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org, "Horneffer, Martin" <Martin.Horneffer@t-com.net>
Subject: Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Hi Uli,

>>  2)Fast Connectivity Restoration Using BGP Add-path,
>> draft-pmohapat-idr-fast-conn-restore-00
>>
>> The issue of "active path" vs "inavtive path" is more relevant to #2,
>> and it is indeed addressed there.

> The idea sketched in the Fast Connectivity Restoration draft is a step
> in the right direction. However, there are still configurations possible
> where inactive paths are incorrectly rated as active ones. Such examples
> show that the Border router attr_set as currently design is not
> sufficient to solve the active/inactive rating problem in general. As
> I hope I will find some time to email an ASCII example for such a configuration.

Please do. It would be quite helpful.

 > Manav, I believe that Addpath in hardly usable without having a
 > mechanism that inherently avoids this problem.

Add-path as currently proposed is a base specification. Each application 
using add-path may choose to define it's own set of primitives and rules.

For example if I would like to use add-path to send all the paths from a 
router to my BGP looking glass or other BGP monitor I really don't need 
much more then it is defined in the base spec.

Cheers,
R.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email