Subject: [Idr] IAC draft

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jul 2009 13:26:44 +0200

Hi all,

In San Francisco, we presented our IAC draft

http://tools.ietf.org/html/draft-van-beijnum-idr-iac-02

in the grow wg. Unfortunately, we didn't get much in the way of  
feedback. As such, we haven't updated the draft. We've been working on  
it for a year and a half, and after some iterations we think it's in  
good shape content-wise. So now it's time to make a decision on how to  
go forward. There are basically three options:

1. adopt the draft as an idr working group item
2. independently submit the draft to the RFC Editor for publication
3. stop this work and don't publish

(Status would be most likely be experimental.)

We would like feedback on which option you all think is appropriate,  
especially from those of you who are in the position to implement or  
not implement the mechanism.

Thank you,

Rolf & Iljitsch

---

From: David Freedman <[email-masked]>
Date: Fri, 03 Jul 2009 13:29:25 +0100

Just a quick question, understanding that you have revised the
path selection statement in this version:

"In the BGP route selection algorithm, the IAClocal is compared
   immediately following the comparison of the IGP cost."

Can I just ask why not just before the IGP cost? what is the use of
doing so afterward?

I think this would be more of a useful tool if done beforehand, the
"lowest IGP cost to next hop" is frequently a problematic metric to use
because it depends on many factors, most importantly, where you are in
the network (especially when you have sparsely placed RRs doing the
selection on your behalf!)

If as you say the implementer provides a feature to remove the IAC
on ingress/egress (despite being off by default), is this really a big
issue?

Dave.

Iljitsch van Beijnum wrote:
> especially from those of you who are in the position to implement or not
> implement the mechanism.
> 
> Thank you,
> 
> Rolf & Iljitsch
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 3 Jul 2009 14:48:52 +0200

> Can I just ask why not just before the IGP cost? what is the use of

In earlier versions we did this earlier, but then there is the issue  
that if you update the routers in an AS to look at the IAC, the  
traffic flow will be very different after this update. That makes the  
mechanism hard to deploy. This would also break the hot potato by  
default behavior in BGP, which is likely to be unpopular in large ASes.

Last but not least, because the IGP cost is increasing, it avoids iBGP  
loops. If we overrule this in some routers (that have IAC) and not  
others (don't have/disabled IAC) we introduce the risk of iBGP loops.

> selection on your behalf!)

I can imagine that route reflectors would have a "ignore IGP cost"  
switch, as the real IGP cost on the routers that use the RR's best  
path will be different anyway. Do you think that would solve your  
issues while maintaing iBGP-loopfreeness, or do you think it's  
necessary to go further?

> on ingress/egress (despite being off by default), is this really a big

In general, I would like to be able to filter any and all attributes,  
especially unknown ones. It's just a matter of time until some clown  
adds unknown transitive path attributes to a route that make the BGP  
message 4090 bytes long so the router 3 hops down explodes after  
adding its AS number to the AS path.

However, for the IAC it's important that the attribute is carried by  
ASes that don't support it themselves and/or have no need for it  
themselves so that ASes further away can make use of it. So off by  
default is essential. I hope that just the availability of the knob  
wouldn't be enough for people to use it indiscriminately. As such, I  
would rather see a general purpose filter that allows filtering any  
attribute, even unknown ones.

Iljitsch

---

From: David Freedman <[email-masked]>
Date: Fri, 03 Jul 2009 13:56:30 +0100

Iljitsch van Beijnum wrote:
> that if you update the routers in an AS to look at the IAC, the traffic
> flow will be very different after this update. That makes the mechanism
> hard to deploy. This would also break the hot potato by default behavior
> in BGP, which is likely to be unpopular in large ASes.

Understand, but usual trade-off with these enhancements between
stability and usefulness.

> switch, as the real IGP cost on the routers that use the RR's best path
> will be different anyway. Do you think that would solve your issues
> while maintaing iBGP-loopfreeness, or do you think it's necessary to go
> further?

RR behaviour is important, AIGP ( draft-ietf-idr-aigp.txt  ) I believe
has a similar problem ?

> message 4090 bytes long so the router 3 hops down explodes after adding
> its AS number to the AS path.

> attribute, even unknown ones.

Agreed, this would be nice , draft-ietf-idr-optional-transitive is doing
work towards error handling inside these

Dave.