Short version:     Most of the third paragraph should be replaced.

                   LISP lacks distinct terms for important concepts.
                   This makes discussion and description tortuous and
                   error prone, especially when terseness is a goal.

                   Ivip has distinct terms for important concepts so
                   discussion and descriptions can be both terse and
                   unambiguous.

                   I think LISP should have distinct terms for the
                   same concepts too.  There's no reason not to use
                   the same terms as I use in Ivip.

                   Sam wrote that a single address would "typically"
                   not be used in EID and RLOC roles.  For a
                   practical LISP system, "typical" is not strong
                   enough - it is impossible.

                   Noel still seems to think it is possible, but has
                   yet to explain how.


Quoting > Noel and >> Sam:

>> I'd like to say that the global portion is what is mapped into an RLOC.
> 
> This gets into a bit of definitional mud here here, because I seem to vaguely
> recall that there were plans to have multiple ETRs divide things up, so that
> not all traffic to a single 'site' (as I am using the term) goes to a single
> ETR. (However, that's the operational side, and I'm not totally up to speed
> on the plans in that area, so I can't say for sure.)

LISP and the other core-edge separation techniques all enable load
balancing for a multihomed network.  In an example where a single
physical end-user network has two ISP links, each with its own ETR,
then the total amount of LISP-mapped address space the end-user
network controls, say 22.22.22.0/24 could be split into two /25
prefixes, each with its own mapping.  One /25 would have mapping so
ETR-A is its preferred ETR (to be used when ITRs perceive that both
ETRs are up) and the other /29 would have ETR-B preferred.  (LISP
also has explicit load-sharing instructions in the mapping data, but
this is an instance of just using Priority rather than the
load-balancing Weight.)

LISP has no specific terminology for these concepts:

   A prefix of LISP-mapped address space assigned to a single
   organisation or end-user network.

   A prefix which is covered by a single body of mapping information.
   (May be the whole of the above, or may be a subset of it.)

This lack of precise terminology leads to difficulties describing and
discussing these things, as we see on the list now.

In Ivip, the 22.22.22.0/24 prefix would be referred to as the UAB
(User Address Block).  Each /25 would be a "micronet".

Theoretically one or (for routing scalability) many more, such as
thousands, of UABs would be in a Mapped Address Block (MAB) which is
advertised in the DFZ by OITRDs (equivalent to LISP PTRs).   LISP has
no equivalent term for MAB either.

In LISP, "EID" could mean several things, including a way to use
address space, or a single address used as an Endpoint Identifier or
a prefix of such addresses.

An "EID prefix" could also mean the equivalent of a MAB (advertised
in BGP), the equivalent of a UAB (the LISP mapped address space
assigned to an end-user), or the equivalent of a micronet (a
particular prefix which is the subject of a single mapping
specification, though in Ivip, micronets don't have to be prefixes).


I think the LISP team should adopt definite terms for what are known
in Ivip as MAB, UAB and micronet.  You are welcome to use these
terms.  I pinched "micronet" from Bill Herrin's TRRP proposal where
it was a prefix, and use it to refer to a a contiguous block of 1 to
any number of IPv4 addresses or IPv6 /64 prefixes which is covered by
a single entry in the mapping database.

I use the term "Scalable PI" (SPI) to refer to any Ivip-mapped
address space.  There's no reason why "SPI" could not be adopted as a
general term in LISP for the complete set of, or the type of, address
which is LISP-mapped and therefore is suitable only for end-user
networks, and which can be used for multihoming, portability and
inbound TE in a scalable fashion.


In the above example, the 22.22.22.0/24 is used for one physical
site.  There could be more ISP links, more ETRs on each link (each
its own RLOC address) and it would be possible in LISP to split the
/24 into any mixture of prefixes from /25 to /32 and give each one of
these (micronet equivalents) a separate mapping entry.

It is also possible for some of this space to be used at another
physical end-user network - either owned by the original organisation
or not.

In the first example, company CCC had the /24 originally for its
single site end-user network.

Here is a second example, with 32 sites:

As the company grew and as IPv4 address space (LISP mapped or not)
became harder obtain, CCC decided to use its existing /24 (Ivip: UAB)
more intensively for its growing network of branch offices.  Let's
say it had 32 offices, all over the world, each with 100 desktop
machines, a mail server, a web server and a few other things.

CCC splits its /24 into 32 /29 prefixes (8 IPv4 addresses each) and
gives separate mapping to each. (In Ivip, each such /29 is a
micronet.)  Then, it has 32 physically separate end-user network
sites each with links to two ISPs and each, in LISP, with a single
ETR at the end of each link.

Within each /29 is an address for the mail-server with web server
(for web-mail, amongst other things), a router address for VPN access
from the outside world and some other addresses for the NAT machines
serving the desktops on private addresses.

Multihoming is achieved by having each such /29 ("micronet") mapped
to the two ETRs of each physical site, with the ITRs choosing which
of the two ETRs to use.  LISP has load balancing features in the ITR,
so traffic addressed to the one /29 could be load balanced over the
two ISP links to the two separate ETR addresses

It would also be possible to load balance these by further splitting
them into /30s, with one being handled by one ETR and the other by
the other, except during an outage when the ITRs figure out to send
packets addressed to both /30s to whichever ETR is working.


A statement such as:

>> I'd like to say that the global portion is what is mapped into an
>> RLOC.

isn't much help, since it is not clear what the "global portion" of
the address bits are and what sort of role the "EID" address/prefix
in question is playing.

I think the 2nd and subsequent sentences in the 3rd paragraph in the
second draft:

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

have many problems and should be replaced.


>=   Both LISP EIDs and RLOCs are IP addresses.

They have to be when LISP is initially introduced as a practical
solution to the routing scaling problem - and for many years after:
until such time as either DFZ routers can be upgraded and/or all
hosts can be changed so that two separate networks or two separate
namespaces in the one network, can be used globally for the two
purposes of addressing hosts and tunneling packets to ETRs.

As discussed in my recent message:

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

and in about 15 mailing list messages in the last 20 months, listed
here: http://www.firstpr.com.au/ip/ivip/namespace/ LISP or any other
"incrementally deployable" [1] core-edge separation solution to the
routing scaling problem which is actually practical and could be
widely voluntarily adopted must rely on the existing IPv4 or IPv6
networks both for the EID addresses used by hosts and for the RLOC
addresses used by ETRs.

Therefore, in this context (being a practical, voluntarily adopted,
scheme) it is true to say that both EIDs and RLOCs are IP addresses.
 Then, it is also true to say, in terms of global operation, that the
EID and RLOC addresses must both be handled by routers and hosts
alike according to the single global unicast namespace of whichever
network is used: IPv4 or IPv6.


>=  LISP EIDs are composed of three parts: a portion that identifies
>=  an organization, a portion that identifies a subnet within an
>=  organization, and a portion that identifies an interface on that
>=  subnet.

I don't recall anything like this in LISP I-Ds.

What is meant by "LISP EIDs"?  In the absence of more specific
terminology, I think any such description needs to have a sentence or
so specifying exactly what is being referred to.

Assuming straight binary boundary prefixes for all divisions (not for
instance a /16 starting on a /17 boundary and so straddling a /16
boundary), here is an example of how the bits might be used if CCC's
/24 was split up into 32 separate, individually mapped /29 prefixes.

 Most significant         Least significant

 0                                       31 Big-endian bit number.

31                                       0  Conventional binary bit
                                            number.

 aaaa aaaa  aaaa aaaa  bbbb bbbb cccc cddd

 aaaa aaaa  aaaa aaaa  .... .... .... ....  Advertised in the DFZ,
                                            equivalent to Ivip's
                                            Mapped Address Block.

 aaaa aaaa  aaaa aaaa  bbbb bbbb .... ....  CCC's /24 (Ivip: UAB.)

 aaaa aaaa  aaaa aaaa  bbbb bbbb cccc c...  A particular /29
                                            covered by a single
                                            mapping entry.
                                            (Ivip: micronet.)

 aaaa aaaa  aaaa aaaa  bbbb bbbb cccc cddd  A particular IP address
                                            within the above.

With the current lack of proper terminology, "LISP EID" could mean
any of the above.

The description in the 2nd draft is not very helpful or accurate.

The bits in an EID don't explicitly "identify" an organisation.

The "aaa"  bits are specific to a particular DFZ advertised prefix
(Ivip: MAB).  In LISP (or in Ivip) this *could* contain a single
range of addresses belonging to a single end-user network.  But it is
vital that the core-edge separation scheme be usable and generally
used so that each such DFZ advertised prefix covers the space of many
(hundreds to thousands) of separate end-user networks.  Otherwise, we
get little or no reduction in the burden on the DFZ per end-user network.

It is possible, but undesirable, in LISP or Ivip for the /16 prefix:

  aaaa aaaa  aaaa aaaa  .... .... .... ....

to be several things all at once:

  1 - A DFZ advertised prefix for PTRs (Ivip: MAB).

  2 - A prefix of LISP-mapped address space assigned to a
      particular organisation for its one or more physically
      distinct end-user networks (Ivip: UAB).

  3 - A prefix with a single mapping (Ivip: micronet).

In this case, for CCC, they have a single end-user network and
multihome via two ISPs, with a single EID prefix with a single
mapping (Ivip: micronet) which covers their entire assigned address
space (Ivip: UAB.)  Also, CCC has its two ISPs advertise this same
/16 into the DFZ (Ivip: MAB.)

This achieves no scaling improvement over the current practice of
advertising the /16 as a conventional PI address in BGP.  However, it
is a technically valid arrangement under LISP or Ivip.

It has no scaling benefits, but it might have benefits for CCC.  For
instance, with LISP, CCC may believe that individual ITRs are better
placed to decide which of the two ETRs to tunnel packets to, rather
than relying on BGP to adapt to a failure of one ISP link or the
other.  With Ivip, CCC might prefer to nearly instantly switch
traffic from one ISP link to the other with a single mapping change.

My point is that this use of a single /16 for three roles, which were
performed by three separate prefixes in the 32 site example above, is
a perfectly valid LISP arrangement and is not at all covered by the
"three parts" text in the 2nd draft of the Charter.


>=  LISP maps only the upper portion of the EID;

Since the reader has no way of being sure what the EID in question
is, or whether "upper" refers to the first or the second of the
"three parts" previously described, this does not help their
understanding.  Also, the "three parts" text did not state clearly
where these three parts reside in the binary address bits to the
reader has to imagine the the first mentioned part is the most
significant, in the "upper" part of the address bits.


>=  as a consequence a host would typically change EIDs when it moves
>=  from one organization to another or whenever it moves from one
>=  subnet to another within an organization.

A host must get a new address when it changes to another subnet of
any kind, and assuming it moves to a subnet in another organisation,
it must therefore get another address.  This is true of ordinary
non-EID (non LISP-mapped and therefore RLOC space) or of LISP-mapped
EID space (Ivip: SPI) space.   So this sentence doesn't help anyone
understand LISP.


>=  Generally, the same IP address cannot be used as both an EID and
>=  an RLOC, especially if the entities named by the EID and RLOC are
>=  different.

This would be an incorrect and extremely confusing sentence to have
in the LISP WG Charter.

It is always true that "the same IP address cannot be used as both an
EID and an RLOC" as I have argued many times, including in my last
message.  So the first half of the sentence is misleading and the
second has no valid meaning.


> Anyway, the upshot is that a single 'site' might have a single LEID block
> assigned, but different parts of that LEID block might resolve to different
> RLOCs. So is the 'global' part just the high part (i.e. the block issued to
> the site as a whole), or does it include everything down to the last bit that
> the mapping system looks at to produce a mapping?

Noel, I hope that my 32 separate /29 prefix example illustrates the
sort of scenarios you are referring to.


>> I think that a case where the same 32-bit number was used for an RLOC
>> and an unrelated EID would be a significant difference from LISP today.

If "LISP today" means as implemented in the current test network and
as LISP must be implemented for a practical, widely, voluntarily
adopted core-edge separation solution to the routing scaling problem
then the above sentence is absolutely true.  There are no separate
namespaces within the IPv4 address range which can be used for RLOCs
and EIDs, because the only global network which can be used for both
hosts and ETRs uses a single namespace for the global unicast
portions of its address range.

There is only one namespace available to LISP or any other scheme for
the two purposes of getting packets to IPv4 headdresses ETRs and for
unmodified IPv4 hosts to use as addresses for themselves: the IPv4
Global Unicast namespace.  My previous message also explains why an
ITR can't possibly be tunneling packets to w.x.y.z as an ETR (RLOC)
address while accepting incoming packets addressed to w.x.y.z as if
it was an "EID" address, so these packets would be mapped and
encapsulated to some ETR address.

>> ...
>> call for something to be said answering to what extent we expect EIDs
>> and RLOCs to overlap.

I agree.  I think my suggested changes to the draft Charter do a good
job of explaining this, and other crucial aspects of LISP, in a
concise and unambiguous manner:

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

Further discussion of these suggested changes:

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


> In my experience, on the Internet, generally if something isn't absolutely
> impossible, people will figure out a way to do it - and they will do it no
> matter whether there's a document saying that they should or should not do it.

I agree.

> (And they often are very clever in doing so - look at things like web site
> load-sharing traffic dispatchers, where a number of machines share a single IP
> address.)

Yes, but it is not always truly clever and wise.  Look at the mess of
ugliness, unpleasant surprises and things which just don't work which
many people made with the desktop publishing and now with HTML, CSS,
javascript and FLASH in website design and HTML email.

In particular, consider NAT . . .


> So if it's _possible_ to use the same bit pattern as both an EID and an RLOC,
> my guess is people will do it, no matter what the documents say. 

It is not possible.  The ITR will eat its own emitted encapsulated
packets and/or the packets emitted by other ITRs.  PTRs in the DFZ
will attract encapsulated packets and look up the mapping of what
they consider to be an EID address, and will then encapsulate the
already encapsulated packet and send it to some hapless ETR.


> And my take is that, because of _other_ concerns (e.g. limiting routing overhead), it
> will be technically possible, which means people probably will do it no
> matter what we say in any documents.

Please read my previous message:

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

and describe in detail how you thing it would be possible, in LISP
(or any other core-edge separation scheme) to use the one particular
address (or 32 bit pattern of bits or whatever you want to call it)
as both an EID and an RLOC.

  - Robin


[1] "Incrementally deployable" means different things to different
    people.  So I think it's use in the Charter needs to be expanded
    into something more specific.  See:

      http://www.ops.ietf.org/lists/rrg/2008/msg00957.html