[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> 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