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

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 6 Jul 2009 14:59:28 +0200

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.

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.

Comments from authors on the above would be appreciated.

Kind regards,
iLya

---

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Mon, 6 Jul 2009 14:34:26 -0400

Comments In-Line 

Jim Uttaro 

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

Hi,

> 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.

> 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?

Kind regards,
iLya
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 9 Jul 2009 09:02:24 +0200

Jim,

please see further comments/questions inline. 

> -----Ursprüngliche Nachricht-----
> 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 

This sounds contradictory to the fact that AIGP will/should be enabled only within common administrative area. Since it's same administrative area with the same policy, why would AIGP evaluated differently from router to router? Also, if AIGP mimics IGP cost (as suggested by the draft) then value of AIGP attribute is deterministic across whole contigious AIGP-enabled area. And finally, I believe the draft should (and it does) clearly state how AIGP value manipulated (ever increasing scalar), which prevents inconstistency of AIGP values, and therefore keeps BGP decision process deterministic, across whole AIGP-enabled area.

> 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 

That's excellent! I was also long looking for possibility to propagate "total IGP cost" across different AS's (members of a BGP confederation in my case). And if it's something based on IGP cost, why not evaluate it at about the same point of decision process as original IGP cost? Let me know if you would like me to provide an example how this would work.
 
> 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?
> 

I don't think that administrative authority is an obstacle here. What I meant is not to let AIGP traverse across global internet unrestricted, but that within single administrative authority it should be possible to apply AIGP to any prefix that has to be routed within that administrative domain. For example, consider a prefix was learned from a foreign network (outside of considered administrative domain) by one AS in London, then propagated into second AS (within same administrative domain) in Hamburg and Frankfurt. Within this second AS there is a router in Berlin connected to both Hamburg and Frankfurt, which wants to send traffic to that foreign network. If AIGP is not allowed to be applied to foreign prefixes, then router in Berlin decides to send traffic via border router in Frankfurt because of IGP cost within its own AS. This traffic then goes into first AS which due to topology has to send traffic to London via Hamburg anyway. So the traffic has incured extra delay and wasted link capacity. Now if AIGP would have been allowed on foreign prefixes, then router in Berlin could see total IGP cost (==AIGP) and would choose to send traffic straight via Hamburg because AIGP for that path would be smaller than via Frankfurt. This kind of scenario is very similar to how MED is used by many networks - even if there is no mutual agreement about comparable MED between two administrative domains, each of them is still free to set any MED on any prefix (own or foreign) within its own network. Why not permit the same for AIGP?

Regards,
iLya