Re: Comments on draft-van-beijnum-multi6-isp-int-aggr-00.txt

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote:

> I have finally read Iljitsch draft above.

Thanks for taking the time to provide feedback!

> What first strikes me is the complexity of the iBGP and keeping this up
> to date.

> I am not convinced that this is workable from a ISP point of view,

I agree that it's a hassle, but it's not all that complex. It is
basically similar to running OSPF with area aggregation. Larger ISPs
already have complex BGP setups with route reflectors and/or
confederations and redistribution. This proposal is on the same level of
complexity.

What do you mean by keeping it up to date?

> but
> I want to think that over more. I am also not sure how "extras" in BGP
> (which I am not sure should be there in the first place) such as
> multicast and VPN information, would work.

Multicast uses a separate routing table so there shouldn't be any
impact. VPN is not a part of regular BGP.

> Another problem I see is that this requires networks that logically map
> fairly well into the physical topology, or even small networks gets
> complicated.

Small networks are unlikely to use internal aggregation: it's more
likely they'll just send traffic for certain regions (where they are not
present themselves) to their upstream ISPs.

> This means that the MPLS crowd will have a problem (hey -
> maybe I do like this proposal! :) ), but so will also corporations that
> have few branch offices across the world connected with a IP-VPN or
> slow speed links.

I'm not sure what kind of problem you see here. I am unfamiliar with the
way MPLS is really deployed in networks so I can't say anything about
that except that if the worst part about this protocol is that it makes
it impossible to provide integrated IP and MPLS services I can live
with that: just de-integrate them.

> Something else that I haven't really figured out, but how will path
> loop prevention be done? If I understood the draft correct, as there is
> not full view, you can only look if a AS is present twice, but you
> could still see the route twice, no?

This is still regular BGP so no special loop prevention magic. There is
a section in the draft that warns about routing loops if there are
network partitions. This can happen with any kind of aggregation. The
answer is always: build your network so that it doesn't partition.

> Last, what worries me the most is the security considerations. A
> failure on filtering, or in routing configuration will make the AS7777
> incident seem like trivial.

No.

> This is not even in the security considerations section. It should be.

No.

Iljitsch