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

["Tony Li" <tony.li@tony.li>]

Hi Robin,

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


Indeed.


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


Agreed.


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


Please re-read the definition of namespace again.  It implies that two items
can have the same name in different namespaces.  What you're proposing is
that two separate namespaces share a single syntactic space as a means of
disambiguation.  


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


I'd still argue that there are two separate namespaces.  Obviously, in
traditional LISP, there's a single syntactic number space, but to truly
disambiguate between locator and identifier, one has to look up the number
in the mapping function.  By definition, the items found in the domain of
the map are going to be identifiers, with the range being the locators.  

Yes, ok, you can do syntactic disambiguation too, but do you really want
that to be your primary definition of the namespace?  It implies that it
will get hard coded, now and forever. Further that you will restrict the
spaces to only a fraction of the available number space.  What happens when
you exaust the prefixes reserved for EIDs?  If EIDs and RLOCs are going to
be syntactically mutually exclusive, don't we end up with only 2 billion of
each?

It would seem to me that one indication of independence is that we should be
able to use any number as either a locator OR identifier.  It's perfectly
acceptable to require that there be nodes in the network that use the same
name in both namespaces as a transition tool, but obviously this cannot be a
long-term steady state requirement.


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


I think that there's some confusion here between a syntactic number space
and a namespace.


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


That's fair.  Not everyone has to accept all axioms.  I think you would
actually rebel against any proposal that didn't result in truly independent
namespaces for a variety of reasons, but we don't really need to explore
that hypothetical situation.


|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."


Ok, fair enough.  Yes, I do want to map the full solution space, but I think
all of us are going to quickly reject things that are architecturally
unclean.  Not much point in spending effort mapping out things that we're
clearly going to reject.

Regards,
Tony


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