North American Network Operators Group

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

Re: multi homing pressure

  • From: Owen DeLong
  • Date: Thu Oct 20 15:03:14 2005

> Rewriting would IMHO not work easily, but encapsulation would.
> Admittedly, this idea has occurred and lead to MPLS
> implementations (which are weak at interconnecting ISPs anyway).
Why wouldn't rewriting work?  The "encapsulation" you show below
is little different from the rewrite I propose.  First, let's
start with something that looks a little more like an IPv6

[Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]]

Now, let's look at what the first DFZ router would do to the

[RLI: Z Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]]
[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: ...]]]

So... Nobody outside the DFZ needs to change anything, all the
checksums and such at hosts that should check them still work,
and, even IPSec packet tampering would not detect this since the
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.

> Well, let's see what else we can do, that MPLS maybe cannot.
Perhaps become ubiquitous implementation in the DFZ?

> If the end user does not determine the RLI themselves, but
> their ISP does (on edge routers), it looks like this:
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.

> A is the customer, Internet access provided by X
> B is the customer of Z
> Y is an intermediate system
> A -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> X
> X -> Add envelope -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...]
> X -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> Y
> Y -> [RLI: Z [something]] -> Z
> Z -> Remove envelope -> [Src: a.b.c.d Dst: e.f.g.h Data: ...]
> Z -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> B
> Routing decision is thus made by looking up paths for Z.
> Multihoming works the same, but we get multiple RLIs in the packet.
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.  If you start playing with changing RLI along
the way, then, you run into serious difficulty with looping
possibilities.  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.

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

> We have some major points here, and one possible ballbreaker:
> + Prefixes (ESI) have gone from the routing process

That's a GOOD thing.

> + Customers are hidden behind their ISPs

I'm not sure what you mean by that.

> + Packets carry their routing information (instead of ESI info)

No.  Under my proposal, packets carry both RLI and ESI information, but,
in separate fields.

> + Packets may as well be deeply inspected, if necessary
That already happens, but, it is not necessary under my proposal.

> - Edge routers need to be extremely powerful, because they
>   have to determine all the ESI <-> RLI information
Nope.  DFZ routers (which already need to be extremely powerful)
need to be able to perform lookups for ESI->RLI (one way,
btw) mapping.  This could be accomplished by a protocol similar
to DNS, but, more secure and authenticated.  Trading a lookup
at first sight of destination prefix, then cache against
trying to manage a 32 bit routing table (4 billion routes?)
is likely a scalability win.  Even if it's just 1 million
routes, I think it is a win.

> Ballbreaker (shared with Owen's idea):
> - This scheme needs the ISPs' edge routers to do the looking
>   up, and if we do not find a way to incorporate updating
>   the lookup table into part of the routing system, we are
>   in violation of Par. 2.1.20 of draft-irtf-routing-reqs-03.txt,
>   which is a very sensible requirement IMHO.
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.

> But at least it differentiates between DFZ (aka Internet Core)
> routing and edge routing.
I think that is the necessary first step.

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


If it wasn't crypto-signed, it probably didn't come from me.

Attachment: pgp00042.pgp
Description: PGP signature