One document matched: draft-portoles-lisp-eid-mobility-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-portoles-lisp-eid-mobility"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Unified L2 and L3 overlays">LISP L2/L3 EID Mobility Using a
Unified Control Plane</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Marc Portoles Comeras" initials="M." surname="Portoles">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>mportole@cisco.com</email>
</address>
</author>
<author fullname="Vrushali Ashtaputre" initials="V." surname="Ashtaputre">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>vrushali@cisco.com</email>
</address>
</author>
<author fullname="Victor Moreno" initials="V." surname="Moreno">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>vimoreno@cisco.com</email>
</address>
</author>
<author fullname="Fabio Maino" initials="F." surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>lispers.net</organization>
<address>
<postal>
<street></street>
<code></code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>LISP; L2 Overlay, L3 Overlay</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The LISP control plane offers the flexibility to support multiple
overlay flavors simultaneously. This document specifies how LISP can be
used to provide control-plane support to deploy a unified L2 and L3
overlay solution, as well as analyzing possible deployment options and
models.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document describes the architecture and design options required
to offer a unified L2 and L3 overlay solution with the LISP
control-plane.</t>
<t>The architecture takes advantage of the flexibility that LISP
provides to simultaneously support different overlay flavors. In this
sense, while the LISP specification defines both data-plane and
control-plane solutions, this document focuses on the use of the
control-plane piece, which can be combined with the data-plane of choice
(e.g., [VXLAN-GPE], [VXLAN], or [LISP].</t>
<t>The recommended selection of whether a flow is sent over the L2 or
the L3 overlay is mapped to bridged (intra-subnet or non-IP) or routed
(inter-subnet) traffic, respectively. This allows treating both overlays
as separate segments, and enables L2-only and L3-only deployments (and
combinations of them) without modifying the architecture.</t>
<t>The unified solution for L2 and L3 overlays offers the possibility to
extend subnets and routing domains (as required in state-of-art
Datacenter and Enterprise architectures) with traffic optimization.</t>
<t>An important use-case of the unified architecture is that, while most
data centers are complete layer-3 routing domains, legacy applications
either have not converted to IP or still use auto-discovery at layer-2
and assume all nodes in an application cluster belong to the same
subnet. For these applications, the L2-overlay limits the functionality
to where the legacy app lives versus having to extend layer-2 into the
network.</t>
<t>Broadcast, Unknown and Multicast traffic on the overlay are supported
by either replicated unicast, or underlay (RLOC) multicast as specified
in <xref target="RFC6831"></xref>, <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref>.</t>
</section>
<section title="Definition of Terms">
<t>LISP related terms are defined as part of the LISP specification
<xref target="RFC6830"></xref>, notably EID, RLOC, Map-Request, Map-
Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router
(ETR), Map- Server (MS) and Map-Resolver (MR).</t>
</section>
<section title="Reference System and Packet Flows">
<t>This section introduces a reference system to support the description
of the solution and it walks the supported packet flows.</t>
<section title="Reference System">
<t>The following figure illustrates the reference system used to
support the packet flow description. The system presents 4 sites. Site
A and Site D provide access to different subnets (non-extended), while
Site B and Site C extend a common subnet. The xTR in each one of the
sites registers EIDs from the sites with the LISP Mapping System and
provides support to encapsulate overlay (EID) traffic through the
underlay (RLOC space).</t>
<figure anchor="figure_reference"
title="Reference System Architecture with unified L2 and L3 overlays">
<artwork><![CDATA[
,-------------.
(Mapping System )
-+------------+
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
.-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
.-.' '.-.
( L3 Underlay )
( (RLOC Space) )
'.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4
MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3
]]></artwork>
</figure>
</section>
<section title="Packet Flows">
<t>The recommended selection between the use of L2 and L3 overlays is
to map them to bridged (intra-subnet or non-IP) and routed
(inter-subnet) traffic. This section follows this recommendation to
describe the packet flows.</t>
<t>However, note that in a different selection approach, intra-subnet
traffic MAY also be sent over the L3 overlay. <xref
target="EF"></xref> specifies the changes needed to send all IP
traffic using the L3 overlay and restricting the use of the L2 overlay
to non-IP traffic.</t>
<t>When required, the control plane makes use of two basic types of
EID-to-RLOC mappings associated to end-hosts and in order to support
the unified architecture: <list style="symbols">
<t>EID = <IID, MAC> to RLOC=<IP>. This is used to
support the L2 overlay.</t>
<t>EID = <IID, IP> to RLOC=<IP>. This is the
traditional mapping as defined in the original LISP specification
and supports the L3 overlay.</t>
</list></t>
<!--</section>-->
<section anchor="intra"
title="Bridged Traffic: Intra-subnet and Non-IP">
<t>Bridged traffic is encapsulated using the L2 overlay. This
section provides an example of the unicast packet flow and the
control plane operations when in the topology shown in Figure 1, the
End-Device 2 in site B communicates with the End-Device 3 in site C.
In this case we assume that End Device 2, knows the MAC address of
End-Device 3 (e.g., learned through ARP). <list style="symbols">
<t>End-Device 2 sends an Ethernet/IEEE 802 MAC frame with
destination 0:0:3:0:0:3 and source 0:0:3:0:0:2.</t>
<t>ITR B does a L2 lookup in its local map-cache for the
destination MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a
miss, the ITR sends a Map-Request to the mapping database system
looking up for MAC 0:0:3:0:0:3.</t>
<t>The mapping systems forwards the Map-Request to ETR C, that
has registered the EID-to-RLOC mapping for MAC 0:0:3:0:0:3.
Alternatively, depending on the mapping system configuration, a
Map-Server which is part of the mapping database system MAY send
a Map-Reply directly to ITR B.</t>
<t>ETR C sends a Map-Reply to ITR B that includes the
EID-to-RLOC mapping: MAC 0:0:3:0:0:3 -> RLOC=IP_C, where IP_C
is the locator of ETR C.</t>
<t>ITR B populates the local map-cache with the EID to RLOC
mapping, and encapsulates all subsequent packets with a
destination MAC 0:0:3:0:0:3 using destination RLOC=IP_C.</t>
</list></t>
</section>
<section anchor="inter" title="Routed Traffic: Inter-subnet">
<t>Inter-subnet traffic is encapsulated using the L3 overlay. The
process to encapsulate this traffic is the same as described in the
original specification <xref target="RFC6830"></xref>. We describe
the packet flow here for completeness</t>
<t>The following is a sequence example of the unicast packet flow
and the control plane operations when in the topology shown in
Figure 1 End-Device 1, in LISP site A, wants to communicate with
End-Device 4 in LISP site D. Note that both end systems reside in
different subnets. We'll assume that End-Device 1 knows the EID IP
address of End-Device 4 (e.g. it is learned using a DNS service).
<list style="symbols">
<t>End-Device 1 sends an IP packet frame with destination
2.0.0.4 and source 1.0.0.1. As the destination address lies on a
different subnet End-Device 1 sends the packet following its
routing table to ITR A (e.g., it is its default gateway).</t>
<t>ITR A does a L3 lookup in its local map-cache for the
destination IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss,
the ITR sends a Map-request to the mapping database system
looking up for IP 2.0.0.4.</t>
<t>The mapping systems forwards the Map-Request to ETR D, that
has registered the EID-to-RLOC mapping of IP 2.0.0.4.</t>
<t>ETR D sends a Map-Reply to ITR A that includes the
EID-to-RLOC mapping: EID IP 2.0.0.4 -> RLOC=IP_D, where IP_D
is the locator of ETR D.</t>
<t>ITR A populates the local map-cache with the EID to RLOC
mapping, and encapsulates all subsequent packets with a
destination IP 2.0.0.4 using destination RLOC=IP_D.</t>
</list></t>
</section>
<section anchor="arp_flow" title="ARP Resolution">
<t>A large majority of applications are IP based and, as a
consequence, end systems are typically provisioned with IP addresses
as well as MAC addresses.</t>
<t>In this case, to limit the flooding of ARP traffic and reduce the
use of multicast in the RLOC network, the LISP mapping system is
used to support ARP resolution at the ITR.</t>
<t>In order to provide this support, ETRs handle and register an
additional EID-to-RLOC mapping as follows, <list style="symbols">
<t>EID = <IID, IP> to RLOC = <MAC>.</t>
</list></t>
<t>The following packet flow sequence describes the use of the LISP
Mapping System to support ARP resolution for hosts residing in a
subnet that is extended to multiple sites. Using Figure 1,
End-Device 2 tries to find the MAC address of End-Device 3. Note
that both have IP addresses within the same subnet: <list
style="symbols">
<t>End-Device 2 sends a broadcast ARP message to discover the
MAC address of End-Device 3. The ARP request targets IP
3.0.0.3.</t>
<t>ITR B receives the ARP message, but rather than flooding it
on the overlay network sends a Map-Request to the mapping
database system for IP 3.0.0.3.</t>
<t>When receiving the Map-Request, the Map-Server sends a
Proxy-Map-Reply back to ITR B with the mapping IP 3.0.0.3 ->
MAC 0:0:3:0:0:3.</t>
<t>Using this Map-Reply, ITR B sends an ARP-Reply back to
End-Device 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3.</t>
<t>End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and
can now send a L2 traffic to End-Device 3. When this traffic
reaches ITR B is sent over the L2-overlay as described above in
<xref target="intra"></xref>.</t>
</list></t>
<t>This example shows how LISP, by replacing dynamic data plane
learning (such as Flood-and-Learn) can reduce the use of multicast
in the underlay network.</t>
<t>Note that ARP resolution using the Mapping System is a stateful
operation on the ITR. The source IP,MAC tuple coming from the ARP
request have to be stored to generate the ARP-reply when the
Map-Reply is received.</t>
<t>Note that the ITR SHOULD cache the ARP entry. In that case future
ARP-requests can be handled without sending additional
Map-Requests.</t>
</section>
</section>
</section>
<section anchor="CP" title="LISP Protocol with L2 and L3 Support">
<t>This section describes the specific elements required to support a
unified L2 and L3 overlay solution and the packet flows described in the
previous section.</t>
<section title="L2 and L3 Segmentation">
<t>LISP support of segmentation and multi-tenancy is structured around
the propagation and use of Instance-IDs, and handled as part of the
EID in control plane operations. The encoding is described in <xref
target="I-D.ietf-lisp-lcaf"></xref> and its use in <xref
target="I-D.ietf-lisp-ddt"></xref>.</t>
<t>Depending on the particular deployment, both the L2 and L3 overlays
can be segmented. An Instance-ID can be used for L2 overlay
segmentation (e.g., VLAN extension) and for L3 overlay segments (e.g.,
VRF extension or multi-VPN overlays). In all cases, the Instance-ID is
a 24-bit value. Instance-IDs are unique to a Mapping System and MAY be
used to identify the overlay type.</t>
<t>An important aspect of L2 overlay segmentation is the mapping of
VLANs to IIDs. In this case a Bridge Domain (which is the L2
equivalent to a VRF as a forwarding context) maps to an IID, a VLAN-ID
may map 1:1 to a bridge domain or different VLAN-IDs on different
ports may map to a common Bridge Domain, which in turn maps to an IID
in the L2 overlay. When ethernet traffic is double tagged, usually the
external 802.1Q tag will be mapped to a bridge domain on a per port
basis, and the inner 802.1Q tag will remain part of the payload to be
handled by the overlay. The IID should therefore be able to carry
ethernet traffic with or without an 802.1Q header. A port may also be
configured as a trunk and we may chose to take the encapsulated
traffic and map it to a single IID in order to multiplex traffic from
multiple VLANs on a single IID. These are all examples of local
operations that could be effected on VLANs in order to map them to
IIDs, they are provided as examples and are not exhaustive.</t>
</section>
<section anchor="dbmaps"
title="Database Mappings in Unified L2 and L3 Overlays">
<t>When an end-host is attached or detected in an ETR that provides
L2-overlay and L3-overlay services, two Database Mapping entries are
registered to the mapping system: <list style="symbols">
<t>The EID 2-tuple (IID, IP) with its binding to a corresponding
ETR locator set (IP RLOC)</t>
<t>The EID 2-tuple (IID, MAC) with its binding to a locator set
(IP RLOC)</t>
</list></t>
<t>These two database mappings are the ones required to support L3 and
L2 forwarding.</t>
<t>The registration of these EIDs MUST follow the LCAF format as
defined in <xref target="I-D.ietf-lisp-lcaf"></xref>.</t>
</section>
<section title="MAC as a Locator Record for ARP Resolution">
<t>When an end-host is attached or detected in an ETR that provides
L2-overlay services and supports ARP resolution using the LISP
control-plane, an additional mapping entry is registered to the
mapping system: <list style="symbols">
<t>The EID 2-tuple (IID, IP) and its binding to a corresponding
host MAC address.</t>
</list></t>
<t>In this case both the xTRs and the Mapping System MUST support an
EID-to-RLOC mapping where the MAC address is set as a locator
record.</t>
<t>This mapping is registered with the Mapping System using the
following EID record structure,</t>
<figure>
<artwork><![CDATA[
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | 4 + n | Instance-ID... |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | ...Instance-ID | EID-AFI = 1 or 2 |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-Prefix (IPv4 or IPv6) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | Unused Flags |L|p|R| AFI = 16387 |
| A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C | Rsvd1 | Flags | Type = 1 | Rsvd2 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 2 + 6 | AFI = 6 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Layer-2 MAC Address ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Layer-2 MAC Address |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
]]></artwork>
</figure>
<t>An EID record with a locator record that carries a MAC address
follows the same structure as described in <xref
target="RFC6830"></xref>. However, some fields of the EID record and
the locator record require special consideration: <list
style="hanging">
<t hangText="Locator Count:">This value SHOULD be set to 1.</t>
<t hangText="Instance-ID:">This is the IID used to provide
L2-overlay segmentation.</t>
<t hangText="Priority and Weight:">IP to MAC bindings are one to
one bindings. An ETR SHOULD not register more than one MAC address
in the locator record together with an IP based EID. The Priority
of the MAC address record is set to 255. The Weight value SHOULD
be ignored and the recommendation is to set it to 0.</t>
<t hangText="L bit:">This bit of the locator record SHOULD only be
set to 1 when an ETR is registering its own IP to MAC binding.</t>
<t hangText="p bit:">This bit of the locator record SHOULD be set
to 0.</t>
<t hangText="R bit:">This bit of the locator record SHOULD be set
to 0.</t>
</list></t>
<t>Note that an IP EID record that carries a MAC address in the
locator record, SHOULD be registered with the Proxy Map-Reply bit
set.</t>
</section>
<section title="LISP Mapping System">
<t>The interface between the xTRs and the Mapping System is described
in <xref target="RFC6833"></xref> and this document follows the
specification as described there. When available, the registrations
MAY be implemented over a reliable transport as described in <xref
target="I-D.kouvelas-lisp-map-server-reliable-transport"></xref>.</t>
</section>
<section title="Time-to-Live Handling in Data-Plane">
<t>The LISP specification (<xref target="RFC6830"></xref>) describes
how to handle Time-to-Live values of the inner and outer headers
during encapsulation and decapsulation of packets when using the L3
overlay. The same approach SHOULD be followed for the unified
overlay.</t>
<t>When using the L2 overlay and the encapsulated traffic is IP
traffic, the Time-to-Live value of the inner IP header MUST remain
unmodified at encapsulation and decapsulation. Network hops traversed
as part of the L2 overlay SHOULD be hidden to tools like traceroute
and applications that require direct L2 connectivity.</t>
</section>
<section title="Using SMRs to Track Moved-Away State">
<t>One of the key elements to support end-host mobility using the LISP
architecture is the Solicit-Map-Request (SMR). This is an special
message by means of which an ETR can request an ITR to send a new
Map-Request for a particular EID record. In essence the SMR message is
used as a signal to indicate a change in mapping information and it is
described with detail in <xref target="RFC6830"></xref>. <xref
target="Mobility"></xref> provides a packet flow description of the
mobility support in a unified overlay.</t>
<t>In order to support mobility, an ETR SHALL maintain a list of EID
records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination. This is called an Away
Table.</t>
<t>The particular strategy to maintain an Away Table is implementation
specific and it will be typically based on the strategy to detect the
presence of hosts and the use of the Map-Notifies received from the
Map-Server. In essence the table SHOULD provide support to the
following: <list style="symbols">
<t>Keep track of end-hosts that were once connected to an ETR and
have moved away.</t>
<t>Support for L2 EID records, the 2-tuple (IID, MAC), for which a
SMR message SHOULD be generated.</t>
<t>Support for L3 EID records, the 2-tuple (IID, IP), for which a
SMR message SHOULD be generated.</t>
</list></t>
</section>
<section title="Non-Extended Subnets">
<t>The registration and access to non-extended subnets using the L3
overlay follows <xref target="RFC6830"></xref>.</t>
<t>Note also that non-extended subnets can also be treated as non-LISP
networks. In that case, providing access to the subnet to participants
of LISP overlays requires the use of a PxTR, following the
specification in <xref target="RFC6830"></xref>.</t>
</section>
<section anchor="l2_groups" title="L2 Overlays and Multicast Groups">
<t>xTRs that offer L2 overlay services and are part of the same
Instance-ID join a common Multicast Group. When required, this group
allows ITRs to send traffic that needs to be replicated (flooded) to
all ETRs participating in the L2-overlay (e.g., broadcast traffic
within a subnet). When the core network (RLOC space) supports native
multicast ETRs participating in the L2-overlay join a (*,G) group
associated to the Instance-ID.</t>
<t>When multicast is not available in the core network, each xTR that
is part of the same instance-ID SHOULD join a (S,G) entry to the
mapping system using the procedures described in <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref>, where S is
0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows and
ITR to know which ETRs are part of the L2 overlay and it can head-end
replicate traffic to.</t>
</section>
<section anchor="BUM"
title="L2 Broadcast, Unknown Unicast and Multicast traffic">
<t>Broadcast, Unknown Unicast and Multicast (BUM) traffic on the
L2-overlay is supported by either replicated unicast, or underlay
(RLOC) multicast.</t>
</section>
</section>
<!--<section anchor="l2_mh" title="xTR Multihoming in L2-overlays">
</section>-->
<section anchor="Mobility" title="EID Mobility Support">
<t>Support to end-host mobility is a basic requirement of state-of-art
overlay solutions. The unified overlay architecture described here
supports mobility both over L2-overlays and L3-overlays. This section
provides a packet flow sequence description of the mobility support,
detailing the use of the elements defined in the previous section.</t>
<section title="Reference Architecture">
<t>In order to support the packet flow description we use again the
same example as in <xref target="figure_reference"></xref>. In this
particular case hosts may roam and we distinguish the case when we
have L2-mobility (e.g., IP hosts move within their own subnet) or
L3-mobility.</t>
<figure anchor="figure_mobility"
title="Reference Mobility Architecture">
<preamble></preamble>
<artwork><![CDATA[
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
' ) ' )
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="L2 Mobility: Packet Flow">
<t>The support to L2 mobility covers the requirements to allow an
end-host to move from a given site to another and maintain
correspondence with the rest of end-hosts that are connected to the
same L2 domain (e.g. extended VLAN). This support MUST ensure
convergence of L2 forwarding (MAC based) from the old location to the
new one, when the host completes its move.</t>
<t>The following is a sequence description of the packet flow when
End-Device 2 in the figure moves to Site C, which is extending its own
subnet network. <list style="symbols">
<t>When End-Device 2 is attached or detected in site C, ETR C sets
up the database mapping corresponding to EID=<IID2,
0:0:3:0:0:2>. ETR C sends a Map-Register to the mapping system
registering RLOC=IP_B as locator for EID=<IID2,
0:0:3:0:0:2>.</t>
<t>The Mapping System, after receiving the new registration for
EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the
new locator set (IP_B). ETR B removes then its local database
mapping and stops registering <IID2, 0:0:3:0:0:2>.</t>
<t>Any PiTR or ITR participating in the same L2-overlay
(corresponding to IID2) that was encapsulating traffic to
0:0:3:0:0:2 before the migration continues encapsulating this
traffic to ETR B.</t>
<t>Once ETR B is notified by the Mapping system, when it receives
traffic from an ITR which is destined to 0:0:3:0:0:2, it will
generate a Solicit-Map-Request (SMR) message that is sent to the
ITR for (IID2,0:0:3:0:0:2).</t>
<t>Upon receiving the SMR the ITR sends a new Map-Request for the
EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a
Map-Reply that includes the new EID-to-RLOC mapping for
<IID2,0:0:3:0:0:2> with RLOC=IP_B. This entry is cached in
the L2 table of the ITR, replacing the previous one, and traffic
is then forwarded to the new location.</t>
</list></t>
<t></t>
</section>
<section title="L3 Mobility: Packet Flow">
<t>The support to L3 mobility covers the requirements to allow an
end-host to move from a given site to another and maintain
correspondence with the rest of end-hosts that are connected to the
same L3 routing domain. This support MUST ensure convergence of L3
forwarding (IPv4/IPv6 based) from the old location to the new one when
the host completes its move.</t>
<t>The following is a sequence description of the packet flow when
End-Device 1 in the reference figure roams to site D: <list
style="symbols">
<t>When End-Device 1 is attached or detected in site D, ETR D sets
up the database mapping corresponding to EID=<IID1,
1.0.0.1>. ETR D sends a Map-Register to the mapping system
registering RLOC=IP_D as locator for EID=<IID1, 1.0.0.1>.
Now the mapping system is updated with the new EID-to-RLOC mapping
(location) for End-Device 1.</t>
<t>The Mapping System, after receiving the new registration for
EID=<IID1, 1.0.0.1> sends a Map-Notify to ETR A to inform it
of the move. Then, ETR A removes its local database mapping
information and stop registering EID=<IID1, 1.0.0.1>.</t>
<t>Any ITR or PiTR participating in the L3 overlay (corresponding
to IID1) that were sending traffic to 1.0.0.1 before the migration
keep sending traffic to ETR A.</t>
<t>Once ETR A is notified by the Mapping system, when it receives
traffic from an ITR with destination 1.0.0.1, it generates a
Solicit-Map-Request (SMR) back the ITR (or PiTR) for EID=<IID1,
1.0.0.1>.</t>
<t>Upon receiving the SMR the ITR invalidates its local map- cache
entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request
for that EID. The Map-Reply includes the new EID-to-RLOC mapping
for End-Device 1 with RLOC=IP_D.</t>
<t>Similarly, once the local database mapping is removed from ITR
A, non-encapsulated packets arriving at ITR A from a local
End-Device and destined to End-Device 1 result in a cache miss,
which triggers sending a Map-Request for EID=<IID1, 1.0.0.1>
to populate the map-cache of ITR A.</t>
</list></t>
</section>
</section>
<section anchor="Special" title="Optional Deployment Models">
<t>The support of an integrated L2 and L3 overlay solution takes
multiple architectural design options, that depend on the specific
requirements of the deployment environment. While some of the previous
describe specific packet flows and solutions based on the recommended
solution, this section documents OPTIONAL design considerations that
differ from the recommended one but that MAY be required on alternative
deployment environments.</t>
<section anchor="EF" title="IP Forwarding of Intra-subnet Traffic">
<t>As pointed out at the beginning the recommended selection of the L2
and L3 overlays is not the only one possible. In fact, providing L2
extension to some cloud platforms is not always possible and subnets
need to be extended using the L3 overlay.</t>
<t>In order to send all IP traffic (intra- and inter-subnet) through
the L3 overlay the solution MUST change the ARP resolution process
described in <xref target="arp_flow"></xref> to the following one (we
follow again <xref target="figure_reference"></xref> to drive the
example. End-Device 2 queries about End-Device 3): <list
style="symbols">
<t>End-Device 1 sends a broadcast ARP message to discover the MAC
address of 3.0.0.3.</t>
<t>ITR B receives the ARP message and sends a Map-Request to the
Mapping System for 3.0.0.3.</t>
<t>In this case, the Map-Request is routed by the Mapping system
infrastructure to ETR C, that will send a Map-Reply back to ITR B
containing the mapping 3.0.0.3 -> RLOC=IP_C.</t>
<t>ITR B populates its local cache with the received entry on the
L3 forwarding table. Then, using the cache information it sends a
Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end
End-Device 1.</t>
<t>End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and
sends traffic with destination address 3.0.0.3 and destination
MAC, MAC_xTR_B.</t>
<t>As the destination MAC address is the one from xTR B, when xTR
B receives this traffic is it forwarded using the L3-overlay.</t>
<t>Note that when implementing this solution, when a host that is
local to an ETR moves away, the ETR SHOULD locally send a
Gratuitous ARP with its own MAC address and the IP of the moved
host, to refresh the ARP tables of local hosts and guarantee the
use of the L3 overlay when connecting to the remote host.</t>
</list></t>
<t>It is also important to note that using this strategy to extend
subnets through the L3 overlay but still keeping the L2 overlay for
the rest of traffic MAY lead to flow asymmetries. This MAY be the case
in deployments that filter Gratuitous ARPs, or when moved hosts
continue using actual L2 information collected before a migration.</t>
<!--</section>-->
<!--<section title="Time-to-Live considerations in data-plane">
<t> When intra-subnet traffic is forwarded using the L3 overlay, TTL handling
of the inner-header is handled, by default, as specified in <xref target="RFC6830"/>.
</t>
<t> However, applications running on stretched subnets MAY require that end-hosts have
direct L2 connectivity. In order to support that, and when the forwarding architecture
allows it, intra-subnet traffic MAY be forwarded with no decrement of the inner IP TTL header.
</t>
</section>-->
</section>
<section title="Data-plane Encapsulation Options">
<t>The LISP control-plane offers independence from the data-plane
encapsulation. Any encapsulation format that can carry a 24-bit
instance-ID can be used to provide the unified overlay.</t>
<t>Common encapsulation formats that can be used are [VXLAN-GPE],
[LISP] and [VXLAN]: <list style="symbols">
<t>VXLAN-GPE encap: This encapsulation format is defined in <xref
target="I-D.ietf-nvo3-vxlan-gpe"></xref>. It allows encapsulation
both L2 and L3 packets and the VNI field directly maps to the
Instance-ID used in the control plane. Note that when using this
encapsulation for a unified solution the P-bit is set and the
Next-Protocol field is used (typically with values 0x1 (IPv4) or
0x2 (IPv6) in L3-overlays, and value 0x3 in L2-overlays).</t>
<t>LISP encap: This is the encapsulation format defined in the
original LISP specification <xref target="RFC6830"></xref>. The
encapsulation allows encapsulating both L2 and L3 packets. The
Instance-ID used in the EIDs directly maps to the Instance-ID that
the LISP header carries. At the ETR, after decapsulation, the IID
MAY be used to decide between L2 processing or L3 processing.</t>
<t>VXLAN encap: This is a L2 encapsulation format defined in <xref
target="RFC7348"></xref>. While being a L2 encapsulation it can be
used both for L2 and L3 overlays. The Instance-ID used in LISP
signaling maps to the VNI field of the VXLAN header. Providing L3
overlays using VXLAN generally requires using the ETR MAC address
as destination MAC address of the inner Ethernet header. The
process to learn or derive this ETR MAC address is not included as
part of this document.</t>
</list></t>
</section>
<section title="L2-only Deployments">
<t>The Unified architecture that this document specifies allows the
deployment of L3-only or L2-only overlays. By having a single control
plane where the mapping database can hold both MAC EIDs and IP EIDs,
the deployment of L2-only or L3-only architectures consists in using
only the relevant database mappings.</t>
<t>The requirements and use of LISP to support a L3-only overlay are
extensively documented in the original LISP specification and related
documents.</t>
<t>The provision of a L2-only overlay MUST provide support for
intra-subnet connectivity of end-hosts belonging to the same tenant,
including them in a unique L2 broadcast domain extended across the
network.</t>
<t>Provision such L2-only overlay SHALL take the following aspects
into account, as described before in <xref target="CP"></xref>: <list
style="symbols">
<t>When an end-host is attached the ETR maintains and registers
the mappings EID = <IID, MAC> -> RLOC = <IP> and
EID = <IID, IP> -> RLOC = <MAC>. The second mapping
is optional and is meant to be used for ARP resolution.</t>
<t>An ITR and Mapping-System provides support for ARP lookup and
MAC lookup using the lisp control-plane as described before in
this document.</t>
<t>xTRs MUST provide support for Broadcast, Unknown and Multicast
(BUM) traffic through either replicated unicast or underlay (RLOC)
multicast.</t>
<t>An ITR MUST treat a destination MAC for which it receives a
Negative Map-Reply with Native Forward action as BUM traffic and
replicate it to the ETRs in the Layer-2 overlay.</t>
<t>To support end-host mobility, an ETR MUST be able to support an
Away Table (as described above) to keep track of end-hosts and
generate SMR messages when receiving traffic for end-hosts not
locally attached.</t>
<t>TTL value of the inner-IP header SHOULD not be modified when
traversing the L2 overlay.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This draft builds on top of two expired drafts that introduced the
concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and
draft-hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the
combined authors of those drafts, that SHOULD be considered main
contributors of this draft as well: Vina Ermagan, Dino Farinacci, Yves
Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael
Smith.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6833.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6831.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7348.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kouvelas-lisp-map-server-reliable-transport-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-lcaf-11.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-signal-free-multicast-00.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-vxlan-gpe-01.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-ddt-04.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:21:47 |