draft-ietf-lisp-alt-01.txt   draft-ietf-lisp-alt-02.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: November 27, 2009 D. Lewis Expires: July 29, 2010 D. Lewis
Cisco Cisco
May 26, 2009 January 25, 2010
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-01.txt draft-ietf-lisp-alt-02.txt
Abstract
This document describes a method of building an alternative, logical
topology for managing Endpoint Identifier to Routing Locator mappings
using the Locator/ID Separation Protocol. The logical network is
built as an overlay on the public Internet using existing
technologies and tools, specifically the Border Gateway Protocol and
the Generic Routing Encapsulation. An important design goal for
LISP+ALT is to allow for the relatively easy deployment of an
efficient mapping system while minimizing changes to existing
hardware and software.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2009. This Internet-Draft will expire on July 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a method of building an alternative, logical described in the BSD License.
topology for managing Endpoint Identifier to Routing Locator mappings
using the Locator/ID Separation Protocol. The logical network is
built as an overlay on the public Internet using existing
technologies and tools, specifically the Border Gateway Protocol and
the Generic Routing Encapsulation. An important design goal for
LISP+ALT is to allow for the relatively easy deployment of an
efficient mapping system while minimizing changes to existing
hardware and software.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 8 4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Connectivity to non-LISP sites . . . . . . . . . . . . . . 8 4.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8
4.2. Caveats on the use of Data Probes . . . . . . . . . . . . 9 4.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9
4.3. Caveats on the use of Data Probes . . . . . . . . . . . . 9
5. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 10
5.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 10 5.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 11
5.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 11 5.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 11
5.3. LISP+ALT Router . . . . . . . . . . . . . . . . . . . . . 12 5.3. LISP+ALT Router (or ALT router for short) . . . . . . . . 12
5.4. ITR and ETR in a LISP+ALT Environment . . . . . . . . . . 12 5.4. ITR and ETR in a LISP+ALT Environment . . . . . . . . . . 13
5.5. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 13 5.5. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 13
6. EID Prefix Propagation and Map-Request Forwarding . . . . . . 14 6. EID Prefix Propagation and Map-Request Forwarding . . . . . . 14
6.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 14 6.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 14
6.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 14 6.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 14
7. BGP configuration and protocol considerations . . . . . . . . 16 7. BGP configuration and protocol considerations . . . . . . . . 16
7.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 16 7.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 16
7.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 16 7.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 16
8. EID-Prefix Aggregation . . . . . . . . . . . . . . . . . . . . 17 8. EID-Prefix Aggregation . . . . . . . . . . . . . . . . . . . . 17
8.1. Traffic engineering with LISP and LISP+ALT . . . . . . . . 17 8.1. Traffic engineering with LISP and LISP+ALT . . . . . . . . 17
8.2. Edge aggregation and dampening . . . . . . . . . . . . . . 18 8.2. Edge aggregation and dampening . . . . . . . . . . . . . . 18
skipping to change at page 6, line 14 skipping to change at page 6, line 14
3. Definition of Terms 3. Definition of Terms
LISP+ALT operates on two name spaces and introduces a new network LISP+ALT operates on two name spaces and introduces a new network
element, the LISP+ALT Router (see below). This section provides element, the LISP+ALT Router (see below). This section provides
high-level definitions of the LISP+ALT name spaces, network elements, high-level definitions of the LISP+ALT name spaces, network elements,
and message types. and message types.
The Alternative Logical Topology (ALT): The virtual overlay network The Alternative Logical Topology (ALT): The virtual overlay network
made up of tunnels between EID Prefix Aggregators. The Border made up of tunnels between EID Prefix Aggregators. The Border
Gateway Protocol (BGP) runs between LISP+ALT routers and is used Gateway Protocol (BGP) runs between ALT routers and is used to
to carry reachability information for EID prefixes. carry reachability information for EID prefixes.
Legacy Internet: The portion of the Internet which does not run LISP Legacy Internet: The portion of the Internet which does not run LISP
and does not participate in LISP+ALT. and does not participate in LISP+ALT.
LISP+ALT Router: The devices which run on the ALT. The ALT is a LISP+ALT Router: The devices which run on the ALT. The ALT is a
static network built using tunnels between LISP+ALT routers. static network built using tunnels between LISP+ALT routers.
These routers are deployed in a hierarchy in which routers at each These routers are deployed in a hierarchy in which routers at each
level in the this hierarchy are responsible for aggregating all level in the this hierarchy are responsible for aggregating all
EID prefixes learned from those logically "below" them and EID prefixes learned from those logically "below" them and
advertising summary prefixes to the routers logically "above" advertising summary prefixes to the routers logically "above"
them. All prefix learning and propagation between levels is done them. All prefix learning and propagation between levels is done
using BGP. LISP+ALT routers at the lowest level, or "edge", of using BGP. A LISP+ALT router at the lowest level, or "edge" of
the ALT learn EID prefixes either over a BGP session to ETRs or the ALT, learns EID prefixes from its "client" ETRs. See
through static routes (in the case of the "low-opex ETR"). See Section 4.1 for a description of how EID prefixes are learned at
Section 7 for details on how BGP is configured between the the "edge" of the ALT. See also Section 7 for details on how BGP
different network elements. is configured between the different network elements.
The primary function of LISP+ALT routers is to provide a The primary function of LISP+ALT routers is to provide a
lightweight forwarding infrastructure for LISP control-plane lightweight forwarding infrastructure for LISP control-plane
messages (Map-Request and Map-Reply), and to transport data messages (Map-Request and Map-Reply), and to transport data
packets when the packet has the same destination address in both packets when the packet has the same destination address in both
the inner (encapsulating) destination and outer destination the inner (encapsulating) destination and outer destination
addresses ((i.e., a Data Probe packet). addresses ((i.e., a Data Probe packet).
Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value 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 used in the source and destination address fields of the first
skipping to change at page 7, line 29 skipping to change at page 7, line 29
EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that
can be used to reach the EID. The term "mapping" refers to an can be used to reach the EID. The term "mapping" refers to an
EID-to-RLOC mapping. EID-to-RLOC mapping.
EID Prefix Reachability: An EID prefix is said to be "reachable" if EID Prefix Reachability: An EID prefix is said to be "reachable" if
one or more of its locators are reachable. That is, an EID prefix one or more of its locators are reachable. That is, an EID prefix
is reachable if the ETR (or its proxy) that is authoritative for a is reachable if the ETR (or its proxy) that is authoritative for a
given EID-to-RLOC mapping is reachable. given EID-to-RLOC mapping is reachable.
Default Mapping: A Default Mapping is a mapping entry for EID- Default Mapping: A Default Mapping is a mapping entry for EID-
prefix 0.0.0.0/0. It maps to a locator-set used for all EIDs in prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used
the Internet. If there is a more specific EID-prefix in the for all EIDs in the Internet. If there is a more specific EID-
mapping cache it overrides the Default Mapping entry. The Default prefix in the mapping cache it overrides the Default Mapping
Mapping route can be learned by configuration or from a Map-Reply entry. The Default Mapping route can be learned by configuration
message. or from a Map-Reply message.
Default Route: A Default Route in the context of LISP+ALT is a EID- Default Route: A Default Route in the context of LISP+ALT is a EID-
prefix value of 0.0.0.0/0 which is advertised by BGP on top of the prefix value of 0.0.0.0/0 (or 0::/0 for ipv6) which is advertised
ALT. The Default Route is used to realize a path for Data Probe by BGP on top of the ALT. The Default Route is used to create a
or Map-Request packets. forwarding path for a packet to be sent into the ALT (and ALT
datagram) on a router which does not have a full ALT forwarding
database.
4. The LISP 1.5 model 4. The LISP 1.5 model
As documented in [LISP], the LISP 1.5 model uses the same basic As documented in [LISP], the LISP 1.5 model uses the same basic
query/response protocol machinery as LISP 1.0. In particular, LISP+ query/response protocol machinery as LISP 1.0. In particular, LISP+
ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings
(both of these techniques are described in more detail in (both of these techniques are described in more detail in
Section 9.2): Section 9.2):
Data Probe: An ITR may send the first few data packets into the ALT Data Probe: An ITR may send the first few data packets into the ALT
to minimize packet loss and to probe for the mapping; the to minimize packet loss and to probe for the mapping; the
authoritative ETR will respond to the ITR with a Map-Reply message authoritative ETR will respond to the ITR with a Map-Reply message
when it receives the data packet over the ALT. Note that in this when it receives the data packet over the ALT. Note that in this
case, the inner Destination Address (DA), which is an EID, is case, the inner Destination Address (DA), which is an EID, is
copied to the outer DA and is routed over the ALT. copied to the outer DA and is routed over the ALT.
Map-Request: An ITR may also send a Map-Request message into the ALT Map-Request: An ITR may also send a Map-Request message into the ALT
to request the mapping. As in the Data Probe case, the to request the mapping. As in the Data Probe case, the
authoritative ETR will respond to the ITR with a Map-Reply authoritative ETR will respond to the ITR with a Map-Reply
message. In this case, the DA of the Map-Request MUST be an EID. message. Since the ALT only forwards on EID destinations, the DA
See [LISP] for the format of Map-Request and Map-Reply packets. of the Map-Request sent in to the ALT MUST be an EID. See [LISP]
for the format of Map-Request and Map-Reply packets.
ALT datagram: A Map-Request or Data Probe to be sent into or
forwarded on the ALT.
4.1. Routeability of EIDs
As with LISP 1.0, EIDs are routable and can be used, unaltered, as As with LISP 1.0, EIDs are routable and can be used, unaltered, as
the source and destination addresses in IP datagrams. Unlike in LISP the source and destination addresses in IP datagrams. Unlike in LISP
1.0, LISP 1.5 EIDs are not routable on the public Internet; instead, 1.0, LISP 1.5 EIDs are not routable on the public Internet; instead,
they are only routed over a separate, virtual topology referred to as they are only routed over a separate, virtual topology referred to as
the LISP Alternative Virtual Network. This network is built as an the LISP Alternative Virtual Network. This network is built as an
overlay on the public Internet using tunnels to interconnect LISP+ALT overlay on the public Internet using tunnels to interconnect LISP+ALT
routers. BGP is run over these tunnels to propagate the information routers. BGP is run over these tunnels to propagate the information
needed to route Data Probes and Map-Request/Replies. Importantly, needed to route ALT datagrams. Importantly, while the ETRs are the
while the ETRs are the source(s) of the unaggregated EID prefix data, source(s) of the unaggregated EID prefix data, LISP+ALT uses existing
LISP+ALT uses existing BGP mechanisms to aggressively aggregate this BGP mechanisms to aggressively aggregate this information. Note that
information. Note that ETRs are not required to participate (or an ETR is not required to participate (or prevented from
prevented from participating) in LISP+ALT; they may choose participating) in LISP+ALT; an ETR may choose to communicate its
communicate their mappings to their serving LISP+ALT router(s) at mappings to its serving LISP+ALT router(s) using subscription time
subscription time via configuration. ITRs are also not required to static configuration or through a dynamic mechanism such as that
participate in (nor prevented from participating in) LISP+ALT. described in [LISP-MS]. An ITR may similarly use a static EID
"default route" or other configuration as described in [LISP-MS] to
avoid the complexity of participating in the ALT.
4.1. Connectivity to non-LISP sites 4.2. Connectivity to non-LISP sites
As stated above, EIDs used as IP addresses by LISP sites are not As stated above, EIDs used as IP addresses by LISP sites are not
routable on the public Internet. This implies that, absent a routable on the public Internet. This implies that, absent a
mechanism for communication between LISP and non-LISP sites, mechanism for communication between LISP and non-LISP sites,
connectivity between them is not possible. To resolve this problem, connectivity between them is not possible. To resolve this problem,
an "interworking" technology has been defined; see [Interworking] for an "interworking" technology has been defined; see [Interworking] for
details. details.
4.2. Caveats on the use of Data Probes 4.3. Caveats on the use of Data Probes
It is worth noting that there has been a great deal of discussion and It is worth noting that there has been a great deal of discussion and
controversy about whether Data Probes are a good idea. On the one controversy about whether Data Probes are a good idea. On the one
hand, using them offers a method of avoiding the "first packet drop" hand, using them offers a method of avoiding the "first packet drop"
problem when an ITR does not have a mapping for a particular EID- problem when an ITR does not have a mapping for a particular EID-
prefix. On the other hand, forwarding data packets on the ALT would prefix. On the other hand, forwarding data packets on the ALT would
require that it either be engineered to support relatively high require that it either be engineered to support relatively high
traffic rates, which is not generally feasible for a tunneled traffic rates, which is not generally feasible for a tunneled
network, or that it be carefully designed to aggressively rate- limit network, or that it be carefully designed to aggressively rate- limit
traffic to avoid congestion or DoS attacks. There are also other traffic to avoid congestion or DoS attacks. There are also other
skipping to change at page 10, line 17 skipping to change at page 10, line 17
LISP+ALT is a hybrid push/pull architecture. Aggregated EID prefixes LISP+ALT is a hybrid push/pull architecture. Aggregated EID prefixes
are "pushed" among the LISP+ALT routers and, optionally, out to ITRs are "pushed" among the LISP+ALT routers and, optionally, out to ITRs
(which may elect to receive the aggregated information, as opposed to (which may elect to receive the aggregated information, as opposed to
simply using a default mapping). Specific EID-to-RLOC mappings are simply using a default mapping). Specific EID-to-RLOC mappings are
"pulled" by ITRs when they either send explicit LISP requests or data "pulled" by ITRs when they either send explicit LISP requests or data
packets on the alternate topology that result in triggered replies packets on the alternate topology that result in triggered replies
being generated by ETRs. being generated by ETRs.
The basic idea embodied in LISP+ALT is to use BGP, running over The basic idea embodied in LISP+ALT is to use BGP, running over
tunneled overlay network, to establish reachability required to route tunneled overlay network, to establish reachability required to route
Data Probes and Map-Requests over an alternate logical topology ALT datagrams over an alternate logical topology (ALT). The ALT
(ALT). The ALT BGPRoute Information Base (RIB) is comprised of EID BGPRoute Information Base (RIB) is comprised of EID prefixes and
prefixes and associated next hops. LISP+ALT routers interconnect associated next hops. LISP+ALT routers interconnect using eBGP and
using eBGP and propagate EID prefix updates, which are learned over propagate EID prefix updates, which are learned over eBGP connections
eBGP connections to authoritative ETRs, or by static configuration. to authoritative ETRs, or by static configuration. ITRs may also
ITRs may also eBGP peer with one or more LISP+ALT to learn the best eBGP peer with one or more LISP+ALT to learn the best ALT router to
ALT router to use to forward a Data Proble or Map-Request for a use to forward an ALT datagram for a particular prefix; in most
particular prefix; in most cases, an ITR will have a default EID cases, an ITR will have a default EID mapping pointing to one or more
mapping pointing to one or more LISP+ALT routers. LISP+ALT routers.
Note that while this document specifies the use of Generic Routing Note that while this document specifies the use of Generic Routing
Encapsulation (GRE) as a tunneling mechanism, there is no reason that Encapsulation (GRE) as a tunneling mechanism, there is no reason that
an ALT cannot be built using other tunneling technologies. In cases an ALT cannot be built using other tunneling technologies. In cases
where GRE does not meet security, management, or other operational where GRE does not meet security, management, or other operational
requirements, it is reasonable to use another tunneling technology requirements, it is reasonable to use another tunneling technology
that does. References to "GRE tunnel" in later sections of this that does. References to "GRE tunnel" in later sections of this
document should therefore not be taken as prohibiting or precluding document should therefore not be taken as prohibiting or precluding
the use of other, available tunneling mechanisms. the use of other, available tunneling mechanisms. Note also that two
LISP+ALT routers that are directly adjacent (with no layer-3 router
hops between them) need not use a tunnel between them; in this case,
BGP may be configured across the interfaces that connect to their
common subnet and that subnet is considered to be part of the ALT
topology. Use of techniques, such as "eBGP multihop", to forward ALT
datagrams through routers that do not participate in ALT routing, is
not recommended.
In summary, LISP+ALT uses BGP to propagate EID-prefix update In summary, LISP+ALT uses BGP to propagate EID-prefix update
information to facilitate forwarding a Map-Reqeusts or Data Probe to information to facilitate forwarding an ALT datagram to the ETR that
the ETR that holds the EID-to-RLOC mapping for that EID-prefix. This holds the EID-to-RLOC mapping for that EID-prefix. This reachability
reachability is carried as IPv4 or IPv6 NLRI without modification is carried as IPv4 or IPv6 NLRI without modification (since an EID
(since an EID prefix has the same syntax as IPv4 or IPv6 address prefix has the same syntax as IPv4 or IPv6 address prefix). LISP+ALT
prefix). LISP+ALT routers eBGP peer with one another, forming the routers eBGP peer with one another, forming the ALT. A LISP+ALT
ALT. A LISP+ALT router near the edge learns EID prefixes originated router near the edge learns EID prefixes originated by authoritative
by authoritative ETRs, either by eBGP peering with them or by ETRs. This may be via eBGP with the ETRs, by static configuration,
configuration. LISP+ALT routers aggregate EID prefixes, and forward or through some other dynamic mechanism such as that defined in
Data Probes and Map-Requests. [LISP-MS]. A LISP+ALT router may also be configured to aggregate EID
prefixes received from ETRs or from other LISP+ALT routers that are
topologically "downstream" from it.
5.1. ITR traffic handling 5.1. ITR traffic handling
When an ITR receives a packet originated by an end system within its When an ITR receives a packet originated by an end system within its
site (i.e. a host for which the ITR is the exit path out of the site) site (i.e. a host for which the ITR is the exit path out of the site)
and the destination for that packet is not known in the ITR's mapping and the destination for that packet is not known in the ITR's mapping
cache, the ITR encapsulates the packet in a LISP header, copying the cache, the ITR encapsulates the packet in a LISP header, copying the
inner destination address (EID) to the outer destination address inner destination address (EID) to the outer destination address
(RLOC), and transmits it through a GRE tunnel to a LISP+ALT router in (RLOC), and transmits it through a GRE tunnel to a LISP+ALT router in
the ALT. This "first hop" LISP+ALT router uses EID-prefix routing the ALT (see also [LISP-MS] for non-ALT-connected ITRs, noting that
information learned from other LISP+ALT routers via BGP to guide the an ITR cannot send Data Probes to a Map-Server). This "first hop"
packet to the ETR which "owns" the prefix. Upon receipt by the ETR, LISP+ALT router uses EID-prefix routing information learned from
normal LISP processing occurs: the ETR responds to the ITR with a other LISP+ALT routers via BGP to guide the packet to the ETR which
LISP Map-Reply that lists the RLOCs (and, thus, the ETRs to use) for "owns" the prefix. Upon receipt by the ETR, normal LISP processing
the EID prefix. The ETR also de-encapsulates the packet and occurs: the ETR responds to the ITR with a LISP Map-Reply that lists
transmits it toward its destination. the RLOCs (and, thus, the ETRs to use) for the EID prefix. The ETR
also de-encapsulates the packet and transmits it toward its
destination.
Upon receipt of the Map-Reply, the ITR installs the RLOC information Upon receipt of the Map-Reply, the ITR installs the RLOC information
for a given prefix into a local mapping database. With these mapping for a given prefix into a local mapping database. With these mapping
entries stored, additional packets destined to the given EID prefix entries stored, additional packets destined to the given EID prefix
are routed directly to a viable ETR without use of the ALT, until are routed directly to a viable ETR without use of the ALT, until
either the entry's TTL has expired, or the ITR can otherwise find no either the entry's TTL has expired, or the ITR can otherwise find no
reachable ETR. Note that a valid mapping (not timed-out) may exist reachable ETR. Note that a valid mapping (not timed-out) may exist
that contains no reachable RLOCs (i.e. all paths to that ETR are that contains no reachable RLOCs (i.e. all paths to that ETR are
down); in this case, packets destined to the EID prefix are dropped, down); in this case, packets destined to the EID prefix are dropped,
not routed through the ALT. not routed through the ALT.
skipping to change at page 11, line 47 skipping to change at page 12, line 11
aggregation at merge points in the tree. Building such a structure aggregation at merge points in the tree. Building such a structure
should minimize the number of EID-prefixes carried by LISP+ALT nodes should minimize the number of EID-prefixes carried by LISP+ALT nodes
near the top of the hierarchy. near the top of the hierarchy.
Since the ALT will not need to change due to subscription or policy Since the ALT will not need to change due to subscription or policy
reasons, the topology can remain relatively static and aggregation reasons, the topology can remain relatively static and aggregation
can be sustained. Because routing on the ALT uses BGP, the same can be sustained. Because routing on the ALT uses BGP, the same
rules apply for generating aggregates; in particular, a LISP+ALT rules apply for generating aggregates; in particular, a LISP+ALT
router should only be configured to generate an aggregate if it is router should only be configured to generate an aggregate if it is
configured with BGP sessions to all of the originators of components configured with BGP sessions to all of the originators of components
(more-specifics prefixes) of that aggregae; not all of the components (more-specifics prefixes) of that aggregate; not all of the
of need to be present for the aggregate to be originated (some may be components of need to be present for the aggregate to be originated
holes in the covering prefix and some may be down) but the (some may be holes in the covering prefix and some may be down) but
aggregating router must be configured to learn the state of all of the aggregating router must be configured to learn the state of all
the components. of the components.
As an example, consider ETRs that are originating EID prefixes for As an example, consider ETRs that are originating EID prefixes for
10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT 10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT
router should only be configured to generate an aggregate for router should only be configured to generate an aggregate for
10.1.0.0/16 if it has BGP sessions configured with all of these ETRs, 10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,
in other words, only if it has sufficient knowledge about the state in other words, only if it has sufficient knowledge about the state
of those prefixes to summarize them. of those prefixes to summarize them.
Under what circumstances the ALT router actually generates the Under what circumstances the ALT router actually generates the
aggregate is a matter of local policy: in some cases, it will be aggregate is a matter of local policy: in some cases, it will be
statically configured to do so at all times with a "static discard" statically configured to do so at all times with a "static discard"
route. In other cases, it may be configured to only generate the route. In other cases, it may be configured to only generate the
aggregate prefix if at least one of the components of the aggregate aggregate prefix if at least one of the components of the aggregate
is learned via BGP. is learned via BGP.
This implies that two ALTs that share an overlapping set of prefixes This implies that two ALT routers that share an overlapping set of
must exchange those prefixes if either is to generate and export a prefixes must exchange those prefixes if either is to generate and
covering aggregate for those prefixes. It also implies that an ETR export a covering aggregate for those prefixes. It also implies that
that originates a prefix must maintain BGP sessions with all ALT an ETR which connects to the ALT using BGP must maintain BGP sessions
routers that are configured to originate an aggregate which covers with all of the ALT routers that are configured to originate an
that prefix. aggregate which covers that prefix. See also [LISP-MS] for an
example of other ways that prefix origin consistency and aggregation
are maintained.
Note: much is currently uncertain about the best way to build the ALT Note: much is currently uncertain about the best way to build the ALT
network; as testing and prototype deployment proceeds, a guide to how network; as testing and prototype deployment proceeds, a guide to how
to best build the ALT network will be developed. to best build the ALT network will be developed.
5.3. LISP+ALT Router 5.3. LISP+ALT Router (or ALT router for short)
A LISP+ALT Router has the following functionality: A LISP+ALT Router has the following functionality:
1. It runs, at a minimum, the eBGP part of the BGP protocol. 1. It runs, at a minimum, the eBGP part of the BGP protocol.
2. It supports a separate RIB which uses next-hop GRE tunnel 2. It supports a separate RIB which uses next-hop GRE tunnel
interfaces for forwarding Data Probes and Map-Requests. interfaces for forwarding ALT datagrams.
3. It can act as a "proxy-ITR" to support non-LISP sites. 3. It can act as a "proxy-ITR" to support non-LISP sites.
4. It can act as an ETR, or as a recursive or re-encapsulating ITR 4. It can act as an ETR, or as a recursive or re-encapsulating ITR
to reduce mapping tables in site-based LISP routers. to reduce mapping tables in site-based LISP routers.
5.4. ITR and ETR in a LISP+ALT Environment 5.4. ITR and ETR in a LISP+ALT Environment
An ITR using LISP+ALT may have additional functionality as follows: An ITR using LISP+ALT may have additional functionality as follows:
1. If it is also acting as a LISP+ALT Router, it sends Data Probes 1. If it is also acting as a LISP+ALT Router, it sends ALT datagrams
or Map-Requests on the BGP best path computed GRE tunnel for each on the BGP best path computed GRE tunnel for each EID prefix.
EID prefix.
2. When acting solely as a ITR, it sends Data Probes or Map-Requests 2. When acting solely as a ITR, it sends ALT datagrams directly to a
directly to a configured LISP+ALT router. configured LISP+ALT router.
An ETR using LISP+ALT may also behave slightly differently: An ETR using LISP+ALT may also behave slightly differently:
1. If it is also acting as a LISP+ALT router, it advertises its 1. If it is also acting as a LISP+ALT router, it advertises its
configured EID-prefixes into BGP for distribution through the configured EID-prefixes into BGP for distribution through the
ALT. ALT.
2. It receives Data Probes and Map-Requests only over GRE tunnel(s) 2. It receives ALT datagrams only from its "upstream" LISP+ALT
to its "upstream" LISP+ALT router(s) and responds with Map- routers over the GRE tunnel(s) configured to it/them. It
Replies for the EID prefixes that it "owns". responds with Map-Replies for the EID prefixes that it "owns".
5.5. Use of GRE and BGP between LISP+ALT Routers 5.5. Use of GRE and BGP between LISP+ALT Routers
The ALT network is built using GRE tunnels between LISP+ALT routers. The ALT network is built using GRE tunnels between LISP+ALT routers.
eBGP sessions are configured over those tunnels, with each LISP+ALT eBGP sessions are configured over those tunnels, with each LISP+ALT
router acting as a separate AS "hop" in a Path Vector for BGP. For router acting as a separate AS "hop" in a Path Vector for BGP. For
the purposes of LISP+ALT, the AS-path is used solely as a shortest- the purposes of LISP+ALT, the AS-path is used solely as a shortest-
path determination and loop-avoidance mechanism. Because all next- path determination and loop-avoidance mechanism. Because all next-
hops are on tunnel interfaces, no IGP is required to resolve those hops are on tunnel interfaces, no IGP is required to resolve those
next-hops to exit interfaces. next-hops to exit interfaces.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
the ALT - an ETR sends a Map-Reply to the source RLOC learned from the ALT - an ETR sends a Map-Reply to the source RLOC learned from
the original Map-Request. There may be scenarios, perhaps to the original Map-Request. There may be scenarios, perhaps to
encourage caching of EID-to-RLOC mappings by ALT routers, where Map- encourage caching of EID-to-RLOC mappings by ALT routers, where Map-
Replies could be sent over the ALT or where a "first-hop" ALT router Replies could be sent over the ALT or where a "first-hop" ALT router
might modify the originating RLOC on a Map-Request received from an might modify the originating RLOC on a Map-Request received from an
ITR to force the Map-Reply to be sent to it; these cases will not be ITR to force the Map-Reply to be sent to it; these cases will not be
supported by initial LISP+ALT implementations but may be subject to supported by initial LISP+ALT implementations but may be subject to
future experimentation. future experimentation.
LISP+ALT routers propagate mapping information for use by ITRs (when LISP+ALT routers propagate mapping information for use by ITRs (when
making Map-Requests or sending Data Probes) using eBGP [RFC4271]. sending ALT datagrams) using eBGP [RFC4271]. eBGP is run on the
eBGP is run on the inter-LISP+ALT router links, and and possibly inter-LISP+ALT router links, and possibly between an edge ("last
between an edge ("last hop") LISP+ALT router and an ETR or between an hop") LISP+ALT router and an ETR or between an edge ("first hop")
edge ("first hop") LISP+ALT router and an ITR. The ALT eBGP RIB LISP+ALT router and an ITR. The ALT eBGP RIB consists of aggregated
consists of aggregated EID prefixes and their next hops toward the EID prefixes and their next hops toward the authoritative ETR for
authoritative ETR for that EID prefix. that EID prefix.
6.1. Changes to ITR behavior with LISP+ALT 6.1. Changes to ITR behavior with LISP+ALT
When using LISP+ALT, an ITR always sends either Data Probes or Map- When using LISP+ALT, an ITR sends ALT datagrams to one of its
Requests to one of its "upstream" LISP+ALT routers. As in basic "upstream" LISP+ALT routers; these are sent only to obtain new EID-
LISP, it should use one of its RLOCs as the source address of these to-RLOC mappings - RLOC probe and cache TTL refresh Map-Requests are
queries; it should explicitly not use a tunnel interface as the not sent on the ALT. As in basic LISP, it should use one of its
source address as doing so will cause replies to be forwarded over RLOCs as the source address of these queries; it should explicitly
the tunneled topology and may be problematic if the tunnel interface not use a tunnel interface as the source address as doing so will
address is not explicitly routed throughout the ALT. If the ITR is cause replies to be forwarded over the tunneled topology and may be
running BGP with the LISP+ALT router(s), it selects the appropriate problematic if the tunnel interface address is not explicitly routed
LISP+ALT router based on the BGP information received. If it is not throughout the ALT. If the ITR is running BGP with the LISP+ALT
running BGP, it uses static configuration to select a LISP+ALT router(s), it selects the appropriate LISP+ALT router based on the
router; in the general case, this will effectively be an "EID-prefix BGP information received. If it is not running BGP, it uses static
default route". configuration to select a LISP+ALT router; in the general case, this
will effectively be an "EID-prefix default route".
6.2. Changes to ETR behavior with LISP+ALT 6.2. Changes to ETR behavior with LISP+ALT
If an ETR connects using BGP to one or more LISP+ALT router(s), it If an ETR connects using BGP to one or more LISP+ALT router(s), it
simply announces its EID-prefix to those LISP+ALT routers. In the simply announces its EID-prefix to those LISP+ALT routers. Note that
"low-opex" case, where the ETR does not use BGP, it will still have a when an ETR generates a Map-Reply message to return to a querying
GRE tunnel to one or more LISP+ALT routers; these LISP+ALT router(s) ITR, it sends it to the ITR's source-RLOC (i.e., on the underlying
the ETR must route Map-Requests and Data Probes to the ETR and Internet topology, not on the ALT; this avoids any latency penalty
contain configuration (in effect, static routes) for the ETR's EID- (or "stretch") that might be incurred by routing over the ALT).
prefixes. Note that in either case, when an ETR generates a Map-
Reply message to return to a querying ITR, it sends it to the ITR's
source-RLOC (i.e., on the underlying Internet topology, not on the
ALT; this avoids any latency penalty that might be incurred by
routing over the ALT).
See also Section 9 for more details about the "low-opex" ETR and ITR
configurations.
7. BGP configuration and protocol considerations 7. BGP configuration and protocol considerations
7.1. Autonomous System Numbers (ASNs) in LISP+ALT 7.1. Autonomous System Numbers (ASNs) in LISP+ALT
The primary use of BGP today is to define the global Internet routing The primary use of BGP today is to define the global Internet routing
topology in terms of its participants, known as Autonomous Systems. topology in terms of its participants, known as Autonomous Systems.
LISP+ALT specifies the use of BGP to create a global EID-to-RLOC LISP+ALT specifies the use of BGP to create a global EID-to-RLOC
mapping database which, while related to the global routing database, mapping database which, while related to the global routing database,
serves a very different purpose and is organized into a very serves a very different purpose and is organized into a very
skipping to change at page 18, line 16 skipping to change at page 18, line 16
Note also that normal BGP best common practices apply to the ALT Note also that normal BGP best common practices apply to the ALT
network. In particular, first-hop ALT routers will aggregate EID network. In particular, first-hop ALT routers will aggregate EID
prefixes and dampen changes to them in the face of excessive updates. prefixes and dampen changes to them in the face of excessive updates.
Since EID prefix assignments are not expected to change with anywhere Since EID prefix assignments are not expected to change with anywhere
as frequently BGP prefix reachability on the Internet, such dampening as frequently BGP prefix reachability on the Internet, such dampening
should be very rare and might be worthy of logging as an exceptional should be very rare and might be worthy of logging as an exceptional
event. It is again worth noting that the ALT carries only EID event. It is again worth noting that the ALT carries only EID
prefixes, along with BGP-generated paths to the ETRs that source prefixes, along with BGP-generated paths to the ETRs that source
those prefixes as advertisements travel over the logical topology; those prefixes as advertisements travel over the logical topology;
this set of information is considerablly less volitile than the this set of information is considerablly less volatile than the
actual EID-to-RLOC mappings. actual EID-to-RLOC mappings.
9. Connecting sites to the ALT network 9. Connecting sites to the ALT network
9.1. ETRs originating information into the ALT 9.1. ETRs originating information into the ALT
EID prefix information is originated into the ALT by two different EID prefix information is originated into the ALT by two different
mechanisms: mechanisms:
eBGP: An ETR may participate in the LISP+ALT overlay network by eBGP: An ETR usually participates in the LISP+ALT overlay network by
running eBGP to one or more LISP+ALT router(s) over GRE tunnel(s). running eBGP to one or more LISP+ALT router(s) over tunnel(s).
In this case, the ETR advertises reachability for its EID prefixes The ETR advertises reachability for its EID prefixes over these
over these eBGP connection(s). The LISP+ALT router(s) that eBGP connection(s). The LISP+ALT router(s) that receive(s) these
receive(s) these prefixes then propagate(s) them into the ALT. prefixes then propagate(s) them into the ALT. Here the ETR is
Here the ETR is simply an eBGP peer of LISP+ALT router(s) at the simply an eBGP peer of LISP+ALT router(s) at the edge of the ALT.
edge of the ALT. Where possible, a LISP+ALT router that receives Where possible, a LISP+ALT router that receives EID prefixes from
EID prefixes from an ETR via eBGP should aggregate that an ETR via eBGP should aggregate that information.
information.
Configuration: One or more LISP+ALT router(s) may be configured to Configuration: One or more LISP+ALT router(s) may be configured to
originate an EID prefix on behalf of the non-BGP-speaking ETR that originate an EID prefix on behalf of the non-BGP-speaking ETR that
is authoritative for a prefix. As in the case above, the ETR is is authoritative for a prefix. As in the case above, the ETR is
connected to LISP+ALT router(s) using GRE tunnel(s) but rather connected to LISP+ALT router(s) using GRE tunnel(s) but rather
than BGP being used, the LISP+ALT router(s) are configured with than BGP being used, the LISP+ALT router(s) are configured with
what are in effect "static routes" for the EID prefixes "owned" by what are in effect "static routes" for the EID prefixes "owned" by
the ETR. The GRE tunnel is used to route Map-Requests to the ETR. the ETR. The GRE tunnel is used to route Map-Requests to the ETR.
Note that the LISP+ALT router could also serve as a proxy for its Note that the LISP+ALT router could also serve as a proxy for its
TCP-connected ETRs. TCP-connected ETRs.
skipping to change at page 20, line 19 skipping to change at page 20, line 18
In the case in which the ITR is connected to some set of LISP+ALT In the case in which the ITR is connected to some set of LISP+ALT
routers without eBGP, the ITR sends Map-Requests to any of its routers without eBGP, the ITR sends Map-Requests to any of its
connected LISP+ALT routers. connected LISP+ALT routers.
An ITR may also choose to send the first few data packets over the An ITR may also choose to send the first few data packets over the
ALT to minimize packet loss and reduce mapping latency. In this ALT to minimize packet loss and reduce mapping latency. In this
case, the data packet serves as a mapping probe (Data Probe) and the case, the data packet serves as a mapping probe (Data Probe) and the
ETR which receives the data packet (over the ALT) responds with a ETR which receives the data packet (over the ALT) responds with a
Map-Reply is sent to the ITR's source-RLOC using the underlying Map-Reply is sent to the ITR's source-RLOC using the underlying
topology. Note that the use of Data Probes is discouraged at this topology. Note that the use of Data Probes is discouraged at this
time (see Section 4.2). time (see Section 4.3).
In general, an ITR will establish connections only to LISP+ALT In general, an ITR will establish connections only to LISP+ALT
routers at the "edge" of the ALT (typically two for redundancy) but routers at the "edge" of the ALT (typically two for redundancy) but
there may also be situations where an ITR would connect to other there may also be situations where an ITR would connect to other
LISP+ALT routers to receive additional, shorter path information LISP+ALT routers to receive additional, shorter path information
about a portion of the ALT of interest to it. This can be about a portion of the ALT of interest to it. This can be
accomplished by establishing GRE tunnels between the ITR and the set accomplished by establishing GRE tunnels between the ITR and the set
of LISP+ALT routers with the additional information. This is a of LISP+ALT routers with the additional information. This is a
purely local policy issue between the ITR and the LISP+ALT routers in purely local policy issue between the ITR and the LISP+ALT routers in
question. question.
skipping to change at page 22, line 45 skipping to change at page 22, line 45
about a LISP destination sites' TE policy by sending legitimate about a LISP destination sites' TE policy by sending legitimate
mapping requests messages and then observing the RLOC mapping mapping requests messages and then observing the RLOC mapping
replies? Is this information useful in attacking or subverting replies? Is this information useful in attacking or subverting
peer relationships? Note that LISP 1.0 has a similar data-plane peer relationships? Note that LISP 1.0 has a similar data-plane
reconnaissance issue. reconnaissance issue.
Scaling of LISP+ALT router Resources: Paths through the ALT may be Scaling of LISP+ALT router Resources: Paths through the ALT may be
of lesser bandwidth than more "direct" paths; this may make them of lesser bandwidth than more "direct" paths; this may make them
more prone to high-volume denial-of-service attacks. For this more prone to high-volume denial-of-service attacks. For this
reason, all components of the ALT (ETRs and ALT routers) should be reason, all components of the ALT (ETRs and ALT routers) should be
prepared to rate-limit traffic that could be received across the prepared to rate-limit traffic (ALT datagrams) that could be
ALT (Map-Requests and Data Probes). received across the ALT.
UDP Map-Reply from ETR: Since Map-Replies packets are sent directly UDP Map-Reply from ETR: Since Map-Replies packets are sent directly
from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable
to various types of DoS attacks. to various types of DoS attacks.
11.2. Survey of LISP+ALT Security Mechanisms 11.2. Survey of LISP+ALT Security Mechanisms
Explicit peering: The devices themselves can both prioritize Explicit peering: The devices themselves can both prioritize
incoming packets as well as potentially do key checks in hardware incoming packets as well as potentially do key checks in hardware
to protect the control plane. to protect the control plane.
skipping to change at page 24, line 9 skipping to change at page 24, line 9
For example, should either sBGP [I-D.murphy-bgp-secr] or soBGP For example, should either sBGP [I-D.murphy-bgp-secr] or soBGP
[I-D.white-sobgparchitecture] become widely deployed it expected that [I-D.white-sobgparchitecture] become widely deployed it expected that
LISP+ALT could use these mechanisms to provide authentication of EID- LISP+ALT could use these mechanisms to provide authentication of EID-
to-RLOC mappings, and EID origination. to-RLOC mappings, and EID origination.
12. Acknowledgments 12. Acknowledgments
Many of the ideas described in this document were developed during Many of the ideas described in this document were developed during
detailed discussions with Scott Brim and Darrel Lewis, who made many detailed discussions with Scott Brim and Darrel Lewis, who made many
insightful comments on earlier versions of this document. insightful comments on earlier versions of this document. Additional
thanks are due to Hannu Flinck and Amit Jain who offered many helpful
suggestions for the -02 version.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
skipping to change at page 25, line 42 skipping to change at page 25, line 42
[I-D.white-sobgparchitecture] [I-D.white-sobgparchitecture]
White, R., "Architecture and Deployment Considerations for White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)", Secure Origin BGP (soBGP)",
draft-white-sobgparchitecture-00 (work in progress), draft-white-sobgparchitecture-00 (work in progress),
May 2004. May 2004.
[Interworking] [Interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and ipv6", "Interworking LISP with IPv4 and ipv6",
draft-ietf-lisp-interworking-00.txt (work in progress), draft-ietf-lisp-interworking-01.txt (work in progress),
May 2009. January 2010.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-00.txt (work in progress), May 2009. draft-ietf-lisp-06.txt (work in progress), January 2010.
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-04.txt (work in progress),
October 2009.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
Cisco Cisco
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: vaf@cisco.com Email: vaf@cisco.com
 End of changes. 38 change blocks. 
149 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/