Re: [Idr] draft-van-beijnum-idr-iac-00
Pekka Savola <pekkas@netcore.fi> Mon, 10 March 2008 01:39 UTC
Return-Path: <idr-bounces@ietf.org>
X-Original-To: ietfarch-idr-archive@core3.amsl.com
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8228828C2DC; Sun, 9 Mar 2008 18:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.446
X-Spam-Level:
X-Spam-Status: No, score=-100.446 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 LhgObXaF-Smr; Sun, 9 Mar 2008 18:39:43 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573E328C2B0; Sun, 9 Mar 2008 18:39:43 -0700 (PDT)
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 CD20928C2B0 for <idr@core3.amsl.com>; Sun, 9 Mar 2008 18:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 knHmFzNMwKOz for <idr@core3.amsl.com>; Sun, 9 Mar 2008 18:39:40 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 1F16B28C2A5 for <idr@ietf.org>; Sun, 9 Mar 2008 18:39:39 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2A1ag0W028896; Mon, 10 Mar 2008 03:36:43 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2A1acjK028891; Mon, 10 Mar 2008 03:36:40 +0200
Date: Mon, 10 Mar 2008 03:36:36 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <9E974148-E332-45AB-AB80-283A244182D9@muada.com>
Message-ID: <alpine.LRH.1.00.0803100311420.28306@netcore.fi>
References: <20080218113944.DD87728C0F4@core3.amsl.com> <9E974148-E332-45AB-AB80-283A244182D9@muada.com>
User-Agent: Alpine 1.00 (LRH 882 2007-12-20)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6174/Sun Mar 9 03:31:16 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] draft-van-beijnum-idr-iac-00
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
On Mon, 18 Feb 2008, Iljitsch van Beijnum wrote: > A while ago I had a short discussion with Robert Raszuk about (the > lack of) an inter-AS metric, and he asked me to write my idea up in a > draft. I did. Let me know what you think. I've read this but I'm not quite sure which problem this is trying to solve. The abstract talks about reducing TE deaggregation, but Introduction jumps right into inter-tier1 load-balancing without describing how these are related. The premise in Introduction appears to be that if a tier1 customer would want to balance (in definition "get closer to 50/50 tier1 propotion" instead of "80/20") its incoming traffic, a AS_PATH prepending is too coarse a tool. This offers a way to do this, IAC metric allows finer granularity balancing and tuning (by the operators in the middle, not the site itself, except potentially by proxy using IAC-controlling communities). This may be applicable for a customer solely connecting to two tier1's (a bad idea as you may end up being hurt by depeering politics), but outside of that context, AS_PATH length has only limited usefulness -- being overridden by LOCAL_PREF and longest prefix matching. Further, the more difficult TE problem is traffic optimization (e.g. finding lowest RTT or least utilized path for source/destination pair) not just load balancing. If this aims to offer tools for optimization, I don't see how it achieves that. As a result I don't yet see if this is worth the trouble. This certainly wouldn't have any impact on the number of more specific TE routes in the DFZ (because few are caused by inter-tier1 policies) which seems to be the implicit motivation based on Abstract. At the very least, the draft should be much clearer on how this approach is supposed to address the deaggregation issues mentioned in the Abstract, or if that's not the goal, the abstract should be rewritten. Btw: the spec should define that (and how) a neighboring router checks that the {-14,112} +/-operation has happened within acceptable limits. The problem of not doing that is mentioned in passing in security considerations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft-van-beijnum-idr-iac-00 Iljitsch van Beijnum
- [Idr] draft-dickson-idr-second-best-backup-01 Brian Dickson
- [Idr] draft-dickson-idr-second-best-backup-02 Brian Dickson
- Re: [Idr] draft-van-beijnum-idr-iac-00 Pekka Savola
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Brian Dickson
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Enke Chen
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Brian Dickson
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Robert Raszuk
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Brian Dickson
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Brian Dickson
- Re: [Idr] draft-dickson-idr-second-best-backup-02 Uli Bornhauser
- Re: [Idr] draft-van-beijnum-idr-iac-00 Iljitsch van Beijnum
- Re: [Idr] draft-van-beijnum-idr-iac-00 Danny McPherson