Re: [Idr] IETF 73

Paul Francis <francis@cs.cornell.edu> Tue, 18 November 2008 01:40 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 EA81428C182; Mon, 17 Nov 2008 17:40:40 -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 CD63528C0E6 for <idr@core3.amsl.com>; Mon, 17 Nov 2008 17:40:39 -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=[AWL=0.000, 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 6KNPI820lLce for <idr@core3.amsl.com>; Mon, 17 Nov 2008 17:40:38 -0800 (PST)
Received: from exch-hub2.cs.cornell.edu (mail-hub-2.cs.cornell.edu [128.84.103.139]) by core3.amsl.com (Postfix) with ESMTP id C395C28C182 for <idr@ietf.org>; Mon, 17 Nov 2008 17:40:38 -0800 (PST)
Received: from EXCHANGE1.cs.cornell.edu (128.84.96.42) by mail-hub.cs.cornell.edu (128.84.96.245) with Microsoft SMTP Server id 8.0.813.0; Mon, 17 Nov 2008 20:40:38 -0500
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:40:37 -0500
Content-Class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 17 Nov 2008 20:40:35 -0500
Message-ID: <37BC8961A005144C8F5B8E4AD226DE11181636@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <195A0B51-43BB-4817-A6C0-0E1B43A92817@cs.ucla.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] IETF 73
Thread-Index: AclJCxmRYQ5POE7vSkOBkYwWzAdUXAAE3DpQ
From: Paul Francis <francis@cs.cornell.edu>
To: Lixia Zhang <lixia@CS.UCLA.EDU>
X-OriginalArrivalTime: 18 Nov 2008 01:40:37.0587 (UTC) FILETIME=[A828EA30:01C9491E]
Cc: Inter-Domain Routing List <idr@ietf.org>
Subject: Re: [Idr] IETF 73
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/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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Understood!

PF
 

> -----Original Message-----
> From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU] 
> Sent: Monday, November 17, 2008 6:20 PM
> To: Paul Francis
> Cc: Iljitsch van Beijnum; Inter-Domain Routing List
> Subject: Re: [Idr] IETF 73
> 
> 
> On Nov 15, 2008, at 6:07 AM, Paul Francis wrote:
> > The sense in which they are not orthogonal is this.  IACs are only 
> > useful insofar that upstream ASes have a choice of path.  
> Of course, 
> > with BGP it often so happens that upstream ASes have 
> choices, but once 
> > any AS makes a choice, it limits the number of choices it 
> presents to 
> > its upstream.  If you have tunnels, then more choices are presented 
> > upstream, and there should therefore me more opportunities to make 
> > selections.  The mapped-bgp spec offers even more choices than the 
> > tunnel-endpoints draft.
> >
> > So basically my point is that if you are prepared to modify BGP to 
> > improve load balancing, you ought to consider the additional 
> > improvements the tunnels can afford you.
> >
> > As for the tunnel-endpoint draft being more appropriate for 
> RRG, this 
> > is feedback I'd like to get.  Narrowly viewed, the tunnel-endpoint 
> > draft is something that improves the performance of 
> (intra-domain) VA, 
> > which is already work that is being done in IDR (and was explicitly 
> > turned away by RRG).
> 
> Just my own 2 cents (with all hats off): before Dublin, the 
> VA looked to me as something that, if adopted, could be 
> deployed *right away*, so IDR seemed to me a better venue to 
> push it--this is not so much of turning VA away per se.  As I 
> mentioned to you privately, I always viewed VA as "poor man's 
> map" in map-n-encap, which can serve as step stone towards 
> incremental deployment (of solutions falling under map-n- encap).
> 
> >  Broadly viewed, the tunnel-endpoint draft has wider scope, which 
> > Raszuk pointed out, and this needs to be discussed in IDR.
> >
> > PF
> >
> >
> >> -----Original Message-----
> >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
> >> Sent: Thursday, November 13, 2008 4:41 AM
> >> To: Paul Francis
> >> Cc: Inter-Domain Routing List
> >> Subject: Re: [Idr] IETF 73
> >>
> >> On 12 nov 2008, at 13:16, Paul Francis wrote:
> >>
> >>> It's worth pointing out that if you convey inter-AS tunnel
> >> endponts in
> >>> BGP along the lines of
> >>> http://tools.ietf.org/id/draft-xu-idr-tunnel-00.txt
> >>> , then different ASes (or even individual routers) can select 
> >>> different paths, and so an IAC scheme can become more
> >> fine-grained.
> >>> Personally I think if we are going to look at something
> >> like IAC, we
> >>> should consider tunneling at the same time.
> >>>
> >>
> >> Both the problems that these drafts address and the solutions that 
> >> they propose look completely orthogonal to me, so I don't see how 
> >> that would be helpful.
> >>
> >> About the tunnel draft: isn't this something that could easily be 
> >> part of the RRG efforts? Standardizing this now while overlapping 
> >> working is going on in RRG may be premature.
> >>
> >> Iljitsch
> >>
> > _______________________________________________
> > 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