North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi homing pressure

  • From: Owen DeLong
  • Date: Fri Oct 21 02:45:50 2005

Because of the number of misconceptions of my idea presented, I'm posting
this to the list. Those uninterested, feel free to ignore. Those interested,
feel free to follow up with me directly. After this, I will not be continuing
this on the list unless there is significant interest from multiple parties.


--On October 21, 2005 12:12:22 AM +0200 "Elmar K. Bins" <[email protected]> wrote:

[email protected] (Owen DeLong) wrote:

Why wouldn't rewriting work?  The "encapsulation" you show below
is little different from the rewrite I propose.
Except that it conserves the original addressing information,
which I believe to be important.

Look at what I proposed again... My rewrite does NOT modify the original
addressing, it ADDs data to the header.

First, let's
start with something that looks a little more like an IPv6
You're only talking v6? Why? Anyway, let's follow this through...

Because we don't really need to solve this in V4.  V4 multihoming is
well understood and is unlikely to hit a scaling limit on router
capabilities before we hit an end of life on address space.

[DST: ::B Src: ::A EXT[RLI: Z] Prot: ICMP [...]]]

Then, Upon arrival at the first Router within AS Z, the packet
is rewritten again:

[Dst: ::B  Src ::A Prot: ICMP [Type: Echo Req [Data: ...]]]
You have used special fields in the IP header. Well, that's
an elegant way to do it _if_ you have this field. You do not
have this in IPv4, and that's what we'll be stuck with for
the next couple of years, unfortunately (or not: I can remember
v4 addresses much more easily...)

Again... Multihoming already works in V4 and there is no real need
to solve this in the V4 world.

final packet arrives unchanged.  Further, any router along the
way that doesn't understand the Extension header doesn't have
to really look at it, so, during transition, routing can occur
on either RLI or Dst.  If you encapsulate, you lose that
transitional ability.
Good point you have here.

Actually, even that isn't necessarily an accurate characterization
of what I am suggesting.  The packet should not be rewritten
until it reaches a DFZ router outside of AS Z.  Whether that
is within AS Y, or somewhere upstream (possibly more than
one level upstream) of AS Y, that's where the initial rewrite
should occur ideally.  If the first DFZ router doesn't yet
know about RLI, however, then, the first RLI aware router
in the DFZ prior to reaching AS Z should do the rewrite.
I see a couple of shortcomings to your idea:
  - it is limited to an IP protocol that carries a RLI header field
  - you only include one RLI in the packet header

You only need one RLI in the packet header.  More would actually be
bad.  Let me 'splain.  If you are routing on RLI, then, you need
to choose the best path and stick to it.  If the packet doesn't
make it through that way, that's OK... That's what retransmits are
for.  If you start rerouting it on the fly, it's likely to loop
a lot before dying, but, little else is achieved.  Worse, it's
likely to loop even if it might have gotten there given one path
and only one path chosen as best by the RLI inserting router.

I do neither believe that we'll get rid of v4 soon, nor do I think
it is a good idea to let the sender decide to which RLI to route
the packet. The benefit of multihoming is lost then.

No, it is not.  Since the RLI inserting router has up to date dynamic
information about which RLIs are reachable and at what cost (BGP
distance vector data), you have the same overall effect as dynamic
routing today.  Just instead of trading prefix routes everywhere,
you trade AS reachability info everywhere and map prefixes to

Um... No... You don't want multiple RLIs in the packet.  You want
the router inserting the RLI to have the ability to chose from
multiple RLIs.
Definitely not.

Definitely so.

If you start playing with changing RLI along
the way, then, you run into serious difficulty with looping
That is not intended. Another way to avoid loops must be found,
and I believe the danger is pretty small. The RLIs in the packet
are not changed in transit. But of course every new router can
choose towards which RLI to send the packet. Luckily, distance
on a working path in the Internet generally decreases as you
approach a target you have chosen. I do see that there is a
danger of looping, but I believe a way to detect that can be

Why.  Why not keep it simple and recognize that when routing changes,
some packets get lost during the shuffle.  This is the way it is
today, and, this wouldn't be any worse with this system.  Also, this
means that loop detection continues to work essentially the way it
does today, and, it doesn't require near as much new code or protocol
support as what you propose.

By choosing an RLI close to the source that,
at the time of selection, had a valid dynamic advertised (BGP)
AS Path for reachability, you seriously reduce the likelihood
of looping the packet.
Yes, but you lose the benefit of multihoming, because the
rewriting edge router may carry outdated information or
simply make a "bad" choice. I'd rather have routing intelligence
in the core than in the edge.

No.  You have nearly the same advantage you have today.  If
the path goes away, then, hopefully by the time of retransmit,
the RLI inserting router will have learned that that RLI destination
is no longer reachable, and, he will insert a different one in
the retransmitted packet.  Same as what happens today with the
retransmitted packet being sent a different way.

> If B is multihomed, I am not in favour of A (or X) selecting the
> location of B to be used. I believe the routing system should
> be able to determine that, like it's done right now.
Look... The first DFZ router selects the location of B to be
used in todays world, why should this change?
I am not sure why you believe that the firsts DFZ router that
is being traversed does the choice today. In paths like (from
source to multihomed-target):


Who exactly chooses? IMHO it's AS B that does the selection.
And: B is closer to the target, aka the source of the routing
information. Its BGP table is more probable to be up-to-date.

Right... B is the first DFZ router.  A is not likely DFZ since A
is not multihomed in your scenario.  No need for A to be DFZ if
A only talks to B.

> + Prefixes (ESI) have gone from the routing process
That's a GOOD thing.
Yup. Longest match sucks.

Nope, but, big routing tables suck.

> + Customers are hidden behind their ISPs
I'm not sure what you mean by that.
Neither customer Z's ESI nor RLI (they don't need one) are visible
in the core. Only their ISPs' RLIs are visible.

Z's ESI is visible in the core, but, not carried in the routing
table.  Z does not have an RLI, but, instead uses the RLIs of
their provider(s).

No... This scheme needs DFZ routers to do the lookup.  This is
going to require significant changes to RFCs for full implementation
anyway, and, no, the whole point of my proposal is for routers NOT
to have to carry full lookup information, so, it is my intent
to modify that requirement.
If I understand the idea correctly, you have to distribute two
types of wide-area routing information: One ESI-based and one
RLI-based. This is because any DFZ box max or may not be able
to RLI-route and/or, if it sees that that's not been done yet,
perform the translation. Of course, not every DFZ router needs
both those tables, but there are some that do.

Initially, yes, there will have to be hybrid table overlap (RLI
global table and prefix-based global table).  However, don't
confuse prefix-based global table with ESI map.  The ESI map
would be a distributed database (like current A record lookups
in DNS) for Query(ESI)->{RLI, RLI, RLI...} (set of destination
RLIs for given ESI).

In the long run (once this is ubiquitous on core routers), the
global prefix-based table can be abandoned freeing router memory.
Hopefully that would occur before the global table and this table
grew to require significant hardware upgrades, and, would make
significant room for caching ESI->RLI lookups.

Oh, and you do of course have to distribute the mapping info.

No, you don't have to distribute it.  You _CAN_ provide it for
lookup instead.

> But at least it differentiates between DFZ (aka Internet Core)
> routing and edge routing.
I think that is the necessary first step.
Then I do not understand why you want the DFZ routers to be able
to translate.

I don't know what you mean by translate.

I also think that the idea of maintaining global knowledge of the
entire routing data (as required in Par. 2.1.20) scales about as
well as the IEN116 hosts file we all knew and loved (hint, when
was the last time you FTPd /etc/hosts from SRI?)
Alright, then please do explain how in your model the system is
going to bootstrap itself...I believe, 2.1.20 is there for a
very good reason (to save me the hassle and fly around the world
pushing DVDs full or initial routing information into my routers)...

Well... Since we already have RIRs, I don't see a reason that the
top level of the hierarchy for this information couldn't be managed
as ANYCAST servers at well known addresses run by the RIRs and/or
IANA.  All space originates from there anyway, so, it is a natural
point of hierarchy.  In essence, the router will learn the path
to the Root and Top Level RLIs which will be fixed ASNs assigned
as part of this protocol deployment.  Only the root is truly

I am not sure whether I have fully understood your idea, its
implications (I've tried to describe above what I understood,
but I'd like to be corrected there); I do see that your idea
is based on the assumption that it only has to work with an
IP protocol that has special header fields for routing infor,
and is not applicable to the Internet as of today (except in
a very small part, called "IPv6 world"). And what I do especially
not like is the source of the packet predetermining the topological
destination, because it only has a limited view.

The source of the packet does not determine it.  The first DFZ router
(often many routers removed from the source) determines it's best
path.  Just like today when the first DFZ router makes a choice,
e.g. between forwarding to 701 or 3561 to get to 10565.
Once the packet is handed off to 701, it's not going to come back
and go via 3561 in most cases.  If 701 loses it's connection
downstream towards 10565, it will likely drop the packet.

Apart from that, I like it, because it is almost as simple as
my own idea, but obviously more thoroughly thought through ;)

Thank you.

(That's a lot of th'es there).



Attachment: pgp00046.pgp
Description: PGP signature