Short version:    Why I think my suggested changes to the draft
                  Charter - or something like them - are worth
                  having.

                  Response to Sam's reply - I think the examples
                  he is considering are not relevant to LISP being
                  used to solve the routing scaling problem.


Hi Sam,

Thanks for your response.  My suggested changes to the draft Charter:

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

are intended to improve the Charter so it gives a clearer
understanding to anyone who reads it, especially those who haven't
spent the last few years reading the RRG and RAM lists.

The changes would ensure readers get:

  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.

  An understanding that EID space is purely for end-user networks, to
  provide multihoming etc. in a scalable fashion.

  An introduction to ITRs and ETRs and description of what they do.

  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.

     Being an operational distinction in how addresses in different
     sub-sections of the address range (perhaps we should mention
     global unicast address range).

     This distinction only being applicable to ITRs and ETRs - not to
     hosts or ordinary routers.

The draft's current wordcount is 624.  The changes add 138 words for
a total of 762.  My attempt above to describe the changes was 140
words, so I think my changes are pretty concise.


I think a Charter which didn't clearly describe these points (in
addition to the other points it already covers, which I think are
well written) would be confusing for many people who will be reading
it in the next year or so.


I am assuming that the Charter is intended to refer to LISP as
defined now and as it will be developed in the next year or so, with
the constraint that LISP is intended to be a practical solution to
the Internet's routing scaling problem.  There are all sorts of other
things which could be done with LISP which are not applicable to
scalable routing, but I think they should not be covered by the Charter.

Please read on for a detailed reply to your message.



You wrote:

> 
>     Robin> Short version: I think these I-Ds contain incorrect usage
>     Robin> of the term "namespace":
> 
> At least to the extent that you copy the lisp@ietf.org list can you
> please state your concern about the use of terminology in terms of the
> affect of that concern?

The effect of leaving the Charter in its current form, rather than
changing it along the lines I suggested, would include:

  1 - Greater difficulty for many people understanding the purpose
      of LISP's EID space and how LISP could be used to solve the
      scalable routing problem.

  2 - Doubt in the reader's mind about exactly what constitutes
      "separation".  This doubt would be exacerbated by existing
      references to LISP involving separate namespaces for RLOCs and
      EIDs, as I listed:

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

      even if the use of "namespace" in the two I-Ds is corrected.


> After multiple readings of your message, I'm still somewhat confused
> about your point.  You seem to be saying that the Namespace is a
> really generic term that can mean a lot of different things.  

Broadly speaking, "namespace" could be applied in various fields of
endeavour.  In computer networking, I think it has a precise and
important meaning - so the term should be used only where it applies.

"Namespace" definitely should not be used to refer to a subset of
larger range of numeric addresses, as if it was a synonym for
"sub-range", subnet or whatever.

The best definition I could find is:

   http://en.wiktionary.org/wiki/namespace

    (computing) A conceptual space that groups classes, identifiers,
    etc. to avoid conflicts with items in unrelated code that have
    the same names.

If the LISP team have a different understanding of "namespace" I hope
they will discuss it.

In the context of numbering and addressing, I understand that
"namespace" is a unique and apt term for a context in which a name
(including a number, which is a numeric name) is to be interpreted.

The name "9587 3762" means exactly one thing when interpreted within
the Australian telephone system's 03 area code.  It means one
completely different thing when interpreted in the 02 area code.

These area codes are separate namespaces.  They both admit 8 digit
decimal numbers and they both provide an interpretation of each
possible name within that range which enables some of these names to
unambiguously identify a particular telephone service.

"303" on its own means just a number.  If you mention "303" in a gun
shop, it will generally be taken to mean the calibre of a rifle.  If
you mention it in a musical instrument shop, it will generally be
interpreted as a reference to a TB-303 electronic instrument made in
Japan in 1982.  These differing interpretations result from different
initially assumed namespaces due to where the specific name was spoken.

In IPv4, each network which uses 10/8 has its own namespace for IP
addresses in that range and likewise for 172.16/12 and
192.168/16.  While any network could in principle do whatever it
likes when interpreting IPv4 addresses, in the context of LISP as a
potentially practical scalable routing solution, we can assume that
the remainder of the IPv4 address space is interpreted according to
the one set of meanings in all networks.  This is what I called the
"IPv4 namespace".

In this namespace - this framework for interpreting the meaning of
specific names - a particular name 12.34.56.78 at a particular time
has exactly one meaning: it identifies a particular IPv4 address,
which generally is useful in that it identifies a particular host
which receives and sends packets according to this address.  (Since
the routing system moves packets according to address, the bits are
also interpreted in various ways by different routers - but
nonetheless, the "meaning" of this pattern of bits is  the same the
world over.)

Exactly what a network does with a packet addressed to 12.34.56.78
would vary - but for any network involved in global Internet
connectivity, it is interpreted as meaning a particular device, or at
least an address where something we regard as a particular device may
be sent a packet.  (I won't go into detail about anycast address,
with multiple hosts on the one address - or discuss broadcast
addresses, 127/8 etc.)

LISP needs to be practical in a scenario of global IP networking
which is based on IPv4 and/or IPv6.  While not every address in these
ranges is global unicast, those global unicast addresses of IPv4 are
all part of a single namespace.  Likewise, for IPv6.

So to be exact, I will refer to:

  IPv4 global unicast namespace
  IPv6 global unicast namespace

LISP needs to rely on the existing Internets: the IPv4 Internet which
interprets addresses according to the IPv4 global unicast namespace
and which forwards them accordingly.  Likewise the IPv6 Internet
according to the IPv6 global unicast namespace.

It is easy to imagine other global networks using other namespaces,
but none will exist in the foreseeable future.  So it is reasonable
to assume that LISP will rely entirely on the IPv4 and IPv6 Internets
and their respective global unicast namespaces for the vital purpose
of ITRs and ETRs sending packets to each other.

I thought this was understood, so I didn't spell it out in such
detail earlier.


> You seem to be concerned about some lack of clarity in the drafts.

Yes, as I described above.


> I think your main point is that you do not believe that a single IP
> address can stand as both an RLOC and an EID.

Within the constraints of LISP being a practical solution to the IPv4
or IPv6 routing scaling problem, yes.


> I agree there are definitions of namespace where saying that EIDs
> and RLOCs are in the same namespace means this and no more.

OK.  For instance the IPv4 global unicast namespace can be divided
into many sections, such as addresses being regarded as "RLOC" except
where a prefix is somehow defined as being "EID" space.

The mapping system carries mapping for EID sections of the global
unicast address space, but not for the remaining RLOC sections.

ITRs advertise EID prefixes and accept packets addressed to EID
addresses into their mapping and encapsulation system, where (if
there is mapping and a reachable RLOC address) the packet will be
encapsulated and tunnelled to an RLOC address.

The I-Ds state that LISP ITRs and ETRs must be on RLOC addresses and
that EID space is for end-user networks.

An IPv4 global unicast address cannot be in an EID section and also
be usable for RLOC purposes, such as ITRs or ETRs.

All IPv4 EIDs and RLOCs are still part of the one IPv4 global unicast
namespace.  It is just that the subset of the total space which is
covered by that unicast namespace is divided numerically into
sub-sections.  Within a sub-section, all addresses are EIDs. Outside
the subsections, all addresses are regarded as RLOCs.


> There are other reasonable definitions of namespace, for example
> definitions under which ULAs and PA IPV6 addresses are in different
> namespaces,

Yes, these are separate namespaces.  PA IPv6 addresses are part of
the IPv6 global unicast namespace.  ULA addresses are interpreted
(given practical meanings) according to a namespace which is unique
to the site.  So ULA addresses can't be used for ITRs or ETRs in any
application of LISP which is to solve the routing scaling problem.
Nor can ULA addresses be used for global communication, which is
field LISP is involved in.


> for which saying that EIDs and RLOCs are in the same namespace says
> far more than you need to if I've captured your point above.

Sure.  When I wrote in previous messages "IPv4 namespace", in the
context of scalable routing, I really meant "IPv4 global unicast
namespace".


> So, let's step past the terminology argument and examine your point.
> First, have I got your point right?  Am I missing part of it?

If we continue the discussion purely in terms of the two namespaces
of the two global networks which LISP must rely upon for ITR <-> ETR
communications, I think our understandings are well aligned.


> It does not seem absolutely true that the same bit pattern cannot
> be an EID and an RLOC.

In LISP, according to the I-Ds, those addresses which are not EIDs
are RLOCs.  The distinction is determined by whether the address - or
at least addresses in the same prefix (however defined) - have an
entry in the mapping system. If they are, it is an EID prefix.  If
not, it is an RLOC address.

I am much clearer about this with Ivip.  Mapped Address Blocks (MAB)
are BGP-advertised prefixed (advertised by OITRDs, the equivalents of
LISP PTRs).  Every address within a MAB is a "Scalable PI" (SPI)
address - that is, it is mapped by the Ivip mapping system and can be
used as, or as part of, a "micronet".  Every address within a MAB
would be described in LISP as an EID - and only addresses within MABs
are "EID"s.

LISP lacks a term equivalent to "MAB" and there's no reason why it
can't be adopted by LISP.

A bit pattern must have a certain length.  If it is 32 bits, it is
amenable to being interpreted according to the IPv4 global unicast
namespace.  If so, that address, for the entire (global scalable
routing) LISP system, must be either an EID address or an RLOC address.

If a global scalable routing application of LISP could use some other
network for ITR <-> ETR communications and if that network used 32
bit addressing using a different namespace than the IPv4 global
unicast namespace, then I would agree that there could be a single
bit pattern which could function both as an EID and as an RLOC.  But
that would depend on the same bit pattern being used on the two
different networks and so in fact meaning two different things, since
each network interprets the bit pattern according to the rules of
separate namespaces.

There is no prospect of a separate global network appearing with such
characteristics, so in the context of this discussion, I would say
there is no prospect for any 32 bit address being usable in a
practical sense as both an EID and RLOC.

  (As an aside, LISP-ALT does have another network - the ALT
   network.  This is used for ITR -> ETR communications.  For
   simplicity, just discussing IPv4, the ALT network is constrained
   to use the same IPv4 global unicast namespace as is used by the
   Internet.  As an example of why this is true, the LISP protocols
   require that the ETR determine the address of an ITR to send a Map
   Reply packet to by reading the source address of the Map Request
   packet which arrives via the ALT network.  Likewise, the ALT
   network forwards Map Requests to ETRs according to which EID
   addresses they advertise to the ALT network (or register with a
   Map Server, which advertises that EID prefix on the ALT network).
   EID addresses are part of the IPv4 global unicast address space
   and so the ALT network is constrained to use the IPv4 global
   unicast address namespace when ascribing meanings to particular 32
   bit patterns which match this large subset of the whole IPv4
   address range.)

A LISP system could work over both IPv4 and IPv6, including IPv4
traffic packets being encapsulated in IPv6 packets and vice-versa.
In this case, there could be separate namespaces for RLOC and EID,
but this is not a function of LISP - these namespaces are already
differently defined for IPv4 and IPv6.

Likewise 128 bit addresses - there is no prospect of there being a
separate global network suitable for ITRs, ETRs and hosts using 128
bit addresses in a manner different from how the IPv6 Internet uses
them in its IPv6 global unicast namespace.


> Here are ways in which this may be false:
>
> 1) As discussed in section 4 of the interworking draft, you can
>    announce an EID as an RLOC.

http://tools.ietf.org/html/draft-lewis-lisp-interworking-02#section-4

OK, but this is not part of LISP as a scalable routing solution:

   Doing this is undesirable as it defeats one of the primary
   goals of LISP - to reduce global routing system state.

   If EID prefixes are announced into the DFZ, the impact is
   similar to the case in which LISP has not been deployed, because
   these EID prefixes will be no more aggregatable than existing PI
   addressing. This behavior is not desirable and such a mechanism
   is not viewed as a viable long term solution.


> This is meaningful if the address would reach the same entity
> regardless of whether you treat it as an EID or RLOC.  That section
> discusses disadvantages of doing so, but does not forbid the
> practice.  (Clearly, if new EIDs are announced as RLOCs, we are
> making the routing problem worse.  It's not clear to me that using
> something as both an EID and RLOC that is already announced in the
> DFZ actually makes things significantly worse.)

Your example is clearly not part of LISP as a solution to the
scalable routing problem, which is the context in which I assume we
are interested in LISP.  I am sure all sorts of things could be done
with LISP network elements and processes - but in the Charter, I
think we need to focus only on those which might be a practical
solution to the routing scaling problem.


> 2)  The RFC 2547 VPN case is actually important.  You discuss some
>     of the conditions that would be necessary for this to be done
>     within an ISP as an argument that it couldn't work.  For
>     example, routers would need to keep track of which 10.1.0.1
>     they were dealing with.  You propose that a bit would be needed
>     in the IPV4 header.

10/8 can't be used for any global, scalable routing implementation of
LISP.

Since the IPv4(6) interdomain routing system interfaces with its ISPs
and other networks purely on the basis of unadorned IPv4(6) packets,
over router links where router behavior is coordinated by a single
BGP system for each of IPv4 and IPv6, I assumed that the extra bit
would need to be carried in the IPv4(6) header.

Links within ISPs and other networks and between networks may well
involve VPNs, MPLS or whatever.  However, since LISP needs to be
practical in all ISPs, it has to run over pure IPv4(6).


> It turns out that this practice is quite common today.  Typically MPLS
> labels are used to distinguish what addressing plan an address is
> drawn from in cases where there are multiple valid addressing plans
> for an interface.  (It's a bit more complicated than this in
> actuality).  However in a number of cases (particularly the CE
> interfaces), only one addressing plan is valid.  The routers
> definitely do support maintaining separate routing tables and keeping 
> the routing separate.

Sure, but I can't see how these techniques could be part of LISP as a
global routing scaling solution.


> If you had a mapping function local to an ISP, you absolutely could
> return EID->RLOC mappings local to the addressing plan of that ISP.

Again, I think you are considering applications of LISP which are not
related to solving the routing scaling problem.


> If the EIDs are not globally unique, then you'll only be able to reach
> that EID from within the scope where it is unique.  However non-unique
> RLOCs don't seem like they would cause any significant problem.  If
> the EID was outside the ISP, then the mapping service could give you
> the RLOC of a router that would decapsulate-and-reencapsulate your
> packet with a new RLOC.
> 
> Is this useful?  I don't know.  

I think such localised variation in the mapping system have not been
described in existing LISP I-Ds.  I don't recall them having been
discussed.  I am sure they are not part of whatever LISP has to offer
in terms of solving the routing scaling problem.


> Will it be permitted by our eventual specs?  Who knows.

I am not opposed to LISP being developed to do more than solve the
scalable routing problem.  I assumed the sole purpose of the new WG
is to develop LISP as a scalable routing solution.  I think that if
the Charter is to contemplate uses of LISP beyond scalable routing,
that this should be explicitly mentioned.


> Will it be technically possibly regardless of anything we do?
> Almost certainly yes.

Sure.

> However, I think there is a core of your concern that is an important
> clarification to the drafts.  In many cases, you cannot use the same
> number as an EID and an RLOC.

Since a practical global LISP system relies entirely on the global
unicast IPv4 and/or IPv6 networks, there is only one namespace to use
for 32 bit IPv4 addresses in the interdomain routing system and for
hosts which are involved in communication to all globally accessible
hosts.  Likewise there is only one such namespace available for using
128 bit IPv6 addresses.  There is no other globally usable namespaces
or global networks.

In that context, I am sure, a single numeric address cannot be used
as and EID and an RLOC, where "EID" means something like "mapped by
the mapping system, used for end-user networks and never of ITRs or
ETRs" and "RLOC" means "all the other addresses, of which the global
unicast addresses may be used for ITRs and ETRs.

I have not tried to understand how LISP would work with multicast, in
part because as far as I know, multicast is not supported by the
interdomain routing systems of either the IPv4 or IPv6 Internets.


> I'd ask us all to focus on figuring out how to explain that, 

I think my suggested improvements to the draft are concise and worth
including.  They can probably be improved upon, but I believe some
text along these lines is needed in the Charter.

> rather than telling people that they have incorrectly used the term
> namespace,

I didn't just tell them - I explained in detail why I believe this,
specifically concerning LISP, in June last year.


> or their identifiers are not "true identifiers" (whatever
> truth is),

I don't recall writing anything along these lines.


> or complaining that we cannot go back and change mailing list
> messages.

I wasn't complaining.  I was pointing out the the message, the NANOG
presentation and the IETF Journal article can't be changed, and that
some people will read them (especially the presentation and article)
- and that as far as I can see, both are misleading in that they
explicitly state that LISP creates separate EID and RLOC namespaces.

In that context, I think it is all the more important to ensure the
Charter is clear about the exact nature of the "Separation".
"Separation" is part of LISP's name and is central to understanding
LISP's mechanisms and benefits.

 - Robin