draft-ietf-lisp-eid-mobility-01.txt   draft-ietf-lisp-eid-mobility-02.txt 
Network Working Group M. Portoles Network Working Group M. Portoles
Internet-Draft V. Ashtaputre Internet-Draft V. Ashtaputre
Intended status: Experimental V. Moreno Intended status: Experimental V. Moreno
Expires: May 19, 2018 F. Maino Expires: November 15, 2018 F. Maino
Cisco Systems Cisco Systems
D. Farinacci D. Farinacci
lispers.net lispers.net
November 15, 2017 May 14, 2018
LISP L2/L3 EID Mobility Using a Unified Control Plane LISP L2/L3 EID Mobility Using a Unified Control Plane
draft-ietf-lisp-eid-mobility-01 draft-ietf-lisp-eid-mobility-02
Abstract Abstract
The LISP control plane offers the flexibility to support multiple The LISP control plane offers the flexibility to support multiple
overlay flavors simultaneously. This document specifies how LISP can overlay flavors simultaneously. This document specifies how LISP can
be used to provide control-plane support to deploy a unified L2 and be used to provide control-plane support to deploy a unified L2 and
L3 overlay solution, as well as analyzing possible deployment options L3 overlay solution, as well as analyzing possible deployment options
and models. and models.
Requirements Language Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 19, 2018. This Internet-Draft will expire on November 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6
4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6
4.2. Implementation Considerations . . . . . . . . . . . . . . 7 4.2. Implementation Considerations . . . . . . . . . . . . . . 7
4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7
4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8
4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8
4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9
4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9
4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9
5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9
5.1. Reference Architecture and packet flows . . . . . . . . . 10 5.1. Reference Architecture and packet flows . . . . . . . . . 9
5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10
5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11
5.2. Implementation Considerations . . . . . . . . . . . . . . 12 5.2. Implementation Considerations . . . . . . . . . . . . . . 11
5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 12 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 11
5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12
5.2.3. Interface to the LISP Mapping System . . . . . . . . 13 5.2.3. Interface to the LISP Mapping System . . . . . . . . 13
5.2.4. SMR support to track L2 hosts that moved away . . . . 13 5.2.4. SMR support to track L2 hosts that moved away . . . . 13
5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14
5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14
5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15
5.3. Support to ARP resolution through Mapping System . . . . 15 5.3. Support to ARP resolution through Mapping System . . . . 15
5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15
5.3.2. ARP registrations: MAC as a locator record . . . . . 16 5.3.2. ARP registrations: MAC as a locator record . . . . . 16
5.3.3. Implementation Considerations . . . . . . . . . . . . 18 5.3.3. Implementation Considerations . . . . . . . . . . . . 18
skipping to change at page 3, line 49 skipping to change at page 3, line 49
An important use-case of the unified architecture is that, while most An important use-case of the unified architecture is that, while most
data centers are complete layer-3 routing domains, legacy data centers are complete layer-3 routing domains, legacy
applications either have not converted to IP or still use auto- applications either have not converted to IP or still use auto-
discovery at layer-2 and assume all nodes in an application cluster discovery at layer-2 and assume all nodes in an application cluster
belong to the same subnet. For these applications, the L2-overlay belong to the same subnet. For these applications, the L2-overlay
limits the functionality to where the legacy app lives versus having limits the functionality to where the legacy app lives versus having
to extend layer-2 into the network. to extend layer-2 into the network.
Broadcast, Unknown and Multicast traffic on the overlay are supported Broadcast, Unknown and Multicast traffic on the overlay are supported
by either replicated unicast, or underlay (RLOC) multicast as by either replicated unicast, or underlay (RLOC) multicast as
specified in [RFC6831] and [I-D.ietf-lisp-signal-free-multicast]. specified in [RFC6831] and [RFC8378].
2. Definition of Terms 2. Definition of Terms
LISP related terms are defined as part of the LISP specification LISP related terms are defined as part of the LISP specification
[RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify,
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server
(MS) and Map-Resolver (MR). (MS) and Map-Resolver (MR).
3. Reference System 3. Reference System
skipping to change at page 7, line 44 skipping to change at page 7, line 44
triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate
the map-cache of ITR A. the map-cache of ITR A.
4.2. Implementation Considerations 4.2. Implementation Considerations
4.2.1. L3 Segmentation 4.2.1. L3 Segmentation
LISP support of segmentation and multi-tenancy is structured around LISP support of segmentation and multi-tenancy is structured around
the propagation and use of Instance-IDs, and handled as part of the the propagation and use of Instance-IDs, and handled as part of the
EID in control plane operations. The encoding is described in EID in control plane operations. The encoding is described in
[I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. [RFC8060] and its use in [RFC8111].
Instance-IDs can be used to support L3 overlay segmentation, such as Instance-IDs can be used to support L3 overlay segmentation, such as
in extended VRFs or multi-VPN overlays. in extended VRFs or multi-VPN overlays.
4.2.2. L3 Database-Mappings 4.2.2. L3 Database-Mappings
When an end-host is attached or detected in an ETR that provides When an end-host is attached or detected in an ETR that provides
L3-overlay services and mobility, a database Mapping is registered to L3-overlay services and mobility, a database Mapping is registered to
the mapping system with the following structure: the mapping system with the following structure:
o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR
locator set (IP RLOC) locator set (IP RLOC)
The registration of these EIDs MUST follow the LCAF format as defined The registration of these EIDs MUST follow the LCAF format as defined
in [I-D.ietf-lisp-lcaf] and the specific EID record to be used is in [RFC8060] and the specific EID record to be used is illustrated in
illustrated in the following figure: the following figure:
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved | E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 | D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len | r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 37 skipping to change at page 9, line 37
have moved away. have moved away.
o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR
message SHOULD be generated. message SHOULD be generated.
4.2.5. L3 multicast support 4.2.5. L3 multicast support
L3 Multicast traffic on the overlay MAY be supported by either L3 Multicast traffic on the overlay MAY be supported by either
replicated unicast, or underlay (RLOC) multicast. Specific solutions replicated unicast, or underlay (RLOC) multicast. Specific solutions
to support L3 multicast over LISP controlled overlays are specified to support L3 multicast over LISP controlled overlays are specified
in in [RFC6831], [I-D.ietf-lisp-signal-free-multicast] and in in [RFC6831], [RFC8378] and [I-D.coras-lisp-re].
[I-D.coras-lisp-re].
4.2.6. Time-to-Live Handling in Data-Plane 4.2.6. Time-to-Live Handling in Data-Plane
The LISP specification ([RFC6830]) describes how to handle Time-to- The LISP specification ([RFC6830]) describes how to handle Time-to-
Live values of the inner and outer headers during encapsulation and Live values of the inner and outer headers during encapsulation and
decapsulation of packets when using the L3 overlay. decapsulation of packets when using the L3 overlay.
5. L2 Overlays and Mobility Support 5. L2 Overlays and Mobility Support
5.1. Reference Architecture and packet flows 5.1. Reference Architecture and packet flows
In order to support L2 packet flow descriptions in this section we In order to support L2 packet flow descriptions in this section we
use Figure 1 as reference. This section uses Sites B and C to use Figure 1 as reference. This section uses Sites B and C to
describe the flows. describe the flows.
/ | | \ / | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
skipping to change at page 12, line 12 skipping to change at page 11, line 52
replacing the previous one, and traffic is then forwarded to the replacing the previous one, and traffic is then forwarded to the
new location. new location.
5.2. Implementation Considerations 5.2. Implementation Considerations
5.2.1. L2 Segmentation 5.2.1. L2 Segmentation
As with L3 overlays, LISP support of L2 segmentation is structured As with L3 overlays, LISP support of L2 segmentation is structured
around the propagation and use of Instance-IDs, and handled as part around the propagation and use of Instance-IDs, and handled as part
of the EID in control plane operations. The encoding is described in of the EID in control plane operations. The encoding is described in
[I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. Instance- [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a
IDs are unique to a Mapping System and MAY be used to identify the Mapping System and MAY be used to identify the overlay type (e.g., L2
overlay type (e.g., L2 or L3 overlay). or L3 overlay).
An Instance-ID can be used for L2 overlay segmentation. An important An Instance-ID can be used for L2 overlay segmentation. An important
aspect of L2 segmentation is the mapping of VLANs to IIDs. In this aspect of L2 segmentation is the mapping of VLANs to IIDs. In this
case a Bridge Domain (which is the L2 equivalent to a VRF as a 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 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 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 Bridge Domain, which in turn maps to an IID in the L2 overlay. When
ethernet traffic is double tagged, usually the outer 802.1Q tag will ethernet traffic is double tagged, usually the outer 802.1Q tag will
be mapped to a bridge domain on a per port basis, and the inner 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 802.1Q tag will remain part of the payload to be handled by the
skipping to change at page 12, line 43 skipping to change at page 12, line 34
5.2.2. L2 Database-Mappings 5.2.2. L2 Database-Mappings
When an end-host is attached or detected in an ETR that provides When an end-host is attached or detected in an ETR that provides
L2-overlay services, a database Mapping is registered to the mapping L2-overlay services, a database Mapping is registered to the mapping
system with the following structure: system with the following structure:
o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP
RLOC) RLOC)
The registration of these EIDs MUST follow the LCAF format as defined The registration of these EIDs MUST follow the LCAF format as defined
in [I-D.ietf-lisp-lcaf] and as illustrated in the following figure: in [RFC8060] and as illustrated in the following figure:
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved | E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 | D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len | r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 30 skipping to change at page 14, line 30
xTRs that offer L2 overlay services and are part of the same xTRs that offer L2 overlay services and are part of the same
Instance-ID join a common Multicast Group. When required, this group Instance-ID join a common Multicast Group. When required, this group
allows ITRs to send traffic that needs to be replicated (flooded) to allows ITRs to send traffic that needs to be replicated (flooded) to
all ETRs participating in the L2-overlay (e.g., broadcast traffic all ETRs participating in the L2-overlay (e.g., broadcast traffic
within a subnet). When the core network (RLOC space) supports native within a subnet). When the core network (RLOC space) supports native
multicast ETRs participating in the L2-overlay join a (*,G) group multicast ETRs participating in the L2-overlay join a (*,G) group
associated to the Instance-ID. associated to the Instance-ID.
When multicast is not available in the core network, each xTR that is When multicast is not available in the core network, each xTR that is
part of the same instance-ID SHOULD register a (S,G) entry to the part of the same instance-ID SHOULD register a (S,G) entry to the
mapping system using the procedures described in mapping system using the procedures described in [RFC8378], where S
[I-D.ietf-lisp-signal-free-multicast], where S is 0000-0000-0000/0 is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows
and G is ffff-ffff-ffff/48. This strategy allows and ITR to know and ITR to know which ETRs are part of the L2 overlay and it can
which ETRs are part of the L2 overlay and it can head-end replicate head-end replicate traffic to.
traffic to.
Following the same case, when multicast is not available in the core Following the same case, when multicast is not available in the core
network, the procedures in [I-D.ietf-lisp-signal-free-multicast] can network, the procedures in [RFC8378] can be used to ensure proper
be used to ensure proper distribution of link-local multicast traffic distribution of link-local multicast traffic across xTRs
across xTRs participating in the L2 overlay. In such case, the xTRs participating in the L2 overlay. In such case, the xTRs SHOULD join
SHOULD join a (S,G) entry with S being 0000-0000-0000/0 and where G a (S,G) entry with S being 0000-0000-0000/0 and where G is
is 0100-0000-0000/8. 0100-0000-0000/8.
5.2.6. L2 Unknown Unicast Support 5.2.6. L2 Unknown Unicast Support
An ITR attempts to resolve MAC destination misses through the Mapping An ITR attempts to resolve MAC destination misses through the Mapping
System. When the destination host remains undiscovered the System. When the destination host remains undiscovered the
destination is considered an Unknown Unicast. destination is considered an Unknown Unicast.
A Map-Server SHOULD respond to a Map-Request for an undiscovered host A Map-Server SHOULD respond to a Map-Request for an undiscovered host
with a Negative Map-Reply with action "Native Forward". with a Negative Map-Reply with action "Native Forward".
Alternatively the action "Drop" may be used in order to suppress Alternatively the action "Drop" may be used in order to suppress
skipping to change at page 17, line 13 skipping to change at page 17, line 13
mapping system: mapping system:
o The EID 2-tuple (IID, IP) and its binding to a corresponding host o The EID 2-tuple (IID, IP) and its binding to a corresponding host
MAC address. MAC address.
In this case both the xTRs and the Mapping System MUST support an 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. EID-to-RLOC mapping where the MAC address is set as a locator record.
In order to guarantee compatibility with current implementations of In order to guarantee compatibility with current implementations of
xTRs, the MAC locator record SHALL be encoded following the AFI-List xTRs, the MAC locator record SHALL be encoded following the AFI-List
LCAF Type defined in [I-D.ietf-lisp-lcaf]. This option would also LCAF Type defined in [RFC8060]. This option would also allow adding
allow adding additional attributes to the locator record, while additional attributes to the locator record, while maintaining
maintaining compatibility with legacy devices. compatibility with legacy devices.
This mapping is registered with the Mapping System using the This mapping is registered with the Mapping System using the
following EID record structure, following EID record structure,
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved | E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 | D | Rsvd | Map-Version Number | AFI = 16387 |
skipping to change at page 22, line 5 skipping to change at page 21, line 50
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>. <https://www.rfc-editor.org/info/rfc6833>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>.
9.2. Informative References 9.2. Informative References
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-08 (work in progress), Engineering", draft-coras-lisp-re-08 (work in progress),
November 2015. November 2015.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-08 (work in progress), September 2016.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-16 (work in
progress), October 2016.
[I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-01 (work in
progress), April 2016.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Kreeger, L. and U. Elzur, "Generic Protocol Extension for Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
April 2016. in progress), April 2018.
[I-D.kouvelas-lisp-map-server-reliable-transport] [I-D.kouvelas-lisp-map-server-reliable-transport]
Cassar, C., Kouvelas, I., Lewis, D., Arango, J., and J. Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.
Leong, "LISP Map Server Reliable Transport", draft- Arango, "LISP Map Server Reliable Transport", draft-
kouvelas-lisp-map-server-reliable-transport-02 (work in kouvelas-lisp-map-server-reliable-transport-04 (work in
progress), August 2016. progress), September 2017.
Authors' Addresses Authors' Addresses
Marc Portoles Comeras Marc Portoles Comeras
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: mportole@cisco.com Email: mportole@cisco.com
 End of changes. 21 change blocks. 
53 lines changed or deleted 51 lines changed or added

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