draft-ietf-lisp-eid-mobility-08.txt   draft-ietf-lisp-eid-mobility-09.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 F. Maino
Expires: 26 January 2022 F. Maino Expires: 22 July 2022 Cisco Systems
Cisco Systems V. Moreno
Google LLC
D. Farinacci D. Farinacci
lispers.net lispers.net
25 July 2021 18 January 2022
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-08 draft-ietf-lisp-eid-mobility-09
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 for End-point Identifier (EID) mobility, as well L3 overlay solution for End-point Identifier (EID) mobility, as well
as analyzing possible deployment options and models. as analyzing possible deployment options and models.
Requirements Language Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 45
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 26 January 2022. This Internet-Draft will expire on 22 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4
4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5
4.1. Reference Architecture and packet flows . . . . . . . . . 5 4.1. Reference Architecture and packet flows . . . . . . . . . 5
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
skipping to change at page 3, line 11 skipping to change at page 3, line 17
5.3.2. ARP registrations: MAC as a locator record . . . . . 19 5.3.2. ARP registrations: MAC as a locator record . . . . . 19
5.3.3. Implementation Considerations . . . . . . . . . . . . 21 5.3.3. Implementation Considerations . . . . . . . . . . . . 21
6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22
6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22
6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document describes the architecture and design options required This document describes the architecture and design options required
to offer a unified L2 and L3 overlay solution for End-point to offer a unified L2 and L3 overlay solution for End-point
Identifier (EID) mobility using the LISP control-plane. Identifier (EID) mobility using the LISP control-plane.
The architecture takes advantage of the flexibility that LISP The architecture takes advantage of the flexibility that LISP
provides to simultaneously support different overlay types. While provides to simultaneously support different overlay types. While
the LISP specification defines both the data-plane and the control- the LISP specification defines both the data-plane and the control-
skipping to change at page 6, line 8 skipping to change at page 6, line 10
:Device 1: :Device 2: :Device 3: :Device 4: :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) (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) (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Figure 2: Reference Mobility Architecture Figure 2: Reference Mobility Architecture
4.1.1. Routed Traffic Flow: L3 Overlay use 4.1.1. Routed Traffic Flow: L3 Overlay use
Inter-subnet traffic is encapsulated using the L3 overlay. The Inter-subnet traffic is encapsulated using the L3 overlay. The
process to encapsulate this traffic is the same as described in the process to encapsulate this traffic is the same as described in
original specification [RFC6830]. We describe the packet flow here [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis]. We
for completeness describe the packet flow here for completeness
The following is a sequence example of the unicast packet flow and The following is a sequence example of the unicast packet flow and
the control plane operations when in the topology shown in Figure 1 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 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 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 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). End-Device 4 (e.g. it is learned using a DNS service).
* End-Device 1 sends an IP packet frame with destination 2.0.0.4 and * 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 source 1.0.0.1. As the destination address lies on a different
skipping to change at page 10, line 27 skipping to change at page 10, line 27
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-Prefix (IPv4 or IPv6) | | | EID-Prefix (IPv4 or IPv6) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L3 EID record follows the structure as described in [RFC6830]. The L3 EID record follows the structure as described in
[I-D.ietf-lisp-rfc6833bis].
4.2.3. LISP Mapping System support 4.2.3. LISP Mapping System support
The interface between the xTRs and the Mapping System is described in The interface between the xTRs and the Mapping System is described in
[RFC6833] and this document follows the specification as described [I-D.ietf-lisp-rfc6833bis] and this document follows the
there. When available, the registrations MAY be implemented over a specification as described there. When available, the registrations
reliable transport as described in MAY be implemented over a reliable transport as described in
[I-D.kouvelas-lisp-map-server-reliable-transport]. [I-D.kouvelas-lisp-map-server-reliable-transport].
In order to support system convergence after mobility, when the Map- In order to support system convergence after mobility, when the Map-
Server receives a new registration for a specific EID, it MUST send a Server receives a new registration for a specific EID, it MUST send a
Map-Notify to the entire RLOC set in the site that last registered Map-Notify to the entire RLOC set in the site that last registered
this same EID. This Map-Notify is used to track moved-away state of this same EID. This Map-Notify is used to track moved-away state of
L3 EIDs as described in Section 4.2.4. L3 EIDs as described in Section 4.2.4.
4.2.4. Using SMRs to Track Moved-Away Hosts 4.2.4. Using SMRs to Track Moved-Away Hosts
One of the key elements to support end-host mobility using the LISP One of the key elements to support end-host mobility using the LISP
architecture is the Solicit-Map-Request (SMR). This is a special architecture is the Solicit-Map-Request (SMR). This is a special
message by means of which an ETR can request an ITR to send a new 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 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 is used as a signal to indicate a change in mapping information and
it is described with detail in [RFC6830]. it is described in [I-D.ietf-lisp-rfc6833bis].
In order to support mobility, an ETR SHALL maintain a list of EID 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 records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination. receives traffic with that EID as destination.
The particular strategy to maintain an Away Table is implementation The particular strategy to maintain an Away Table is implementation
specific and it will be typically based on the strategy to detect the specific and it will be typically based on the strategy to detect the
presence of hosts and the use of Map-Notify messages received from presence of hosts and the use of Map-Notify messages received from
the Map-Server. In essence the table SHOULD provide support to the the Map-Server. In essence the table SHOULD provide support to the
following: following:
skipping to change at page 11, line 30 skipping to change at page 11, line 30
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], and [RFC8378]. in in [RFC6831], and [RFC8378].
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 ([I-D.ietf-lisp-rfc6830bis]) describes how to
Live values of the inner and outer headers during encapsulation and handle Time-to-Live values of the inner and outer headers during
decapsulation of packets when using the L3 overlay. encapsulation and 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.
/ | | \ / | | \
skipping to change at page 16, line 29 skipping to change at page 16, line 29
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| ... Layer-2 MAC Address | Priority | Weight | | /| ... Layer-2 MAC Address | Priority | Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | M Priority | M Weight | Unused Flags |L|p|R| | o | M Priority | M Weight | Unused Flags |L|p|R|
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Loc-AFI | Locator.... | | | | Loc-AFI | Locator.... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Locator | \| ... Locator
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2 EID record follows the structure as described in [RFC6830]. The L2 EID record follows the structure as described in
[I-D.ietf-lisp-rfc6833bis].
5.2.3. Interface to the LISP Mapping System 5.2.3. Interface to the LISP Mapping System
The interface between the xTRs and the Mapping System is described in The interface between the xTRs and the Mapping System is described in
[RFC6833] and this document follows the specification as described [I-D.ietf-lisp-rfc6833bis] and this document follows the
there. When available, the registrations MAY be implemented over a specification as described there. When available, the registrations
reliable transport. MAY be implemented over a reliable transport.
In order to support system convergence after mobility, when the Map- In order to support system convergence after mobility, when the Map-
Server receives a new registration for a specific EID, it MUST send a Server receives a new registration for a specific EID, it MUST send a
Map-Notify to the entire RLOC set in the site that last registered Map-Notify to the entire RLOC set in the site that last registered
this same EID. This Map-Notify is used to track moved-away state of this same EID. This Map-Notify is used to track moved-away state of
L2 EIDs as described in Section 5.2.4. L2 EIDs as described in Section 5.2.4.
5.2.4. SMR support to track L2 hosts that moved away 5.2.4. SMR support to track L2 hosts that moved away
In order to support mobility, an ETR SHALL maintain a list of EID In order to support mobility, an ETR SHALL maintain a list of EID
skipping to change at page 20, line 46 skipping to change at page 20, line 49
| C | Rsvd1 | Flags | Type = 1 | Rsvd2 | | C | Rsvd1 | Flags | Type = 1 | Rsvd2 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 2 + 6 | AFI = 6 | | | | 2 + 6 | AFI = 6 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Layer-2 MAC Address ... | | | | Layer-2 MAC Address ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Layer-2 MAC Address | | \| ... Layer-2 MAC Address |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
An EID record with a locator record that carries a MAC address An EID record with a locator record that carries a MAC address
follows the same structure as described in [RFC6830]. However, some follows the same structure as described in
fields of the EID record and the locator record require special [I-D.ietf-lisp-rfc6833bis]. However, some fields of the EID record
consideration: and the locator record require special consideration:
Locator Count: This value SHOULD be set to 1. Locator Count: This value SHOULD be set to 1.
Instance-ID: This is the IID used to provide segmentation of the Instance-ID: This is the IID used to provide segmentation of the
L2-overlays, L3 overlays and ARP tables. L2-overlays, L3 overlays and ARP tables.
Priority and Weight: IP to MAC bindings are one to one bindings. An 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 ETR SHOULD not register more than one MAC address in the locator
record together with an IP based EID. The Priority of the MAC record together with an IP based EID. The Priority of the MAC
address record is set to 255. The Weight value SHOULD be ignored address record is set to 255. The Weight value SHOULD be ignored
skipping to change at page 23, line 34 skipping to change at page 23, line 34
and [VXLAN]: and [VXLAN]:
* VXLAN-GPE encap: This encapsulation format is defined in * VXLAN-GPE encap: This encapsulation format is defined in
[I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3
packets and the VNI field directly maps to the Instance-ID used in packets and the VNI field directly maps to the Instance-ID used in
the control plane. Note that when using this encapsulation for a the control plane. Note that when using this encapsulation for a
unified solution the P-bit is set and the Next-Protocol field is unified solution the P-bit is set and the Next-Protocol field is
used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in
L3-overlays, and value 0x3 in L2-overlays). L3-overlays, and value 0x3 in L2-overlays).
* LISP encap: This is the encapsulation format defined in the * LISP encap: This is the encapsulation format defined in the LISP
original LISP specification [RFC6830]. The encapsulation allows specification [I-D.ietf-lisp-rfc6830bis]. The encapsulation
encapsulating both L2 and L3 packets. The Instance-ID used in the allows encapsulating both L2 and L3 packets. The Instance-ID used
EIDs directly maps to the Instance-ID that the LISP header 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 carries. At the ETR, after decapsulation, the IID MAY be used to
decide between L2 processing or L3 processing. decide between L2 processing or L3 processing.
* VXLAN encap: This is a L2 encapsulation format defined in * VXLAN encap: This is a L2 encapsulation format defined in
[RFC7348]. While being a L2 encapsulation it can be used both for [RFC7348]. While being a L2 encapsulation it can be used both for
L2 and L3 overlays. The Instance-ID used in LISP signaling maps L2 and L3 overlays. The Instance-ID used in LISP signaling maps
to the VNI field of the VXLAN header. Providing L3 overlays using to the VNI field of the VXLAN header. Providing L3 overlays using
VXLAN generally requires using the ETR MAC address as destination VXLAN generally requires using the ETR MAC address as destination
MAC address of the inner Ethernet header. The process to learn or MAC address of the inner Ethernet header. The process to learn or
derive this ETR MAC address is not included as part of this derive this ETR MAC address is not included as part of this
skipping to change at page 25, line 21 skipping to change at page 25, line 21
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lisp-gpe] [I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", Work in Smith, "LISP Generic Protocol Extension", Work in
Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July
2020, <https://www.ietf.org/internet-drafts/draft-ietf- 2020, <https://www.ietf.org/archive/id/draft-ietf-lisp-
lisp-gpe-19.txt>. gpe-19.txt>.
[I-D.ietf-lisp-pubsub] [I-D.ietf-lisp-pubsub]
AlbertoRodriguezNatal, Ermagan, V., Cabellos-Aparicio, A., Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
Barkai, S., and M. Boucadair, "Publish/Subscribe S., and M. Boucadair, "Publish/Subscribe Functionality for
Functionality for LISP", Work in Progress, Internet-Draft, LISP", Work in Progress, Internet-Draft, draft-ietf-lisp-
draft-ietf-lisp-pubsub-09, 28 June 2021, pubsub-09, 28 June 2021, <https://www.ietf.org/archive/id/
<https://www.ietf.org/archive/id/draft-ietf-lisp-pubsub- draft-ietf-lisp-pubsub-09.txt>.
09.txt>.
[I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)",
Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6830bis-36, 18 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6830bis-36.txt>.
[I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
"Locator/ID Separation Protocol (LISP) Control-Plane",
Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6833bis-30, 18 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6833bis-30.txt>.
[I-D.ietf-lisp-vpn] [I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", Work in Progress, Internet-Draft, draft- Networks (VPNs)", Work in Progress, Internet-Draft, draft-
ietf-lisp-vpn-06, 3 August 2020, <http://www.ietf.org/ ietf-lisp-vpn-08, 18 January 2022,
internet-drafts/draft-ietf-lisp-vpn-06.txt>. <https://www.ietf.org/archive/id/draft-ietf-lisp-vpn-
08.txt>.
[I-D.kouvelas-lisp-map-server-reliable-transport] [I-D.kouvelas-lisp-map-server-reliable-transport]
Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C., Leong, J., Lewis, D., Pitta, B., Cassar, C., Kouvelas, I.,
Kouvelas, I., and J. Arango, "LISP Map Server Reliable and J. Arango, "LISP Map Server Reliable Transport", Work
Transport", Work in Progress, Internet-Draft, draft- in Progress, Internet-Draft, draft-kouvelas-lisp-map-
kouvelas-lisp-map-server-reliable-transport-06, 26 April server-reliable-transport-07, 18 January 2022,
2021, <https://www.ietf.org/archive/id/draft-kouvelas- <https://www.ietf.org/archive/id/draft-kouvelas-lisp-map-
lisp-map-server-reliable-transport-06.txt>. server-reliable-transport-07.txt>.
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
United States of America United States of America
Email: mportole@cisco.com Email: mportole@cisco.com
Vrushali Ashtaputre Vrushali Ashtaputre
Cisco Systems Cisco Systems
skipping to change at page 26, line 20 skipping to change at page 26, line 31
Email: mportole@cisco.com Email: mportole@cisco.com
Vrushali Ashtaputre Vrushali Ashtaputre
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States of America United States of America
Email: vrushali@cisco.com Email: vrushali@cisco.com
Victor Moreno
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
United States of America
Email: vimoreno@cisco.com
Fabio Maino Fabio Maino
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States of America United States of America
Email: fmaino@cisco.com Email: fmaino@cisco.com
Victor Moreno
Google LLC
1600 Amphitheatre Pkwy
Mountain View, CA 94043
United States of America
Email: vimoreno@google.com
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
United States of America United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
 End of changes. 23 change blocks. 
57 lines changed or deleted 76 lines changed or added

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