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

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

Short version:  Pernickety but important discussion of the precise
                meaning of "namespace" and "independent namespaces".


Hi Tony,

We have a confusing difference of understanding of a "new
namespace", an "independent namespace" or a "separate namespace".

I thought that if there were namespaces A and B, both of which had a
range of 0 to 9, that "7" would mean one thing in namespace A and
(probably, or at least possibly) something else in namespace B.

I did not think that a statement like: "Numbers 0 to 6 refer to the
colours red, orange, yellow, green, blue and violet, and numbers 7
yo 9 refer to the textures gloss, semi-gloss, semi-matte and matte"
as defining two separate namespaces.

Nor would I think that the statement "All phone numbers apart from
123 **** are for external phones while 123 **** are for internal
phones" defines two different namespaces.

Now to lunge for the Wikipedia page . . .

  http://en.wikipedia.org/wiki/Namespace

     In general, a namespace is an abstract container providing
     context for the items (names, or technical terms, or words)
     it holds and allowing disambiguation of items having the same
     name (residing in different namespaces).

I think that is compatible with my understanding of the
characteristics of two separate/independent namespaces.

However, you wrote:

>> 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.
> 
> Well, I'd claim that they are indeed a new namespace, or at least could be
> if the proposals were generalized.  

I was assuming the map-encap system such as LISP uses, for instance,
IPv4 for both RLOC and EID addresses - which is closely analogous
with the "0 to 6 means colours, 7 to 9 means textures" example above.

The IP address 12.34.56.78 may be considered by a LISP ITR to be an
EID or an RLOC address, depending on the mapping reply, but there is
only one namespace: the 32 bit IP address range.

If there were two separate namespaces, then 12.34.56.78 would point
to one resource, device etc. if it was considered to be an RLOC and
to another resource, device etc. if it was considered to be an EID.
 But that is not the case in any map-encap system which uses IPv4
for both EID and RLOC spaces.  There is only the IPv4 namespace.

> To see that this is possible, consider a case where we used some other 
> new network layer for doing the encap.
>
> Imagine, for example, that LISP used v6 to encap v4.  As far as I can tell,
> logically, the entire proposal still works.  [Yes, I'm sure there would be
> bugs, that's not what I'm after...]

Sure, now the namespaces for RLOC and EID are different, separate,
independent or whatever.  Any given binary value X points to a
different thing in the RLOC (IPv6) namespace than it would in the
EID (IPv4) namespace.

But that is not how map-encap schemes are going to be deployed,
because that wouldn't be *incrementally deployable*!


> I'm interested in trying to characterize the full solution space,
> including the good, the bad, and the ugly.

OK.  If (as I argue) is impossible for something to be incrementally
deployable whilst also being architecturally clean (by whatever
definition, such as using independent namespaces, as you wrote in
your first message), then your solution space needs to include
things which are  architecturally unclean - because some solutions
are incrementally deployable.

In your first message, you wrote:

> We've also accepted as axiomatic that we would like to separate
> this functionality into two independent namespaces.

(I am not sure I did.  I just want the thing to work nicely, save
the BGP system from melting down and provide for billions of
multihomed, portable, networks - ideally with TE and mobility.)

> Assuming that we retain our axioms from the start of this
> discussion, this pretty clearly divides the solution space in
> two, and would seem to present a full cover of the space, which
> I, for one, find somewhat satisfying.

From this I understood your solution space was restricted to
solutions which involved independent namespaces (architecturally
clean) - but now you write of the "full solution space, including
the good, the bad, and the ugly."

 - 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