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

Re: [RRG] Idea for shooting down

On 2007-11-21 18:53, Robin Whittle wrote:

Hi Brian,

I had forgotten that your proposal is intended to be orthogonal to
ITR-ETR schemes such as LISP, eFIT-APT, Ivip or TRRP.  I understand
that "orthogonal" in this context means something like "operate
independently of (using different "dimensions"), to achieve similar
and/or other objectives".

Assuming there is an ITR-ETR scheme which successfully limits the
number of prefixes in the current single DFZ (to some acceptable
number, the same, somewhat higher or lower than the current ~240k),
what benefits would your proposal provide?


None. But historically, routing swamps have a habit of emerging
spontaneously. This is an idea of how to take the sting out of that.


You wrote:


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.


I got the impression from the text and diagrams that no ISP in a
Level 1 domain could link to any other ISP in any other Level 1
domain - that the packets would have to flow via a Level 2 domain,
in the simplest instance.


Correct. But remember it is a virtual topology; it doesn't need
to add more than one hop to the real topology, if such a connection
is needed. I do assume that ISPs which happen to exchange a lot
of traffic will end up in the same region - very likely the regions
would emerge in existing economic blocs, with the primary driver being
economic, rather than geographic or topological, nearness.




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.


There could be, but since there are now multiple domains, with
restrictions on what each ISP in each domain can link to (as best I
understand it) then this would surely reduce the opportunities for
meshing compared to the current situation where there is only one
"domain" and any ISP can link to any other ISP.


Yes. But that may simply be the price of scalability.




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.


ITR-ETR schemes with well placed ITRs and ETRs don't necessarily
involve longer path lengths.  In many or most cases, once the system
is widely adopted, I think there would be no extra distance or
number of routers for most packets.


Well, you don't know that a priori. If we use something like GRE
you actually have no control at the ITR-ETR level over how many
actual routing hops are involved in the GRE tunnel.


Your system, as I understand it, involves restrictions on which ISP
can connect with other ISPs, so the total system is going to be more
hierarchical, branched and compartmentalised than would be the case
with a single domain, as exists today.



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.


I didn't mean "walled gardens" - just more like your Step 4 diagram,
in which, as I understand it, an ISP in the bottom right Level 1
domain can't connect - or finds it more complex and therefore
expensive to connect - to an ISP in the bottom middle Level 1 domain.

I doubt that conceptually and practically more complex arrangements
lead to greater ease of understanding and debugging.  The ITR-ETR
schemes all introduce a roughly similar new set of architectural
arrangements in terms of address space, ITRs, ETRs etc. which will
make the total Internet harder to understand and debug.  These
schemes are only being contemplated because we perceive a
prohibitive scaling limit in the DFZ if we don't implement such a
scheme and the number of end-user networks (and ISPs too) continues
to grow as we expect.  These schemes are being contemplated just to
keep the Internet running with its current hosts and most of the
current BGP routers untouched - not because the result will be
simpler or easier to debug.


Which is worrying in itself.

I would maintain that a hierarchy is conceptually and practically
simpler than an ever-growing mesh. There's a systems engineering
tradeoff here.





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.


Can an ISP be in two domains at the same time?  Can an ISP be in two
or more Level 1 domains?  Two or more domains of different levels?
In the Level 0 (existing DFZ) and in some other domain(s)?


I think an ISP would have to operate two ASes to be in two domains
at the same time. I need to think a bit more about shortcut routes
in such a case (i.e. violating the separation of regions). It seems
likely that if a packet shows up in the "wrong" place, there's no
reason it can't be routed further through the system (but some
thought is needed about spoofing and loop-prevention).



If the answer to any of these questions is negative, then I think
your system imposes more restrictions on how ISPs can connect to
other ISPs, which I think would lead to more fuss.  Likewise if the
answers are all "yes - but only with extra costs or complexity".



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.


My first sentence refers to my perception that each site will want
to connect to several ISPs in several different domains, in order to
maximise diversity for multihoming robustness. 

If I'm right that regions would emerge in economic blocs, this would
really only arise for the truly international companies that connect
their company networks to the Internet in many different geographic
regions today; the IBMs of this world. These are all sophisticated
BGP4 users already - the worst case, I think, is that they would have to
operate multiple ASes (as suggested above for cross-connected ISPs).


The second and third
sentences refers to my understanding that the overall path lengths
are going to be longer with your scheme, since ISPs in general are
less meshed - although theoretically a multihomed site could be
smart enough to know which of the upstream ISPs was closest to the
destination of each outgoing packet, and so could to some extent
reduce the general path-lengthening effect by forwarding the packet
to the optimal outgoing link.


Which the internationals already do.

    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