[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Idea for shooting down



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

Delivery to the following recipient failed permanently:

     rrg@psg.com

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 rrg-request@psg.com 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