Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming]

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 1 Apr 2003 12:27:35 +0200

>> It just doesn't seem to be enough fleshed out to say much other than
>> "ouch! I don't really understand the idea, but it still gives me 
>> creeps!".
>
> What's so hard to understand??? In the US you create an aggregate 
> route for the US address block and you accept /48s for US 
> destinations. In Europe, you create an aggregate for the European 
> address block and accept /48s for European destinations. So when you 
> have a packet in the US that needs to go to a European destination, 
> you don't have a /48 route so the packet is routed to Europe by means 
> of the aggregate. In Europe, the packet is routed further as per the 
> /48 that is in the routing tables of European routers. Rinse, repeat.

I would still like to second Pekkas request on an example with AS:es 
instead of routers.

What I am not sure I understand is who would have to provide the 
transit between the AS:es for these /48s? Also, what do you do with 
Tier-1 providers and customers that are multihomed to different 
continents?

Could you write a bit more detailed example?

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Tue, 1 Apr 2003 16:52:03 +0300 (EEST)

Sorry for the delay, was occupied.

On Mon, 31 Mar 2003, Iljitsch van Beijnum wrote:
> On zondag, maa 30, 2003, at 21:40 Europe/Amsterdam, Pekka Savola wrote:
> 
> > But really, the problem is that I'm having hard time (and based on the
> > lack of enthuasiasm from the others, the rest as well)  figuring out
> > whether the model could be useful and whether it could actually work.
> 
> It allows around ten million multihomed networks, so that answers the 
> useful part. Nobody has ever pointed out any aspect that presumably 
> wouldn't work (just stuff they aren't real comfortable with) so either 
> I am as smart as I think or nobody wants to take the time to carefully 
> read the draft.

You know, when the document quality is not as high as one could hope, and
a new concept is introduced, it's also a matter of writing the idea
clearly.  Especially, starting with clear introduction, easy-to-understand
picture, etc. -- answer the question "how is this different from other geo
proposals".  People, under these circumstances give up after N pages when
you don't get into business quickly enough.

It's easier to find the gold if the map is easy to understand.  Sometimes 
you don't have a map or it's very difficut to read...

> What's so hard to understand??? In the US you create an aggregate route 
> for the US address block and you accept /48s for US destinations. In 
> Europe, you create an aggregate for the European address block and 
> accept /48s for European destinations. So when you have a packet in the 
> US that needs to go to a European destination, you don't have a /48 
> route so the packet is routed to Europe by means of the aggregate. In 
> Europe, the packet is routed further as per the /48 that is in the 
> routing tables of European routers. Rinse, repeat.

Flesh it out, in simple terms (the pic in the draft is too complex).  Try
to use AS's if that's possible.

A particular point I'm not sure would work out is how you deal with backup 
connectivity.  An example:

 upstream  upstream (US?)
   |         |
[router2]-[router3] 
 |   \      /
 |    \    /                       .---- other
 |     [router1]  ---- exchange --/----- routers
 |        /                       \----- from the
[ISP backbone]                     \---- region 

Now, if you install the aggregate for the region in router1 and block more
specifics at router2 and router3 (from upstreams and internally), now what
if router1 or the link to the exchange fails?  How do you get the routes
through your upstreams?

> > If you want to avoid that feeling, you must warm up the folks properly 
> > :-)
> 
> So how do I do that? Buy everyone drinks at the IETF meetings?

Try a good introduction in the draft, answering the critical questions 
(how is this different, how does it work in principle) plus a clear, 
simple pic or two.
 
> > "if you can't have the same routing table in all of your routers in a
> > single AS while being part of the DFZ, your architecture or the 
> > definition
> > of AS is broken"
> 
> Ok, then OSPF and IS-IS explicitly support broken networks...

IGP's are entirely different beasts with different functionality.
 
> > In the proposal, where are the more specific advertisements hidden?
> > Being advertised between different AS's at peering points but hidden in
> > your that particular peering router by an internally advertised 
> > aggregate?
> 
> Not sure what you're getting at.

_someone_ must have the more specific routes.  you can't just toss the 
routes around.  Sure, you could build the internet routing architecture 
with manual aggregates or default routes, even, but that would be 
horrible, especially if a router or link goes down.

> >> I'd say it's the other way around: if your architecture requires
> >> you to keep information about the entire world in all routers, you've
> >> painted yourself into a corner.
> 
> > I can agree with that (which is the addressing model Tony is proposing
> > with his geo proposal, btw.) -- if it's required, but I'd like to avoid
> > it.
> 
> But just now you said you wanted to be able to have the same routing 
> info in all routers! You can't have it both ways.

In all routers in _my AS_.
  
> >> I'm considering an update to the draft, but as far as I can tell
> >> everything is in there.
> 
> > Doesn't seem to be particularly unenlightened-friendly.. :-/
> 
> Tell me what's missing and I'll put it in.

I hope I made a few pointers above.  Clear introduction, summary of the 
operation etc. would be nice starting points.
 
> >> Actually Tony's draft is just an addressing scheme which doesn't
> >> automatically solve routing.
> 
> > I'd be very very careful of any mechanism which claimed would solve
> > routing automatically.
> 
> I don't mean solving all routing problems forever, just that Tony's 
> scheme needs additional routing stuff to do something useful.

Sure, it needs a bit of work .. but the concept of someone advertising an 
aggregate seems clear -- not necessarily acceptable or a good idea
considering all the different implications (many of them non-technical), 
but still understandable, to an extent.

> >> Cooperation from other ISPs is not needed: everyone can implement or
> >> not implement this as desired, just as long as the RIRs give out the
> >> addresses based on geography.
> 
> > Forgive me for sounding skeptic, but I'm not as sure without further
> > analysis that no cooperation would be required.
> 
> What exactly would another ISP have to do so I can aggregate within my 
> own network??? If I want to accept all routes within 195.0.0.0/8 in 
> Amsterdam, all routes within 196.0.0.0/8 in London and so on, I can do 
> that without cooperation. (I have to deaggregate if I don't peer in 
> London with someone who announces 196.12.34.0/24, though, but that's 
> still something I can do on my own.)

What about when your router or a link in london or amsterdam goes down?  
where do you go to networks in 195/8 or 196/8 then?  This was one of the 
points in message "Sun, 30 Mar 2003 20:37:07 +0300 (EEST)".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 1 Apr 2003 16:16:19 +0200

On dinsdag, apr 1, 2003, at 12:27 Europe/Amsterdam, Kurt Erik Lindqvist 

> I would still like to second Pekkas request on an example with AS:es 

The AS view is exactly the same as today: each AS announces its 
customers (and customer's customers) to peers and upstreams.

> transit between the AS:es for these /48s?

It seems the word "geography" carries a lot of baggage in this context. 
Forget all of that. The only thing I want to do is remove routing 
information from the places where it doesn't actually help routing.

To answer your question: the transit relationships would be identical 
to what happens with PI today. So if A is a customer of B which is a 
peer of C which has a customer D, the traffic would still flow A -> B 
-> C -> D and D -> C -> B -> A. However, if A is in Seattle and D is in 
The Hague, today the A -> D traffic would be flow from B to C close to 
the origin, so probably somewhere in the bay area. The D -> A traffic 
would also flow from C to B close to the origin, probably in Amsterdam.

With provider-internal geo aggregation B would no longer have the route 
for D in routing tables on the US west coast. (C would still announce 
this route there, as C doesn't know how B aggregates internally.) So 
the traffic for D will be routed according to an aggregate. This could 
be a route for all of Europe, or the Netherlands or The Hague. Then at 
some point the packet arrives on the US east coast, in Europe, NL or 
The Hague, and there the /48 is in the routing table and the packet is 
transferred to C.

>  Also, what do you do with Tier-1 providers and customers that are 
> multihomed to different continents?

There are three cases:

1. Geographically diverse organization that doesn't want to use its 
private network for "internal transit" (having ISPs transport the 
traffic to the right location is cheaper): simply use GAPI addresses in 
each location. This means that each location must multihome 
independently.

2. Geographically diverse organization that wants to use its private 
network for "internal transit": they are assuming an ISP role here so 
they should get their own PA block. Note that this means the entire PA 
block is announced in each location so lots of internet traffic 
traverses the private network.

3. Organizations that use long distance links to connect to the net. A 
good example would be satellite links. There is no good solution for 
this situation: either the organization breaks aggregation or it uses 
addresses from the "landing site" geo address block rather than the 
user site geo address block.

Note that not solving 100% of all cases isn't a problem: we don't need 
a 4k routing table, we just need to avoid a 4M routing table. A 400k 
routing table in the year 2008 or so would be just fine. So we can 
still allow a reasonable number of all multihomers to break aggregation.

> Could you write a bit more detailed example?

Is the above what you need?