headers
Kurt Erik Lindqvist | 1 Apr 12:27
Picon

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

>> 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 -
Permalink | Reply | 1 comment |
headers
Dorian Kim | 1 Apr 13:07

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

On Sun, Mar 30, 2003 at 09:12:56PM +0200, Iljitsch van Beijnum wrote:
> 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.

I guess if one stays around long enough, one gets to see all old arguments 
rehashed, regardless of how definitive the result of the last round was.

Geographical address assignment and aggregation was discussed extensively 
and rejected in big-internet mailing list circa 1994-5 during the
discussions leading up to the publication of RFC 2008.

The list archive is available at ftp://munnari.oz.au/big-internet/list-archive 

I believe there were also discussions on cidrd wg mailing list on the same
topic around the same time.

-dorian
Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 1 Apr 15:16
Favicon

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

On dinsdag, apr 1, 2003, at 13:07 Europe/Amsterdam, Dorian Kim wrote:

> I guess if one stays around long enough, one gets to see all old 
> arguments
> rehashed, regardless of how definitive the result of the last round 
> was.

> Geographical address assignment and aggregation was discussed 
> extensively
> and rejected in big-internet mailing list circa 1994-5 during the
> discussions leading up to the publication of RFC 2008.

> The list archive is available at 
> ftp://munnari.oz.au/big-internet/list-archive

Cool. I've searched 1994 and 1995 for "geo" and I found a lot of 
debate. However, I did not find any definitive results.
Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Apr 15:52
Picon

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

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

> > 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Apr 16:16
Favicon

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

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

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

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

> What I am not sure I understand is who would have to provide the 
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bound, Jim | 1 Apr 16:30
Picon
Favicon

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

I have been thinking about this but that is ok.  Here is my logic.  When
we designed IPv6 we left many open for discussion parts in the
architecture.  For example scoping of interfaces, multiple
format-prefixes for address architecture, flowlabel.  Solving anyone of
these is a complex undertaking, but could be done later.  I believe it
is fair because of this effort to look at geo addressing again for
Multi6.  It does not break existing implementations or deployment test
beds or those emerging further, but a policy discussion that can have an
affect to implementation but in a backwards compatible manner, and same
with scoping and the flowlabel.   In this case revisitation of the
principles of geo address architecture is in fact valid IMO.

Regards,
/jim

> -----Original Message-----
> From: Dorian Kim [mailto:dorian <at> blackrose.org] 
> Sent: Tuesday, April 01, 2003 6:08 AM
> To: Iljitsch van Beijnum
> Cc: multi6 <at> ops.ietf.org
> Subject: Re: provider-int geo aggr [Re: plug: thesis on site 
> multihoming]
> 
> 
> On Sun, Mar 30, 2003 at 09:12:56PM +0200, Iljitsch van Beijnum wrote:
> > 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.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 2 Apr 00:39
Favicon

Geo pros and cons

In the discussion about geographical aggregation the past days (and on 
earlier occasions) we tend to get into a lot of detail: which routes go 
where, how many interconnects and so on. These are important details, 
and they need to be discussed. But first we need to consider the 
viability of geographical aggregation.

Geographical aggregation has some problems. For instance, it won't 
scale in the long term if we indeed reach multihoming levels of 1 : 10. 
Another problem is that it changes the way traffic flows between ISPs 
(no more hot potato routing).

But the biggest objection against it is that network topologies don't 
match geography, so geography isn't a reasonable basis for making 
routing decisions. I think this is the one we need to tackle.

Now obviously it is possible to lease a circuit to a remote location 
and connect to "the internet" in that location rather than close to 
home. But should we consider this a feature we must support, or is it 
an exceptional situation that we can safely ignore?

Suppose the long distance connection would have been IP rather than 
ATM, SONET or fiber. In that case, a data from customer A of the long 
distance service provider to customer B of the long distance provider, 
wouldn't travel all the way to the remote location and back, but the 
data would be immediately forwarded to the right destination by a local 
router. So essentially we're expecting IP to compensate for the 
stupidity of non-IP networks...

Then there is the argument that interconnection is limited. Yes, this 
is true. Only a small percentage of all internet users live very close
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Li | 2 Apr 01:38

RE: Geo pros and cons


Iljitsch,

|    Now obviously it is possible to lease a circuit to a 
|    remote location 
|    and connect to "the internet" in that location rather than 
|    close to 
|    home. But should we consider this a feature we must 
|    support, or is it 
|    an exceptional situation that we can safely ignore?

Since this happens all too frequently, we must deal with it.  The
Internet is not a centrally run function.  Instead it grows
organically by the needs of the users.  In other words, the links
only show up where they make economic sense.  And those are the
links that users will use, ignoring the consequences.

    
|    Since the scalability of geographical aggregation depends 
|    on the number 
|    of internet users and the size of the aggregation areas, 
|    where each 
|    aggregation area needs at least two interconnects, it 
|    would seem that 
|    the scalability of geographical multihoming isn't a problem: more 
|    multihomers means more routes in an area, but since more end-users 
|    means more interconnects, the areas shrink. So the number 
|    of routes per 
|    area should remain fairly constant.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Pekka Savola | 2 Apr 09:23
Picon

voluntary filtering of more specifics [Re: Geo pros and cons]

One particular point..

On Wed, 2 Apr 2003, Iljitsch van Beijnum wrote:
> Since the scalability of geographical aggregation depends on the number 
> of internet users and the size of the aggregation areas, where each 
> aggregation area needs at least two interconnects, it would seem that 
> the scalability of geographical multihoming isn't a problem: more 
> multihomers means more routes in an area, but since more end-users 
> means more interconnects, the areas shrink. So the number of routes per 
> area should remain fairly constant.

.. depending on who is in charge of the aggregate and the routes, I've 
gotten a personal belief that if we build a system that allows more 
specific routes, we must have a system which can be used to block them 
too.

That is, e.g. longer prefixes from under current 2001 RIR allocations are 
a non-starter; they create a system where advertising more specifics is 
required for multihomers while giving away the control of more 
restrictions of more specifics.  "meant for longer prefixes of a certain 
length" allocations from a separate block would be completely different in 
this regard.

Similar seems to apply to geo-like approaches depending on geo-aggregates.  
Who (at the originating region) is creating the aggregate?  And more 
importantly, *why* should the sites or ISP's in the region be encouraged 
to *not* advertise their more specific geo prefix *anyway* (assuming the 
geo routing infrastructure might require that under some conditions)?  
There would seem to be a need for some control there, or all the traffic 
going through such big ISP's we could trust to do the right thing and not
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcelo bagnulo | 2 Apr 17:14
Picon

RE: Geo pros and cons

Hi Tony,

[...]
> As we concluded many years ago: for addressing to scale, it has
> to match the topology.

Fully agree.
I would say that the question is if topology matches geography or not.

I have heard many claims that the Internet is becoming a dense
interconnection mesh. If this is true, it should be easy to determine
geographical areas that are interconnected, so geo aggregation works
without the need of more specific routes.

I think that this is certainly not the case for all geo locations, but i
would say that it is probably the case for some locations as big cities
where a lot of users reside. Wouldn't geo addressing be suitable for
this situations?

I am not aware of any analysis of how dense is the interconnection in
geo areas, but i would say that this input is important when considering
geo addressing. Does anyone have information about this?

Thanks, marcelo

>   If addressing does not match the topology,
> then additional information in the form of longer prefixes must be
> advertised into the routing subsystem.  Ergo, if one chooses geographic
> address, one must force only geographically based links.  Anything
> else destroys the aggregatability of the address assignment.  Since
(Continue reading)

Permalink | Reply | 0 comments |

Gmane