Re: [RRG] On "jack-down" models

[Robin Whittle <rw@firstpr.com.au>]

Hi Tony,

You wrote, in part:

> We've also accepted as axiomatic that we would like to separate
> this functionality into two independent namespaces.  I want to
> stress here that for the architectural result to be in any way
> clean, independence is mandatory.  Any linkage whatsoever would be
> a clearly suboptimal result.

If this is a discussion about practical solutions, then I think
incremental deployability is a principle which is more important
than any other.

I don't think any of the map-encap approaches - LISP, APT, Ivip or
TRRP - involves the creation of a completely independent namespace.
 I can't imagine any incrementally deployable solution which would.

I can't imagine how a "jack-down" system such as you describe could
be incrementally deployable, or how the system could support the
instantaeous delivery of packets the Net can do today, without prior
arrangement, since you mention key pairs for session keys for
encrypting the traffic.

Since you ask whether this division into "jack-up" and "jack-down"
covers every possible solution, and since I don't recognise the
current map-encap schemes as matching "jack-down", I am trying to
imagine how they match your "jack-up" description.

I don't think they do.

So if your problem space ignores incremental deployability as a
consideration and assumes architectural cleanliness, then maybe your
split is correct.

However, if your solution space doesn't insist on complete
architectural cleanliness, and the existing map-encap proposals
would fit within this space, them I wonder whether they are within
the "jack-up" class, or whether some new division is required.

> In what Noel has characterized as the "jack-up" model, we would lift up the
> operating Internet today, let what we think of as addresses continue to be
> used, but demote them to the role of pure identifiers.  We would then
> install a new namespace of locators underneath it, provide a mapping between
> identifiers and locators, and work out a forwarding plane adaptation so that
> we only dealt with locators in the core.  

None of the map-encap schemes involve a truly new namespace for the
ETR addresses - ETRs are located on some subset of the address space
which is not itself subject to mapping by ITRs.

Theoretically, one might be able to deploy the map-encap scheme to
the point where no host every used a non-mapped space, and that only
routers, including ETRs and BGP routers, used this non-mapped space.

But in all these map-encap schemes hosts can still send packets to
the ETRs, because they are addressable as ordinary IP addresses -
unless some kind of filtering fence is erected everywhere to stop
"hosts" sending packets to or from any device in "locator space",
which might be the case with fully deployed APT.

I regard the goal of complete separation of locator and identifier
spaces as unnecessary and counter-productive.

For instance, some hosts are part of the support system for the
map-encap scheme, and they need to be on non-mapped (RLOC) addresses
to avoid circular dependencies.  Yet those hosts need to talk to
hosts which use mapped addresses - so the idea of complete
separation makes no practical sense to me.

I conclude that if your solution space is limited to architecturally
pure outcomes, then it almost certainly cannot include solutions
which are incrementally deployable.

If your solution space includes all solutions which are
incrementally deployable, then I think it must include architectures
which are not completely clean.

I am only really interested in incrementally deployable solutions.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg