multi homing pressure

Fri Oct 21 06:40:44 UTC 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.

Owen

--On October 21, 2005 12:12:22 AM +0200 "Elmar K. Bins" <elmi at 4ever.de> 
wrote:

> owen at 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.
>
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
>> datagram:
>
> 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
ASs.

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

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

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20051020/f72d03de/attachment.sig>