[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Idea for shooting down
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?
>> 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.
>> 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.
>> 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.
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
> 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.
>> 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)?
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. 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.
to unsubscribe send a message to firstname.lastname@example.org 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