Re: [RRG] Idea for shooting down

[Brian Carpenter <[e-mail]>]

[Resend due to
This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

      [e-mail]

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 13): 550 deferred because 209.85.198.185 is in  a black list at qil.mail-abuse.com]

On 2007-11-20 18:08, Robin Whittle wrote:
> Hi Brian,
> 
> With your proposal:
> 
>   http://www.cs.auckland.ac.nz/~brian/DFZng.pdf
> 
> I get the impression that the result would be the Internet being
> much less meshed than it is at present. 

Not exactly. The individual regions can be as meshed as one
wants, and they are *not* geographical regions - in fact they
are more likely to evolve as conglomerates of ISPs.

> This would have negative
> impacts including:
> 
> 1 - Less robustness in the event of link and router failure.

As noted in the draft, there can be multiple links between
layers - as many as desired, in fact.

> 2 - Often longer path lengths (AKA "stretch") as a packet has to
>     get out of one of the many Level 1 domains (or the one Level 0
>     domain) up to some Level 2 domain in order to get to another
>     Level 1 (or the Level 0) before it could be delivered.  This is
>     true even if the ISP border routers connecting to the sites with
>     the sending and receiving hosts are physically close, but happen
>     to be of ISPs which are in separate domains.  (I assume an ISP
>     can only be in one domain, but perhaps I am wrong.)

Definitely more stretch. But that may be inevitable as we grow towards
ten billion hosts.
> 
> 3 - Therefore, further dimensions of "Balkanisation" of the
>     Net, where actual packet delivery times and reliability
>     levels depend not just on physical (partly geographic)
>     topology, link capacities and traffic levels but also on
>     which domain each host is in and how far the packet has to
>     travel to go up and then down a level to the destination
>     domain.

I don't see why that is Balkanisation, which implies walled gardens
to me. I would counter this and the previous two arguments with the
assertion that an organised hierarchy of finite meshes is intrinsically
easier to understand and debug than a single unbounded mesh.
> 
> 4 - Therefore, a lot of fuss as ISPs try to decide which domain
>     to be in.

I don't see this as being that much different from today's fuss
as ISPs decide who to peer with.

> 
> 5 - Also, perhaps, more pressure on "sites" (as I think you
>     nicely describe them) to multihome to various ISPs in
>     different domains.  However, that only helps with the
>     path length if the "site" is smart enough to send outgoing
>     packets to the optimal ISP's router.  This wouldn't help
>     with optimising which ISP and region an incoming packet
>     arrives through when it is sent by a non-multihomed site
>     or a multihomed site without the smarts to choose the
>     best outgoing router.

I don't see this as any different from a site's point of view than
today. The sites will perceive ISPs, not regions. They have all those
issues today.

> Also, I don't understand how your proposal would help with the
> central problem we are trying to solve - of a multihomed site's
> router requiring a separate route for every prefix advertised by any
> site anywhere at all.
> 
> The fact that the destination site is in a different domain doesn't
> alter the fact that the multihomed site's router needs a separate
> route for that slice of address space, because the router still
> needs to decide which of the two or more upstream ISP routers to
> forward the packet to.

As I said, this idea is *orthogonal* to LISP, Ivip, etc. We
definitely  need a robust solution for exit router selection
that doesn't require full routes. I haven't had time to analyse
draft-baker-6man-multiprefix-default-route-00 yet, but we need
something with that degree of simplicity and robustness.

    Brian

--
to unsubscribe send a message to [e-mail] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg