draft-ietf-lisp-alt-08.txt   draft-ietf-lisp-alt-09.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: March 11, 2012 D. Lewis Expires: March 23, 2012 D. Lewis
Cisco Cisco
September 8, 2011 September 20, 2011
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-08.txt draft-ietf-lisp-alt-09.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 March 11, 2012. This Internet-Draft will expire on March 23, 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 23 skipping to change at page 3, line 23
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 . . . . . . . . . . 17 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17
6. BGP configuration and protocol considerations . . . . . . . . 18 5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18 6. BGP configuration and protocol considerations . . . . . . . . 19
6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19
7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19
7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20
7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20
7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 20
7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 21
8. Connecting sites to the ALT network . . . . . . . . . . . . . 22 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 21
8.1. ETRs originating information into the ALT . . . . . . . . 22 8. Connecting sites to the ALT network . . . . . . . . . . . . . 23
8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22 8.1. ETRs originating information into the ALT . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 26
10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document describes the LISP+ALT system, used by a [LISP] ITR or This document describes the LISP+ALT system, used by a [LISP] ITR or
MR to find the ETR that holds the RLOC mapping information for a MR to find the ETR that holds the RLOC mapping information for a
particular EID. The ALT network is built using the Border Gateway particular EID. The ALT network is built using the Border Gateway
Protocol (BGP, [RFC4271]), the BGP multi-protocol extension Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
[RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to [RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
construct an overlay network of devices (ALT Routers) which operate construct an overlay network of devices (ALT Routers) which operate
on EID-prefixes and use EIDs as forwarding destinations. on EID-prefixes and use EIDs as forwarding destinations.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
In summary, LISP+ALT uses BGP to build paths through ALT Routers so In summary, LISP+ALT uses BGP to build paths through ALT Routers so
that an ALT Datagram sent into the ALT can be forwarded to the ETR that an ALT Datagram sent into the ALT can be forwarded to the ETR
that holds the EID-to-RLOC mapping for that EID-prefix. This that holds the EID-to-RLOC mapping for that EID-prefix. This
reachability is carried as IPv4 or ipv6 NLRI without modification reachability is carried as IPv4 or ipv6 NLRI without modification
(since an EID-prefix has the same syntax as IPv4 or ipv6 address (since an EID-prefix has the same syntax as IPv4 or ipv6 address
prefix). ALT Routers establish BGP sessions with one another, prefix). ALT Routers establish BGP sessions with one another,
forming the ALT. An ALT Router at the "edge" of the topology learns forming the ALT. An ALT Router at the "edge" of the topology learns
EID-prefixes originated by authoritative ETRs. Learning may be EID-prefixes originated by authoritative ETRs. Learning may be
though the Map Server interface, by static configuration, or via BGP though the Map Server interface, by static configuration, or via BGP
with the ETRs. An ALT Router may also be configured to aggregate with the ETRs. An ALT Router may also be configured to aggregate
EID-prefixes received from ETRs or from other LISP+ALT routers that EID-prefixes received from ETRs or from other LISP+ALT Routers that
are topologically "downstream" from it. are topologically "downstream" from it.
4.1. ITR traffic handling 4.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 EID for that packet is not known in the ITR's and the destination EID for that packet is not known in the ITR's
mapping cache, the ITR creates either a Map-Request for the mapping cache, the ITR creates either a Map-Request for the
destination EID or the original packet encapsulated as a Data Probe destination EID or the original packet encapsulated as a Data Probe
(see Section 3.3 for caveats on the usability of Data Probes). The (see Section 3.3 for caveats on the usability of Data Probes). The
skipping to change at page 16, line 22 skipping to change at page 16, line 22
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. See sections 6.1.2 and 6.2 of [LISP] from the original Map-Request. See sections 6.1.2 and 6.2 of [LISP]
for more information on the use of the Map-Request ITR RLOC field. for more information on the use of the Map-Request ITR RLOC field.
Keep in mind that the ITR RLOC field supports mulitple RLOCs in Keep in mind that the ITR RLOC field supports mulitple RLOCs in
multiple address families, so a Map-Reply sent in response to a Map- multiple address families, so a Map-Reply sent in response to a Map-
Request is not necessarily sent to back to the Map-Request RLOC Request is not necessarily sent to back to the Map-Request RLOC
source. source.
There may be scenarios, perhaps to encourage caching of EID-to-RLOC 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 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 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 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 returned to the "first-hop" ALT Router. 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.
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
skipping to change at page 18, line 5 skipping to change at page 17, line 23
As documented in [LISP], when an ETR generates a Map-Reply message to As documented in [LISP], when an ETR generates a Map-Reply message to
return to a querying ITR, it sets the outer header IP destination return to a querying ITR, it sets the outer header IP destination
address to one of the requesting ITR's RLOCs so that the Map-Reply address to one of the requesting ITR's RLOCs so that the Map-Reply
will be sent on the underlying Internet topology, not on the ALT; will be sent on the underlying Internet topology, not on the ALT;
this avoids any latency penalty (or "stretch") that might be incurred this avoids any latency penalty (or "stretch") that might be incurred
by sending the Map-Reply via the ALT, reduces load on the ALT, and by sending the Map-Reply via the ALT, reduces load on the ALT, and
ensures that the Map-Reply can be routed even if the original ITR ensures that the Map-Reply can be routed even if the original ITR
does not have an ALT-routed EID. For details on how an ETR selects does not have an ALT-routed EID. For details on how an ETR selects
which ITR RLOC to use, see section 6.1.5 of [LISP]. which ITR RLOC to use, see section 6.1.5 of [LISP].
5.3. ALT Datagram forwarding falure
Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by-
hop routing on the ALT overlay network. Should an ALT router not be
able to forward an ALT Datagram, whether due to an unreachable next-
hop, TTL exceeded, or other problem, it has several choices:
o If the ALT Router understands the LISP protocol, as is the case
for a Map Resolver or Map Server, it may respond to a forwarding
failure by returning a negative Map-Reply, as described in
Section 4.2 and [LISP-MS].
o If the ALT Router does not understand LISP, it may attempt to
return an ICMP message to the source IP address of the packet that
cannot be forwarded. Since the source address is an RLOC, an ALT
Router would send this ICMP message using "native" Internet
connectivity, not via the ALT overlay.
o A non-LISP-capable ALT Router may also choose to silently drop the
non-forwardable ALT Datagram.
[LISP] and [LISP-MS] define how the source of an ALT Datagram should
handle each of these cases. The last case, where an ALT Datagram is
silently discarded, will generally result in several retransmissions
by the source, followed by treating the destination as unreachable
via LISP when no Map-Reply is received. If a problem on the ALT is
severe enough to prevent ALT Datagrams from being delivered to a
specific EID, this is probably the only sensible way to handle this
case.
Note that the use of GRE tunnels should prevent MTU problems from
ever occurring on the ALT; an ALT Datagram that exceeds an
intermediate MTU will be fragmented at that point and will be
reassembled by the target of the GRE tunnel.
6. BGP configuration and protocol considerations 6. BGP configuration and protocol considerations
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
skipping to change at page 27, line 12 skipping to change at page 28, line 12
deployed, LISP+ALT can readily use these mechanisms to provide deployed, LISP+ALT can readily use these mechanisms to provide
authentication of EID-prefix origination and EID-to-RLOC mappings. authentication of EID-prefix origination and EID-to-RLOC mappings.
11. Acknowledgments 11. Acknowledgments
The authors would like to specially thank J. Noel Chiappa who was a The authors would like to specially thank J. Noel Chiappa who was a
key contributer to the design of the LISP-CONS mapping database (many key contributer to the design of the LISP-CONS mapping database (many
ideas from which made their way into LISP+ALT) and who has continued ideas from which made their way into LISP+ALT) and who has continued
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, Scott Brim, and Jari Arkko.
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-15.txt (work in progress), July 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-11.txt (work in progress), August 2011. draft-ietf-lisp-ms-12.txt (work in progress),
September 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. 10 change blocks. 
29 lines changed or deleted 66 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/