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

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 Feb 2003 10:46:23 +0100

I have finally read Iljitsch draft above.

(yes, the slopes are closed due to the heavy snow fall so I have 
nothing better to do..:) )

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

Another problem I see is that this requires networks that logically map 
fairly well into the physical topology, or even small networks gets 
complicated. 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.

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?

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. This is not even in the security 
considerations section. It should be.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Feb 2003 10:47:22 +0100 (CET)

> I have finally read Iljitsch draft above.

Thanks for taking the time to provide feedback!

> 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

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

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

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.

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

> incident seem like trivial.

No.

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

No.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Feb 2003 09:34:44 +0100

> What do you mean by keeping it up to date?

Well, ISPs and large enterprises normally use some form of policy 
routing, even if it being hot-potato. With this, I would most likely 
need to maintain my iBGP to send traffic to the "right" prefix, via the 
right exit. Especially if I span several areas. Today this is per peer 
which is somewhat simpler.

> impact. VPN is not a part of regular BGP.

True, but it is still in use. As for multicast you still need to find 
the next-hop information for PIM you need to do the RPF.

> present themselves) to their upstream ISPs.

Yes, but what if I cover several regions? I.e I am not a small network?

> with that: just de-integrate them.

Agreed. From what I know many people have deployed more or less full 
meshed networks with MPLS.

>> incident seem like trivial.

Uhm, why not?

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

- kurtis -