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

Robert Raszuk <raszuk@juniper.net> Tue, 25 November 2008 17:20 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 AF9533A6C08; Tue, 25 Nov 2008 09:20:38 -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 F0F5C3A6C13 for <idr@core3.amsl.com>; Tue, 25 Nov 2008 09:20:37 -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 GNl3mzHw0vRY for <idr@core3.amsl.com>; Tue, 25 Nov 2008 09:20:37 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id EC1523A6C06 for <idr@ietf.org>; Tue, 25 Nov 2008 09:20:36 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSSwz4bzaZPEWMf0MBKyPBZRJ/VEdjqXZ@postini.com; Tue, 25 Nov 2008 09:20:35 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; Tue, 25 Nov 2008 09:15:38 -0800
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 09:15:38 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 09:15:38 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 09:15:37 -0800
Received: from [172.26.250.82] ([172.26.250.82]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAPHFZM56176; Tue, 25 Nov 2008 09:15:36 -0800 (PST) (envelope-from raszuk@juniper.net)
Message-ID: <492C32B4.9000408@juniper.net>
Date: Tue, 25 Nov 2008 09:15:32 -0800
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <200811241951.mAOJp1M40495@magenta.juniper.net> <CD3DF385-2ECB-4D0C-A9A6-F47F14818939@tcb.net> <04CAD96D4C5A3D48B1919248A8FE0D54082D6005@xmb-sjc-215.amer.cisco.com> <2BAD1AFB-6B55-40C0-A59C-7D350D9C4D47@tcb.net>
In-Reply-To: <2BAD1AFB-6B55-40C0-A59C-7D350D9C4D47@tcb.net>
X-OriginalArrivalTime: 25 Nov 2008 17:15:37.0756 (UTC) FILETIME=[6F5B9DC0:01C94F21]
Cc: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org
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 Danny,

 > and advertising the capability may well result in considerable
 > reductions in the ability to update pack, etc..

How would it ? Path_id is part of NLRI not any of the attached attributes.

Yes some applications which build on top of add-path may require new 
attributes but after all this is the price one needs to pay distribute 
more then best path around. And I think the numerous applications of the 
latter proves the price vs benefit much into the benefit zone.

Cheers,
R.


> 
> On Nov 25, 2008, at 8:58 AM, Pradosh Mohapatra (pmohapat) wrote:
>>
>> Right. It MUST preserve the path-id that it received in the path
>> structure since the id would be used for replacing any new
>> advertisement received for that path or removing the path upon
>> withdrawl.
> 
> Ahh, of course..
> 
>> This makes parsing extremely difficult. Reception of the capability
>> from a peer is the only indication that the UPDATE parsing needs
>> to retrieve the first four octets as path-id and the prefix
>> follows after that. How would you differentiate an UPDATE message
>> where prefixes are encoded with path-id vs. another where they
>> aren't?
>>
>> If a speaker is able to send only one path and has advertised
>> add-path capability, there are simpler ways to encode a (dummy)
>> path-id, like always encode 0 or 1 or whatever...
> 
> While I'm an advocate of this work, I'm just a little
> concerned about the fact that we're introducing more paths,
> and advertising the capability may well result in considerable
> reductions in the ability to update pack, etc..
> 
> Some explicit text around error handling would be useful here.
> 
> Of course, the call was to become a WG document, not WG LC,
> and so none of my queries should be considered gating.
> 
> -danny
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 

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