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

Hi Jim,

I think there are few things which would be great to keep in mind no 
matter how this proposal will move forward.

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

* As defined today AIGP attribute carries an unreferenced sigma of 
metrics. In my opinion it should be referenced by the start point of the 
accumulation which most obviously would be the originator next hop. Best 
path should compare only those AIGP attributes with original next hop 
attached to be equal. Otherwise in deployments in other customer 
networks when AIGP support is partial in the mesh of ASes it is quite 
obvious that it may lead to permanent loops. Any encapsulation (even 
mpls) on a per AS basis will not be a cure at all.

* And to the point you made ... cost community where designed to be 
common tool to modify the best path selection on as needed basis. Do you 
have a different opinion on cost community applicability ? Their design 
is exactly as you require in your case. Yes it would need to accumulate 
MEDs metrics on the AS boundaries, but this is the same as adding new 
values to the new to be deployed AIGP attribute.

Best regards,
R.

> I do not agree. MED is a tool that is used to signal preference between
> two AS domains... The idea of overloading for this purpose would require
> knobs and hacks like "always-compare MED" and accumulating MED etc....
> Cost Community would also have to be modified. It is better to create an
> attribute whose functionality is clear. Use MED and Cost Community for
> the problems the were designed to solve.
> 
> Jim Uttaro
> 
> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Robert Raszuk
> Sent: Tuesday, March 24, 2009 12:15 PM
> To: idr
> Subject: [Idr] draft-rosen-idr-aigp-00
> 
> All,
> 
> I would like to support the suggestion made yesterday by Enke Chen, 
> Keyur Patel and Danny which suggested to make a good analysis for using 
> MED + Cost Community which are an already existing tools to achieve the 
> same functionality as the draft proposed via a definition of a new AIGP 
> attribute.
> 
> In fact the problem described in the draft is a very good example where 
> practical problem can be solved using the above two solutions combined 
> together.
> 
> It can be a very good motivation for restarting work on cost community 
> itself which were last posted draft-retana-bgp-custom-decision-00. There
> 
> are apparently practical cases which this draft has a potential to solve
> 
> and IMHO there is a saving to implement something once and then reuse 
> for various applications as opposed to implementing separate attributes 
> which would at the end result in more burden to BGP and deployment 
> difficulties.
> 
> Cheers,
> R.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
> 