Re: An idea: GxSE

["Jon (Taz) Mischo" <taz@tazlore.com>]

On Wed, 20 Jun 2001, Mohan Parthasarathy wrote:

> > To reiterate for you, Mohan, we're not taling about mobility.  We're
> > talking about large-scale changes, not one or two hosts, but thousands of
> > hosts.  If a new prefix is added, it doesn't affect a few hosts, it
> > affects a large subnet.
> >
> Sure. I was only trying to draw an analogy i.e Mobile IPv6 which i am
> familiar with. Are you saying that we are not interested in solving
> the above mentioned problem ?

Understandable.  But yes, that's what I'm saying.  What we're discussing
here isn't mobility, and we're not designing for mobility.  However, it
does have some good benefits for mobility.

> > Mobile IP handles the case of a host moving around on a network.  Here
> > we're addressing the issues of a network moving around on a backbone and
> > in address space.  What we're trying to solve for here is how to keep a
> 
> When you are moving around, you are getting new prefixes and the old
> prefixes will not be valid after sometime. (The difference between
> this and mobility is that the old prefix is considered to be valid
> in mobility)

You're not moving around a lot.  Again, this isn't mobility.  This is
often the result of a circuit or router going down in the case of
multihoming.  In thse situations, the prefix is never invalidated, it's
just useless for a while.

In the case of renumbering, if you have a protocol that does a good job of
distributing the prefix information, it is pushed far enough out that you
don't have to worry.  Furthermore, we're talking about address space
that's unique but doesn't have to be routable.  This way you know it will
be rewritten, but the host doesn't really care about that.  In some cases
the space may be routable and you may still own it, but you aren't using
it anymore, in favor of better aggregation and routing.

One of the biggest nightmares in the service provider field (I know,
before I was in R&D I was a network engineer for a very large ISP) is
renumbering because you have a region that's grown and you either have to
add a new subnet and grow your tables due to the aggregation you've lost,
or renumber that region into a larger subnet you have.  In this scenario,
you would just change the GR the space fell into, keeping the same SK, so
the host doesn't know it's somewhere else in the network.

> > host unaware that there have been sweeping network changes, including its
> > own address, while still giving it the ability to operate as if nothing
> > happened, with confidence that its sessions aren't being hijacked.
> >
> What do you mean by keeping the host unaware ? Does it mean that
> you don't want the renumbering event to be known to the end hosts ?
> It will be known without which it can't configure new addresses.
> So, i am missing something.

That's exactly what it means.  The host doesn't configure new
addresses.  In SCTP it can, but we're talking about GxSE, where there are
routers further upstream that are doing the remapping/rewriting for
you.  The host doesn't have to know.  Of course, Sean's point of this
requiring a different checksum scenario is very true.  We'd have to move
to a checksum scenario closer to what UDP-lite uses, where you don't have
a single checksum for the entire packet, but actually break the packet up
into portions that are reliable and unreliable.  Obviously the addresses
in a packet are completely unreliable for checksum purposes in this
scenario, and need either to have their own simple checksum that's
verified and recomputed at every rewrite, or you just checksum as many
bytes from the header as will stay the same regardless, and pray what you
get at the other end makes sense.  Of course, if it doesn't, it'll likely
be rejected anyway.

-Taz

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989