Re: [Idr] draft-rosen-idr-aigp-00

Robert Raszuk <robert@raszuk.net> Mon, 30 March 2009 07:13 UTC

Return-Path: <robert@raszuk.net>
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 2FDCE3A693B for <idr@core3.amsl.com>; Mon, 30 Mar 2009 00:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 vNQ1qD3nQZmh for <idr@core3.amsl.com>; Mon, 30 Mar 2009 00:13:16 -0700 (PDT)
Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 538EB3A683E for <idr@ietf.org>; Mon, 30 Mar 2009 00:13:16 -0700 (PDT)
Received: (qmail 17117 invoked by uid 399); 30 Mar 2009 07:14:13 -0000
Received: from unknown (HELO ?192.168.1.55?) (83.24.10.85) by mail37.opentransfer.com with SMTP; 30 Mar 2009 07:14:13 -0000
Message-ID: <49D0713F.2020207@raszuk.net>
Date: Mon, 30 Mar 2009 00:14:07 -0700
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Jeff S Wheeler <jsw@inconcepts.biz>
References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> <49CEC525.9040306@raszuk.net> <1238397020.31558.53.camel@guardian.inconcepts.net>
In-Reply-To: <1238397020.31558.53.camel@guardian.inconcepts.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr@ietf.org
Subject: Re: [Idr] draft-rosen-idr-aigp-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert@raszuk.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/mail-archive/web/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>
X-List-Received-Date: Mon, 30 Mar 2009 07:13:17 -0000

Hi Jeff,

>> * I think that making new attribute is clean indeed, but a bit risky to 
>> touch your best path selection algorithm each time new attribute is 
>> invented to influence best path decision.
 >
> How do you propose to make the algorithm aware of future attributes that
> have not been invented yet?  If I want to do bestpath decision based on
> who has the coolest ASCII-art in their advertisement, just assuming that
> I have an army of stick-man art critics in my basement, how can you
> write spec or software to anticipate that need until I thought of it?

http://tools.ietf.org/html/draft-retana-bgp-custom-decision-00

    This document defines a new Extended Community [EXT_COMM], called the
    Cost Community, which may be used in tie breaking during the best
    path selection process.  The end result is a local custom decision
    process.

...

    The network administrator may use the Cost Community to assign a
    value to a path originated or learned by a peer in any part of the
    local domain. The Point of Insertion may also be specified using the
    values defined in the IANA registry [BGP_PAR] or this document.

    If a BGP speaker receives a path that contains the Cost Community, it
    MUST consider its value at the Point of Insertion specified, when
    calculating the best path [RFC1771].

R.