Short version:  Responding to Sam's discussion of the changes
                I suggested for the draft Charter.


Hi Sam,

You wrote:

> I'd like to focus discussion on the specific goals you propose for
> your charter changes.
>
>>  A description of LISP as being part of the "core-edge separation"
>>  class of scalable routing solutions, noting that "map-and-encap"
>>  was a term used earlier on for this class.
>
> So far, you are the only one who has advanced this particular
> terminology distinction as important.  I'd appreciate hearing
> comments from others.

I hope others will support this.  I think the paper by Lixia and
colleagues is an important step in defining terminology and arguing
for the correctness of pursuing the core-edge separation approach:

   Towards a Future Internet Architecture: Arguments for Separating
   Edges from Transit Core
   Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
   http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf


>>  An understanding that EID space is purely for end-user networks,
>>  to provide multihoming etc. in a scalable fashion.
>
> Your changes in this area may be part of addressing the concern
> that Margaret, Lixia, and I believe Bryan raised.  I think from
> your most recent messages you may share that concern.

I can't be sure my my suggested text resolves their concern.  I hope
they will comment and suggest new text themselves.


>>  An introduction to ITRs and ETRs and description of what they do.
>
> Again, comments welcome from others.

OK.


>>  A clearer understanding of Locator Identifier Separation in terms
>>  of it:
>
>>     Not involving separate namespaces - contrary to incorrect
>>     statements about LISP in an IETF Journal article etc. and
>>     in contrast to the HIP approach to Locator Identifier
>>     Separation which does involve separate namespaces.
>
> You've presented one definition of namespace.  I strongly suspect
> that there are a lot of other definitions floating around and that
> the term was being used loosely.  I have not seen a lot of support
> for your strict definition of namespaces.

I responded to this in my previous message and in the new web page.

   http://www.ietf.org/mail-archive/web/lisp/current/msg00307.html
   http://www.firstpr.com.au/ip/ivip/namespace/

As far as I recall, you are the first to suggest that there may well
be multiple meanings of the term in the context of scalable routing.

> However, I think that addressing Bryan, Lixia and Margaret's
> concern needs to be addressed by making this distinction clear.

I am not quite sure which distinction you refer to.

> I think that avoiding the term namespace or defining what we mean
> by namespace will be more productive than an argument over its
> definition and whether we have found the clearly correct definition
> for our field.

I don't think there is any disagreement about what "namespace" means.
 No-one has suggested an alternative definition of the term.

It seems to be a useful, precise, and widely understood concept since
at least the early 1990s in computer networking.  I guessed its
history went back to 1980s computer programming, but I just used
Google Books and found a few 1969 AI books which used "namespace".

I was unable to find any IETF or IRTF definition of it, but it is a
widely used term in RFCs and I-Ds.  I guess most people who used it
figured it was widely and correctly understood and that there were no
alternative meanings.   The IRTF Name Space Research Group from a few
years ago did not seem to see the need to define the term.

I think the use of "namespace" in the two LISP I-Ds is simply a
low-key mistake and could easily be fixed.  I guess the more explicit
claims made in the Journal article and presentations probably arose
from the authors not thinking clearly enough about what separate
namespaces really means and how this is impractical for any routing
scaling solution which we need to have voluntarily adopted by the
great majority of end-user networks which want multihoming - and so
could not involve global changes to routers or hosts.


> At least as I understand it, your proposed charter text change in
> this area seems to do this.

I think "namespace" is not a problematic term and that there is good
cause for using it in the Charter, since the Charter quite correctly
goes to some trouble to describe the "separation" and since HIP,
which does a more conceptually pure and powerful "separation" is
widely known to involve separate namespaces.


Jari wrote of "truth in advertising about the readiness of the
technology for wide deployment" regarding the LISP WG:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00262.html

I think the claims and inferences about LISP creating a new namespace
for EIDs, or two separate namespaces for RLOCs and EIDs, is at odds
with "truth in advertising".

HIP does separate Locators and Identifiers into separate namespaces.
 I understand that HIP is widely regarded as a true Loc/ID Separation
scheme.  HIP's separate namespace for EIDs means it can't be
considered as part of a practical solution to the routing scaling
problem.

If LISP did create separate RLOC and EID namespaces, it too would not
be a practical solution because its use on a global scale would
require new global networks which operate according to those new
namespaces - RLOCs over some new global network and/or all hosts
adopting some new EID namespace for all their communications.

Even if I thought there were were no misstatements about LISP
regarding separate namespaces, I think the Charter should state
clearly what the nature of LISP's "separation" is.  Many people
reasonably and correctly assume that HIP, with its separate
namespaces, is a true Locator ID Split protocol.  But LISP's name:

  Locator Identifier Separation Protocol

gives the impression that LISP is The protocol in this field.  I
imagine that the many people who are more familiar with HIP than with
LISP or any other scalable routing architectures would by default
consider LISP to involve a split to the same extent as HIP - separate
namespaces.

I think it is important to note that LISP is not as radical, pure or
architecturally elegant as HIP.  Its "separation" involve different
uses for different sections of the existing IPv4(6) global unicast
address space.  It may be less elegant and pure, but this is what
makes LISP a potentially practical solution to the routing scaling
problem which a pure architecture such as HIP can never be.

Since two LISP I-Ds currently use "namespace" in a manner I think is
misleading, and since the IETF Journal article and two 2008
presentations (currently linked to from the LISP site) explicitly
state that there are separate namespaces, I think it is all the more
important to have the Charter clearly state that there are no
separate namespaces.  (This is all within the context of LISP being a
practical solution to the routing scaling problem.  LISP could be
applied with separate namespaces, but I think that is outside the
scope of the purpose of the new WG because it would not address the
routing scaling problem in a practical manner.)


>>     Being an operational distinction in how addresses in different
>>     sub-sections of the address range (perhaps we should mention
>>     global unicast address range).
>
> I think something along these lines is starting to sound like it is
> needed.

I think it would be good to have the Charter refer to the IPv4(6)
"global unicast address range" and the one global namespace for this,
which any practical scalable routing solution relies upon for both
its EID space (hosts) and RLOC space (DFZ and other routers between
XTRs).  As I discovered in recent discussions, mentioning something
like "IPv4 namespace" is inaccurate or at least too vague.


>>>     This distinction only being applicable to ITRs and ETRs - not
>>     hosts or ordinary routers.
>
> As I understand it, the only XTRs need to care about EID vs RLOC
> distinctions is one of the core design goals of LISP.  It seems
> like including it in the charter may add clarity and constrain our
> work.

I agree.

   - Robin