draft-ietf-lisp-alt-07.txt   draft-ietf-lisp-alt-08.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: January 1, 2012 D. Lewis Expires: March 11, 2012 D. Lewis
Cisco Cisco
June 30, 2011 September 8, 2011
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-07.txt draft-ietf-lisp-alt-08.txt
Abstract Abstract
This document describes a simple distributed index system to be used This document describes a simple distributed index system to be used
by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
which holds the mapping information for a particular Endpoint which holds the mapping information for a particular Endpoint
Identifier (EID). The MR can then query that ETR to obtain the Identifier (EID). The MR can then query that ETR to obtain the
actual mapping information, which consists of a list of Routing actual mapping information, which consists of a list of Routing
Locators (RLOCs) for the EID. Termed the Alternative Logical Locators (RLOCs) for the EID. Termed the Alternative Logical
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 1, 2012. This Internet-Draft will expire on March 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10
3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13
4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 16 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17
6. BGP configuration and protocol considerations . . . . . . . . 18 6. BGP configuration and protocol considerations . . . . . . . . 18
6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18
6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18
7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19
7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19
7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19
7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20
7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20
8. Connecting sites to the ALT network . . . . . . . . . . . . . 22 8. Connecting sites to the ALT network . . . . . . . . . . . . . 22
8.1. ETRs originating information into the ALT . . . . . . . . 22 8.1. ETRs originating information into the ALT . . . . . . . . 22
skipping to change at page 4, line 41 skipping to change at page 4, line 41
to-RLOC mappings. What it does provide is a forwarding path from an to-RLOC mappings. What it does provide is a forwarding path from an
ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
holds that mapping. The ITR/MR uses this path to send an ALT holds that mapping. The ITR/MR uses this path to send an ALT
Datagram (see Section 3) to an ETR which then responds with a Map- Datagram (see Section 3) to an ETR which then responds with a Map-
Reply containing the needed mapping information. Reply containing the needed mapping information.
One design goal for LISP+ALT is to use existing technology wherever One design goal for LISP+ALT is to use existing technology wherever
possible. To this end, the ALT is intended to be built using off- possible. To this end, the ALT is intended to be built using off-
the-shelf routers which already implement the required protocols (BGP the-shelf routers which already implement the required protocols (BGP
and GRE); little, if any, LISP-specific modifications should be and GRE); little, if any, LISP-specific modifications should be
needed for such devices to be deployed on the ALT. Note, though, needed for such devices to be deployed on the ALT (see Section 7 for
that organizational and operational considerations suggest that ALT aggregation requirements). Note, though, that organizational and
Routers be both logically and physically separate from the "native" operational considerations suggest that ALT Routers be both logically
Internet packet transport system; deploying this overlay on those and physically separate from the "native" Internet packet transport
routers which are already participating in the global routing system system; deploying this overlay on those routers which are already
and actively forwarding Internet traffic is not recommended. participating in the global routing system and actively forwarding
Internet traffic is not recommended.
This specification is experimental, and there are areas where further
experience is needed to understand the best implementation strategy,
operational model, and effects on Internet operations. These areas
include:
o application effects of on-demand route map discovery
o tradeoff in connection setup time vs. ALT design and performance
when using a Map Request instead of carring initial user data in a
Data Probe
o best practical ways to build ALT hierarchies
o effects of route leakage from ALT to the current Internet,
particularly for LISP-to-non-LISP interworking
o effects of exceptional situations, such as denial-of-service
attacks
Experimentation, measurements, and deployment experience on these
aspects is appreciated. While these issues are conceptually well-
understood (e.g. an ALT lookup causes potential delay for the first
packet destined to a given network), the real-world operational
effects are much less clear.
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
provides the definitions of terms used in this document. Section 3 provides the definitions of terms used in this document. Section 3
outlines the LISP ALT model, where EID prefixes are routed across an outlines the LISP ALT model, where EID prefixes are routed across an
overlay network. Section 4 provides a basic overview of the LISP overlay network. Section 4 provides a basic overview of the LISP
Alternate Topology architecture, and Section 5 describes how the ALT Alternate Topology architecture, and Section 5 describes how the ALT
uses BGP to propagate Endpoint Identifier reachability over the uses BGP to propagate Endpoint Identifier reachability over the
overlay network and Section 6 describes other considerations for overlay network and Section 6 describes other considerations for
using BGP on the ALT. Section 7 describes the construction of the using BGP on the ALT. Section 7 describes the construction of the
ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT
skipping to change at page 9, line 19 skipping to change at page 9, line 19
of packet that an ITR can originate to obtain EID-to-RLOC mappings: of packet that an ITR can originate to obtain EID-to-RLOC mappings:
Map-Request: A Map-Request message is sent into the ALT to request Map-Request: A Map-Request message is sent into the ALT to request
an EID-to-RLOC mapping. The ETR which owns the mapping will an EID-to-RLOC mapping. The ETR which owns the mapping will
respond to the ITR with a Map-Reply message. Since the ALT only respond to the ITR with a Map-Reply message. Since the ALT only
forwards on EID destinations, the destination address of the Map- forwards on EID destinations, the destination address of the Map-
Request sent on the ALT must be an EID. Request sent on the ALT must be an EID.
Data Probe: Alternatively, an ITR may encapsulate and send the first Data Probe: Alternatively, an ITR may encapsulate and send the first
data packet destined for an EID with no known RLOCs into the ALT data packet destined for an EID with no known RLOCs into the ALT
as a Data Probe. This might be done minimize packet loss and to as a Data Probe. This might be done to minimize packet loss and
probe for the mapping. As above, the authoritative ETR for the to probe for the mapping. As above, the authoritative ETR for the
EID-prefix will respond to the ITR with a Map-Reply message when EID-prefix will respond to the ITR with a Map-Reply message when
it receives the data packet over the ALT. As a side-effect, the it receives the data packet over the ALT. As a side-effect, the
encapsulated data packet is delivered to the end-system at the ETR encapsulated data packet is delivered to the end-system at the ETR
site. Note that the Data Probe's inner IP destination address, site. Note that the Data Probe's inner IP destination address,
which is an EID, is copied to the outer IP destination address so which is an EID, is copied to the outer IP destination address so
that the resulting packet can be routed over the ALT. See that the resulting packet can be routed over the ALT. See
Section 3.3 for caveats on the usability of Data Probes. Section 3.3 for caveats on the usability of Data Probes.
The term "ALT Datagram" is short-hand for a Map-Request or Data Probe The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
to be sent into or forwarded on the ALT. Note that such packets use to be sent into or forwarded on the ALT. Note that such packets use
skipping to change at page 13, line 43 skipping to change at page 13, line 43
the entry's TTL has expired, or the ITR can otherwise find no the entry's TTL has expired, or the ITR can otherwise find no
reachable ETR. Note that a current mapping may exist that contains reachable ETR. Note that a current mapping may exist that contains
no reachable RLOCs; this is known as a Negative Cache Entry and it no reachable RLOCs; this is known as a Negative Cache Entry and it
indicates that packets destined to the EID-prefix are to be dropped. indicates that packets destined to the EID-prefix are to be dropped.
Full details on Map-Request/Map-Reply processing may be found in Full details on Map-Request/Map-Reply processing may be found in
[LISP]. [LISP].
Traffic routed on to the ALT consists solely of ALT Datagrams, i.e. Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
Map-Requests and Data Probes (if supported). Given the relatively Map-Requests and Data Probes (if supported). Given the relatively
low performance expected of a tuneled topology, ALT Routers (and Map low performance expected of a tunneled topology, ALT Routers (and Map
Resolvers) should aggressively rate-limit the ingress of ALT Resolvers) should aggressively rate-limit the ingress of ALT
Datagrams from ITRs and, if possible, should be configured to not Datagrams from ITRs and, if possible, should be configured to not
accept packets that are not ALT Datagrams. accept packets that are not ALT Datagrams.
4.2. EID Assignment - Hierarchy and Topology 4.2. EID Assignment - Hierarchy and Topology
EID-prefixes are expected to be allocated to a LISP site by Internet EID-prefixes are expected to be allocated to a LISP site by Internet
Registries. Where a site has multiple allocations which are aligned Registries. Where a site has multiple allocations which are aligned
on a power-of-2 block boundary, they should be aggregated into a on a power-of-2 block boundary, they should be aggregated into a
single EID-prefix for advertisement. The ALT network is built in a single EID-prefix for advertisement. The ALT network is built in a
skipping to change at page 16, line 13 skipping to change at page 16, line 13
addressing, can therefore be used for ALT tunnels. addressing, can therefore be used for ALT tunnels.
5. EID-prefix Propagation and Map-Request Forwarding 5. EID-prefix Propagation and Map-Request Forwarding
As described in Section 8.2, an ITR sends an ALT Datagram to a given As described in Section 8.2, an ITR sends an ALT Datagram to a given
EID-to-RLOC mapping. The ALT provides the infrastructure that allows EID-to-RLOC mapping. The ALT provides the infrastructure that allows
these requests to reach the authoritative ETR. these requests to reach the authoritative ETR.
Note that under normal circumstances Map-Replies are not sent over Note that under normal circumstances Map-Replies are not sent over
the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned
from the original Map-Request. There may be scenarios, perhaps to from the original Map-Request. See sections 6.1.2 and 6.2 of [LISP]
encourage caching of EID-to-RLOC mappings by ALT Routers, where Map- for more information on the use of the Map-Request ITR RLOC field.
Replies could be sent over the ALT or where a "first-hop" ALT router Keep in mind that the ITR RLOC field supports mulitple RLOCs in
might modify the originating RLOC on a Map-Request received from an multiple address families, so a Map-Reply sent in response to a Map-
ITR to force the Map-Reply to be returned to the "first-hop" ALT Request is not necessarily sent to back to the Map-Request RLOC
Router. These cases will not be supported by initial LISP+ALT source.
implementations but may be subject to future experimentation.
There may be scenarios, perhaps to 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 might modify the originating RLOC
on a Map-Request received from an ITR to force the Map-Reply to be
returned to the "first-hop" ALT Router. These cases will not be
supported by initial LISP+ALT implementations but may be subject to
future experimentation.
ALT Routers propagate path information via BGP ([RFC4271]) that is ALT Routers propagate path information via BGP ([RFC4271]) that is
used by ITRs to send ALT Datagrams toward the appropriate ETR for used by ITRs to send ALT Datagrams toward the appropriate ETR for
each EID-prefix. BGP is run on the inter-ALT Router links, and each EID-prefix. BGP is run on the inter-ALT Router links, and
possibly between an edge ("last hop") ALT Router and an ETR or possibly between an edge ("last hop") ALT Router and an ETR or
between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB
consists of aggregated EID-prefixes and their next hops toward the consists of aggregated EID-prefixes and their next hops toward the
authoritative ETR for that EID-prefix. authoritative ETR for that EID-prefix.
5.1. Changes to ITR behavior with LISP+ALT 5.1. Changes to ITR behavior with LISP+ALT
skipping to change at page 18, line 16 skipping to change at page 18, line 16
6.1. Autonomous System Numbers (ASNs) in LISP+ALT 6.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 overlay network LISP+ALT specifies the use of BGP to create a global overlay network
(the ALT) for finding EID-to-RLOC mappings. While related to the (the ALT) for finding EID-to-RLOC mappings. While related to the
global routing database, the ALT serves a very different purpose and global routing database, the ALT serves a very different purpose and
is organized into a very different hierarchy. Because LISP+ALT does is organized into a very different hierarchy. Because LISP+ALT does
use BGP, however, it uses ASNs in the paths that are propagated among use BGP, however, it uses ASNs in the paths that are propagated among
ALT Routers. To avoid confusion, it needs to be stressed that that ALT Routers. To avoid confusion, LISP+ALT should use newly-assigned
these LISP+ALT ASNs use a new numbering space that is unrelated to AS numbers that are unrelated to the ASNs used by the global routing
the ASNs used by the global routing system. Exactly how this new system. Exactly how this new space will be assigned and managed will
space will be assigned and managed will be determined during the be determined during the deployment of LISP+ALT.
deployment of LISP+ALT.
Note that the ALT Routers that make up the "core" of the ALT will not Note that the ALT Routers that make up the "core" of the ALT will not
be associated with any existing core-Internet ASN because the ALT be associated with any existing core-Internet ASN because the ALT
topology is completely separate from, and independent of, the global topology is completely separate from, and independent of, the global
Internet routing system. Internet routing system.
6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT
As defined by this document, LISP+ALT may be implemented using BGP As defined by this document, LISP+ALT may be implemented using BGP
without modification. Given the fundamental operational difference without modification. Given the fundamental operational difference
skipping to change at page 28, line 11 skipping to change at page 28, line 11
to provide invaluable insight as the LISP effort has evolved. Others to provide invaluable insight as the LISP effort has evolved. Others
who have provided valuable contributions include John Zwiebel, Hannu who have provided valuable contributions include John Zwiebel, Hannu
Flinck, Amit Jain, John Scudder, and Scott Brim. Flinck, Amit Jain, John Scudder, and Scott Brim.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-14.txt (work in progress), June 2011. draft-ietf-lisp-15.txt (work in progress), July 2011.
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-09.txt (work in progress), May 2011. draft-ietf-lisp-ms-11.txt (work in progress), August 2011.
[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,
March 2000. March 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
 End of changes. 12 change blocks. 
28 lines changed or deleted 60 lines changed or added

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