Re: multi homing pressure

["Elmar K. Bins" <elmi () 4ever de>]

owen () delong com (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.

> First, let's
> start with something that looks a little more like an IPv6
> datagram:

You're only talking v6? Why? Anyway, let's follow this through...


> [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...)
> 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

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.


> 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.


> If you start playing with changing RLI along
> the way, then, you run into serious difficulty with looping
> possibilities. 

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
found.

> 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.


> > 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):

A B C D T
A B E F T

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.


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

Yup. Longest match sucks.

> > + 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.


> 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.

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


> > 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 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)...

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.

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

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

Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
                          (PLemken, <bu6o7e$e6v0p$2 () ID-31 news uni-berlin de>)

--------------------------------------------------------------[ ELMI-RIPE ]---