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

["UTTARO, JAMES, ATTLABS" <uttaro at att.com>]

Comments In-Line 

Jim Uttaro 

-----Original Message-----
From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
Ilya Varlashkin
Sent: Monday, July 06, 2009 8:59 AM
To: idr at ietf.org
Subject: [Idr] draft-ietf-idr-aigp-00

Hi,

I've read through draft-ietf-idr-aigp-00 and find the idea quite good.
In fact it was long on my wish-list since as necessary tool to optimise
routing within BGP confederation. There are couple concerns, however,
regarding details of proposed functionality.

First, section 4.1 sugests to evaluate AIGP before LOCAL-PREF.
Considering that AIGP is close in ist nature to IGP cost, it seems more
natural to evaluate it right where IGP cost is evaluated. One
possibility could be: if a route has AIGP attribute with value X, then
add X to IGP cost of the NEXT_HOP and use result as tie-breaker instead
of plain IGP cost. It should be noted that if BGP implementation has
knob to consider length of CONFED_SEQUENCE and it's turned on, then
length of CONFED_SEQUENCE will take precedence, so if operator wants to
use AIGP they should consider turning off CONFED_SEQUENCE length knob.

> A route with the AIGP attribute must be evaluated in a consistent
manner across an AS or multiple AS domains. If the AIGP attribute is
being used, and each BGP speaker could override AIGP via LP or some
other metric ( AS-PATH, MED etc... ) this would lead to a great deal of
uncertainty about how any one route could be evaluated. High probability
that the same route will not be evaluated the same way by each speaker
that has agreed to use AIGP. Just to circle back. A method for scaling
an IGP that contains thousands of PEs is to divorce the signaling of PE
LBs within and across AS domains from the underlying IGP. The PE LBs are
propagated using BGP w/label ( 3107 ). The rationale ( my need ;) ) for
AIGP is to allow for an "IGP" metric ( latency ) to be propagated with a
route that is being exchanged between multiple AS domains or within an
AS Domain where BGP is used as the signaling protocol.  In today's world
there are various methods to exchange this info between two AS domains
but not three, four etc... None of the current methods meet the
requirements.

Second, section 3.3.1 explicitly forbids adding AIGP to routes learned
from outside of AS. From operational prospective this rips off most of
the benefits that AIGP could provide. If a route learned by two
confederation member-AS are then injected into third member-AS, it would
be benifical to choose best of them based on AIGP value but the draft
won't allow this. Seems like serious drawback.

> This comes back to the single administrative authority. AIGP is not
appropriate where two administrative authorities have not agreed across
both AS domains to use AIGP. Are you describing two distinct admin
authorities? If not, why would'nt the AIGP attribute be originated to
begin with in the original confederation member AS domains?

Comments from authors on the above would be appreciated.

Kind regards,
iLya
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr