Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces

From: [email-masked] (Noel Chiappa)
Date: Tue, 17 Mar 2009 22:44:49 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

    > The "split" referred to in LISP's name involves classifying some IPv4
    > addresses into "EID" addresses and others (the remainder?) into "RLOC"
    > addresses.
    > ...
    > EIDs and RLOCs are still within the single IPv4 namespace.

If you look at the LISP Map-Reply packet format, you'll notice a field called
"Loc-AFI". (The documentation doesn't really talk about it.) Ever notice that
field, and wonder what it was there for? Any guesses as to why it is there?

To repeat yet again something I said a while back in email to the LISP list,
to many of the people working on LISP, LISP is not just what is in the current
documents, but also a long-term development path of which the current stuff is
only step 1 of about 5 - or more.

Many of the current documents contain small 'hooks' intended to be used (or
necessary) at some of these later stages - such as the one I just pointed out
above. No, it's not all written down; neither was all of TCP/IP, when we
started that, either. With limited time/energy, don't expect documents that
describe things that won't be used for years to get written now.

Also, deploying a new namespace can be a major job of work, _especially_ if it
needs to be a _structured_ namespace, which is what a new locator namespace
would need to be. (Unique identifiers picked singly and probabilistically out
of a large identifier range are a whole different, and much simpler, kettle of
fish.)

Try planning all the pieces you'd need to be able to deploy a new locator
namespace - starting with agreement on the politics of how they'd be
allocated. (Note that politics has just driven the allocation of IPv6 PI
addresses - a completely non-sensensical decision from the routing engineering
point of view.)

For the initial stages of deployment, deploying a new namespace is just a
major, and unnecessary, distraction. As the old joke goes, how do you get
down off an elephant?

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Mar 2009 21:00:15 -0700

> field, and wonder what it was there for? Any guesses as to why it is  

Noel, the Loc-AFI is describe during the 'Locator' description is made:

    Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI'  
field)
       assigned to an ETR or router acting as a proxy replier for the
       EID-prefix.  Note that the destination RLOC address MAY be an
       anycast address.  A source RLOC can be an anycast address as  
well.
       The source or destination RLOC MUST NOT be the broadcast address
       (255.255.255.255 or any subnet broadcast address known to the
       router), and MUST NOT be a link-local multicast address.  The
       source RLOC MUST NOT be a multicast address.  The destination  
RLOC
       SHOULD be a multicast address if it is being mapped from a
       multicast destination EID.

Dino

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Mar 2009 11:42:06 +1100

Hi Noel,

I am absolutely certain that LISP as currently defined does not
involve new namespaces for Locators or Identifiers.

> field, and wonder what it was there for? Any guesses as to why it is there?

Loc-AFI is a 16 bit field with two currently defined options: IPv4
or IPv6.

If LISP is encapsulating IPv4 EIDs to an IPv6 RLOC or vice-versa
then the EID and RLOC addresses are in separate namespaces.  However
this has nothing to do with LISP - it is because IPv4 and IPv6
addresses use different namespaces.

> only step 1 of about 5 - or more.

My critique cites I-Ds, presentations and mailing list messages from
the LISP designers.  I can't anticipate or comment on whatever you
might think of in the future.

> Also, deploying a new namespace can be a major job of work, ...

One does not deploy a new namespace.  I think you are using the term
"namespace" at times when "addressing system", "routing system" or
similar would be more appropriate.

Anyone can invent a new namespace, simply by defining the types of
names which it encompasses and supplying a definition of how each
individual name is to be interpreted.

For example, here is a new namespace IPvBTFUSD:

   IPvBTFUSD names are 32 bit binary numbers.

   An IPvBTFUSD name is interpreted by reversing the order of the
   bits and inverting their state.  The resulting 32 bits are
   interpreted according to their accepted meaning in the IPv4
   namespace).

In the future, LISP *could* define a new namespace for RLOCs which
by prohibition or impracticality was never used for EIDs.  This
would indeed be a true case of Loc/ID separation.

To be useful in a scalable routing solution, EIDs must remain in the
namespaces recognised by hosts (IPv4 or IPv6).

You could define IPvCP [1] as an RLOC namespace, but it would be no
use in a scalable routing solution until there was firstly a global
network between ITRs and ETRs which delivered packets whose
destination addresses were specified according to the IPvCP
namespace and secondly until most end-user networks were happy with
this new network's delay and reliability.

 - Robin

[1]  IPvCP is an 84 bit addressing scheme using a namespace in
     which the bits are interpreted to provide centimetre accurate
     geographic location: 32 bits for latitude, 32 bits for
     longitude and 20 bits for elevation.

     While a scalable electronic global routing system is under
     development, initial deployment of the network involves carrier
     pigeons trained to respond to signals from skull-mounted GPS
     devices.

     This may be practical if all ETRs and ITRs could be located
     in pigeon-accessible sites.  Hosts in general cannot be
     pigeon-accessible and are frequently mobile, so any network
     which relies on the IPvCP namespace for addressing is
     unsuitable for use by hosts and therefore for carrying
     EID packets.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 18 Mar 2009 17:46:20 -0700

> Loc-AFI is a 16 bit field with two currently defined options: IPv4

Robin, you can have n namespaces with the same AFI value. RFC 2547  
VPNs is an example of this. And there are plenty more examples as well.

Dino

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Mar 2009 12:11:46 +1100

Hi Dino,

You wrote:

> Robin, you can have n namespaces with the same AFI value. RFC 2547 VPNs
> is an example of this. And there are plenty more examples as well.

Maybe so, but this is nothing to do with LISP.

I stand by my critique:

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

  - Robin

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 18 Mar 2009 18:17:14 -0700

>> VPNs

But that is how you'd implement an EID namespace that doesn't overlap  
with an RLOC namespace.

You could use, say 10.1.1.1 in both namespaces to mean two different  
things. That is, an address used as an endpoint TCP connection  
identifier and the other to number a CE/PE link from a PA-block on a  
CPE router.

Dino

---

From: Robin Whittle <[email-masked]>
Date: Thu, 19 Mar 2009 14:01:04 +1100

Short version:  I think these I-Ds contain incorrect usage of the
                term "namespace":

          http://tools.ietf.org/html/draft-farinacci-lisp-12
          http://tools.ietf.org/html/draft-lewis-lisp-interworking-02

                Maybe "address range" would be better.

                A NANOG presentation, IETF Journal article and a
                mailing list message contain incorrect statements
                about LISP creating separate namespaces for RLOC and
                EID addresses - but they can't be updated.

Hi Dino,

You wrote:

> identifier and the other to number a CE/PE link from a PA-block on a CPE
> router.

Within the IPv4 namespace, which encompasses 0.0.0.0 to
255.255.255.255, there are RFC 1918 regions 10/8, 172.16/12 and
192.168/16 which do provide a separate namespace for every private
network which uses such space.

I think what you wrote:

  1 - Has nothing to do with anything I have ever read about LISP.

  2 - Is of no practical value since LISP is intended to be a
      scalable routing solution and since EID addresses must be
      globally unique - as must RLOC addresses.

  3 - Wouldn't work anyway, even within an ISP, ignoring the rest of
      the Net, since internal routers can't tell anything about
      which namespace context you might intend for a packet whose
      destination address is within 10/8.  You are using the same
      address range for two namespaces, which is fine in principle,
      but can't work without modified routers and an extra bit in the
      IPv4 header to communicate which namespace the address should
      be interpreted according to.

      Your example would allow traffic packets from one host being
      sent to a second host with a destination (EID) address of
      10.1.1.1 and packets being tunneled by an ITR to an ETR where
      the ETR has an "RLOC" address of 10.1.1.1.  (Also, an ITR
      having 10.1.1.1 and an ETR sending it a packet.)

      Ordinary routers and hosts wouldn't know or care.

      But you can't make ITRs work.  ITRs advertise EID prefixes,
      in this case 10/8.

      An ITR would accept any packet addressed to a 10/8 address as
      a traffic packet with a destination address which matches an
      EID prefix.  The ITR would therefore look up the mapping for
      10.1.1.1 and encapsulate it to a 10/8 address in an effort to
      tunnel it to an ETR.  Then the emitted packet, if it ever left
      the ITR, would be routed straight back to the ITR and be
      encapsulated again because it matches the EID prefix which the
      ITR advertises!

I think you and your colleagues were mistaken in the use of the term
"namespace" in the I-Ds, presentation and mailing list message I
cited and quoted:

  LISP WG: Loc/ID separation - not separate namespaces
  http://www.ietf.org/mail-archive/web/lisp/current/msg00273.html

It is too late to change the mailing list messages and the
presentation.  In those, there were explicit statements about LISP
creating separate namespaces for RLOCs and EIDs.

I think you should correct the two I-Ds I cite:

   http://tools.ietf.org/html/draft-farinacci-lisp-12

     Versions 08, 09, 10, 11 and 12 since I first pointed out
     this LISP "namespace" problem on 2008-06-27.

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

     Versions 01 and 02 since 2008-06-27.

In neither of these I-Ds is there a statement that two separate
namespaces are being created.  I think the problem is that you are
using the word "namespace" when something like "address range" would
be the correct term.

So these are simple corrections.

But first, I think you would need to agree with me that LISP, if it
is to be useful on a global basis as a routing scaling solution,
cannot create separate namespaces for RLOCs and EIDs, because both
types of address need to be part of the existing namespaces of IPv4
or IPv6 in order for them to be:

   Useful to unmodified hosts as EID addresses.

   Useful as RLOC addresses, which requires that the existing
   global routing system be able to carry carry packets with such
   source and destination addresses to and from all the world's
   ITRs and ETRs.

With LISP (and likewise with APT, Ivip and TRRP) "separation" is
creating separate regions of the existing address space, which only
ITRs and ETRs need to know about.  Ordinary routers and hosts treat
packets with these addresses as they always have.

All these architectures are core-edge separation architectures, with
the new kind of address space for end-user networks (EID space for
LISP, Scalable PI micronet space for Ivip) being in specific prefixes
known to all ITRs and the mapping system.  The remaining addresses
are "core" addresses, known in LISP as "RLOC" addresses.

In June 2007, I mistakenly using "anycast" as part of Ivip's "Anycast
ITRs in the core".  One of the LISP team mentioned this to me several
times and I finally got it, renaming them "Open ITRs in the DFZ" in
March 2008.  I appreciate his efforts to improve Ivip.  Now I am
returning the favour for LISP.

  - Robin

---

From: John Zwiebel <[email-masked]>
Date: Wed, 18 Mar 2009 17:43:18 -1000

>                 Maybe "address range" would be better.

The problem is the address range for the RLOCs is every possible IP  
address
(caveat, of course, special address spaces)

And the address range for the EIDs is exactly the same.

EIDs must be globally unique only in the EID-space.

RLOCS must be globally unique only in the DFZ (which is equivalent to  
the RLOC-space)

There are, of course, exceptions to this simple understanding.  That  
happens
when you try to send packets from EID-space into RLOC-space and visa  
versa.

At that point, then the address must, of course, be globally unique  
in both spaces.

Maybe we could call it "inner space" and "outer space".  :-)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Mar 2009 09:09:47 -0400

>>>>> "Robin" == Robin Whittle <[email-masked]> writes:

    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 [email-masked] list can you
please state your concern about the use of terminology in terms of the
affect of that concern?

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.  You seem
to be concerned about some lack of clarity in the drafts.  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.  I agree there are definitions
of namespace where saying that EIDs and RLOCs are in the same
namespace means this and no more.  There are other reasonable
definitions of namespace, for example definitions under which ULAs and
PA IPV6 addresses are in different namespaces, 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.

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?

It does not seem absolutely true that  the same bit pattern cannot be an EID and an RLOC.
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.  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.)

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.

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.

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.
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.  Will it be permitted by our eventual
specs?  Who knows.  Will it be technically possibly regardless of
anything we do?  Almost certainly yes.

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.

I'd ask us all to focus on figuring out how to explain that, rather
than telling people that they have incorrectly used the term
namespace, or their identifiers are not "true identifiers" (whatever
truth is),or complaining that we cannot go back and change mailing
list messages.

---

From: Robin Whittle <[email-masked]>
Date: Fri, 20 Mar 2009 20:34:47 +1100

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.

> please state your concern about the use of terminology in terms of the

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:

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

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

> 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

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.

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

> definitely do support maintaining separate routing tables and keeping 

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

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

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

> 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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Mar 2009 10:41:37 -0400

Hi.
I'd like to focus discussion on the specific goals you propose for your charter changes.

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

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

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

Again, comments welcome from others.

>     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.  However, I think that addressing
Bryan, Lixia and Margaret's concern needs to be addressed by making
this distinction clear.  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.  At least as I understand it, your
proposed charter text change in this area seems to do this.

>     global unicast address range).

I think something along these lines is starting to sound like it is needed.

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Mar 2009 11:47:48 -0400

> terminology distinction as important.  I'd appreciate hearing comments

I believe it's useful to distinguish between encapsulation and various
forms of rewriting/translation, which also provide core-edge
separation.

> I think something along these lines is starting to sound like it is needed.

Does this have to be done before the WG is chartered?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Mar 2009 12:34:07 -0400

>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    >> > A clearer understanding of Locator Identifier Separation in
    >> terms > of it:
    >> 
    >> > Being an operational distinction in how addresses in
    >> different > sub-sections of the address range (perhaps we
    >> should mention > global unicast address range).
    >> 

    Scott> Does this have to be done before the WG is chartered?

Something has to happen.  The charter needs to be clear and accurate
in what it says.  Margaret at least has said that removing a lot of
text from the charter might also address her concerns, or at least
some of them.

Darrel and I discussed a rough outline for proposed text; I'd prefer
to try and float that before looking at removing a lot of text from
the charter.  However if it's late next week and we don't have text
that makes people happy, I definitely think we should consider options
that allow us to defer the discussion.

I think the charter is a tool that among other things serves these goals:

1) Allows people in other parts of the IETF to quickly examine what
we're doing and decide whether they need to become involved.

2) Allows the chairs to limit the scope of what we're doing so we can
be successful.

I think the fact that LISP maps networks rather than end systems is an
important property in distinguishing LISP from other proposals and so
it may be useful in controlling scope.  The other thing I'd like the
charter to do is to say how much future possible extensions to LISP
are in scope.  My belief is that the current charter limits the scope
of the LISP we're designing to cases where most routers do not change,
and where most hosts and routers are unaware of LISP.  While we might
choose to make LISP work when deployed very close to the edge, say
first hop router, that is not a use case we're focusing on, and we're
certainly not designing in features for that deployment.  That sort of
limitation seems like it may be very valuable to the chairs, so I'm
reluctant to drop too much text.

---

From: Robin Whittle <[email-masked]>
Date: Sun, 22 Mar 2009 04:13:48 +1100

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

Hi Sam,

You wrote:

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

> Again, comments welcome from others.

OK.

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

> I think something along these lines is starting to sound like it is

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