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