Short version: I am perplexed to be defending draft-farinacci-lisp's
crystal clear definitions of EID and RLOC against
misunderstandings. The definitions are at the end of
this message.
I am replying to Sam Hartman and John Zweibel.
Dino, Vince, David and Darrel: You wrote draft-
farinacci-lisp. Can you comment on this debate?
Vince, can you describe the definition of "namespace"
you used in your presentation today:
http://www3.ietf.org/proceedings/09mar/slides/lisp-2.ppt
which accords with the prohibition of using an EID as
an RLOC? An example of the separate namespaces
would help. According to my understanding of the
accepted definition of "namespace":
http://www.firstpr.com.au/ip/ivip/namespace/
the separate EID and RLOC namespaces you mention mean
that a single numeric IP address could be used as
both an EID and an RLOC at the same time - and that
therefore there must be a mechanism or context by
which any device (an ITR or ETR) which needs to
distinguish between the two ways of interpreting the
address can know whether the address is being used as
an EID or as an RLOC.
BTW, I haven't yet listened to today's meeting.
Hi Sam,
I don't understand how you decided, even tentatively, on rough
consensus:
http://www.ietf.org/mail-archive/web/lisp/current/msg00336.html
I think there has been enough discussion on-list and other
private comments that the rough consensus of the participants so
far is that there will be cases where the same IP stands both as
an EID and a RLOC.
RFC 2418 considers rough consensus determinations only for mailing
list discussions and face-to-face meetings. The "private comments"
you mention are not part of either - and are not visible to me or
other list participants.
The only instance of a list message supporting the view that a single
IP address could simultaneously be used as an EID and and RLOC seems
to be from Noel:
http://www.ietf.org/mail-archive/web/lisp/current/msg00332.html
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. 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.
Noel provides no example of how this would work to counter my
argument that it could not work: search for "an ITR will eat its own
emitted encapsulated packet" in msg00338.html.
You wrote:
> What do you mean that no EID is also an RLOC? It's not clear to me
> that in interworking cases this is always true.
I don't see how "internetworking" affects the draft-farinacci-lisp
prohibition of using any address as both an EID and RLOC.
In the context of LISP I understand "internetworking" to mean
arrangements to enable hosts in networks without ITRs to send packets
successfully to host on EID addresses. Proxy Tunnel Routers (PTRs -
equivalent to Ivip OITRDs) solve this problem as described in
draft-lewis-lisp-interworking-02.
Without PTRs (LISP before 2007-12-07) an EID address was not
covered by any BGP advertised prefix. So hosts in networks (ISP
and end-user) without ITRs could not send a packet to any host
with an EID address.
I proposed a solution to this on 2007-05-15:
http://www.ietf.org/mail-archive/web/ram/current/msg01518.html
and this appeared in the first Ivip I-D a month later, as "Anycast
ITRs in the core/DFZ". Prompted by a LISP team member who
repeatedly reminded that "anycast" was the wrong term, I renamed
them to "Open ITRs in the DFZ" (OITRD) in 2008.
PTRs and OITRDs are functionally identical, but the business and
operational arrangements for LISP are less clear than for Ivip.
With PTRs, LISP is potentially practical, since the EID address of
some host in an a LISP-mapped EID prefix of an end-user network is
part of a prefix which is advertised by one or ideally multiple PTRs
in the DFZ. (For scaling reasons, this BGP advertised prefix should
cover the EID space of many end-user networks, such as dozens to
tens of thousands.)
That does not make this host's EID address also an RLOC.
The formal definition of RLOC is that it can't be an EID address and
that RLOCs must be used for ITR and ETR addresses. As noted below,
in actual usage in LISP discussion, I think "RLOC" has come to mean a
broader set of IP addresses - I think every global unicast address
which is not an EID.
If you think that an IP address could be used both as an EID and an
RLOC, please show where this is required or allowed for in the LISP
I-Ds and give an example of how it would work, ideally in a way
which disproves my "ITR will eat its own ..." argument.
Hi John,
You wrote:
>> Since 2007-01 draft-farinacci-lisp-00 to 12 has this as an
>> absolute requirement:
>>
>> EIDs MUST NOT be used as LISP RLOCs.
>
> This does not say you can't use the same IP address for an EID
> and for an RLOC.
This is exactly what it says and means.
I am giving up my usual "I think ..." stuff because these definitions
are completely unambiguous.
In LISP (as a practical solution to the routing scaling problem) EIDs
and RLOCs are two classes of address within the global unicast
address ranges of IPv4 and IPv6.
The definitions make it clear that "EID" and "RLOC" are two disjoint
sets of addresses:
EIDs MUST NOT be used as LISP RLOCs.
In LISP discussions, "RLOC" has also frequently been used to refer to
an IP address which are used by a host or ordinary router, but which
is not an EID and which are not used for ITRs or ETRs. This extends
the set of RLOC addresses well beyond those used for ITRs and ETRs.
It is my impression that this broader definition of "RLOC" means
something like:
Any address in the global unicast set of addresses which is not
an EID. An EID address is any address which matches a prefix
in the mapping database.
> It says EID and RLOC functions cannot be assigned to
> the same interface at the same time.
No it doesn't. EID and RLOC are two separated classes of address.
The definitions are purely about addresses and how to use them.
There is no mention of interfaces.
An interface could have two IP addresses. Address A could be part
of the EID subset of the address range and address B could be of the
RLOC subset. Then the one interface can function perfectly well as
both an RLOC (such as for an ITR or ETR or both functions combined,
or as a host or router on non LISP-mapped address space) and also
as an EID: as a host or router in an end-user network which uses
LISP-mapped address space
> Or, another way of looking at it, an interface cannot be in EID
> space and in RLOC space.
Yes it can, as just described.
- Robin
There have been no substantial changes in the definition of RLOC and
EID since version 00 in January 2007.
http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8
Routing Locator (RLOC): the IPv4 or IPv6 address of an egress
tunnel router (ETR). It is the output of a EID-to-RLOC mapping
lookup. An EID maps to one or more RLOCs. Typically, RLOCs are
numbered from topologically-aggregatable blocks that are assigned
to a site at each point to which it attaches to the global
Internet; where the topology is defined by the connectivity of
provider networks, RLOCs can be thought of as PA addresses.
Multiple RLOCs can be assigned to the same ETR device or to
multiple ETR devices at a site.
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
used in the source and destination address fields of the first
(most inner) LISP header of a packet. The host obtains a
destination EID the same way it obtains an destination address
today, for example through a DNS lookup or SIP exchange. The
source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts.
*** EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be
assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure
is not visible to the global routing system.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.