Internet-Draft MS-originated SMRs October 2021
Rodriguez-Natal, et al. Expires 14 April 2022 [Page]
Workgroup:
LISP Working Group
Internet-Draft:
draft-rodrigueznatal-lisp-ms-smr-13
Published:
Intended Status:
Informational
Expires:
Authors:
A. Rodriguez-Natal
Cisco Systems
A. Cabellos-Aparicio
Technical University of Catalonia
V. Ermagan
Google
F. Maino
Cisco Systems
S. Barkai
Nexar Inc.

MS-originated SMRs

Abstract

This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers to send SMR messages.

This extension is intended to be used in some SDN deployments that use LISP as a southbound protocol with (P)ITRs that are compliant with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do not come from ETRs, but rather from a centralized controller that pushes the updates directly to the Mapping System. In such deployments, Map Servers will benefit from having a mechanism to inform directly (P)ITRs about updates in the mappings they are serving. Although implementations of this extension exist, this extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being documented for informational purposes. Newer implementations should look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP deployments.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 April 2022.

Table of Contents

1. Introduction

The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] splits current IP addresses in two different namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies in two entities, the Mapping System and the Tunnel Routers. The Tunnel Routers are deployed at LISP sites edge points and perform encapsulation and decapsulation of LISP data packets. The Mapping System is a distributed database that stores and disseminates EID-RLOC bindings across different Map-Servers. LISP Tunnel Routers keep a cache of EID-RLOC mappings pulled from the Mapping System.

There are several ways to keep this cache updated as described in [I-D.ietf-lisp-rfc6833bis]. Among them, the Solicit Map-Request (SMR) message allows to explicitly signal (P)ITRs to let them know that some of their cached mappings may be outdated. However, vanilla LISP as described in [I-D.ietf-lisp-rfc6833bis] only considers SMR messages to be sent by an ETR. This document extends [I-D.ietf-lisp-rfc6833bis] to cover the case where SMRs can be sent also by a Map Server (MS).

This document introduces changes in the MS specification allowing them to send SMR messages, however it does not require any modification in the (P)ITRs. This document is backwards compatible and enables upgraded MSs to interoperate via SMRs with legacy (P)ITRs that only implement [I-D.ietf-lisp-rfc6833bis].

This document offers a basic form of Publish/Subscribe (PubSub) compatible with legacy LISP devices. The LISP WG is currently working on [I-D.ietf-lisp-pubsub] as the comprehensive mechanism to enable PubSub in LISP which deprecates this document. Newer implementations should look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP deployments.

1.1. Requirements Language

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 RFC 2119 [RFC2119].

2. Map Server extension

This document enables MS to generate and send SMR messages towards (P)ITRs. SMRs originated in a MS follow the same format described in [I-D.ietf-lisp-rfc6833bis]. Besides the fact that they are sent from a MS, there is no difference between an SMR originated in an ETR and one originated in a MS.

A MS supporting the extension described in this document is supposed to keep track of the Map-Requests received for the mappings it is serving. When receiving a Map-Request, the MS should extract the source EID and ITR-RLOCs from the message and keep them associated with the requested mapping. The MS is expected to keep this state for a period equal to the TTL of the mapping. When the mapping changes, the MS should build and send an SMR to the (P)ITR that requested the mapping using the stored EID and ITR-RLOCs, as described below.

When a MS generates an SMR, it uses as source-EID the EID-prefix it wants the (P)ITR to send the SMR-invoked Map-Request for (i.e. the EID of the mapping that changed). The EID included in the EID-record field is the one belonging to the (P)ITR the MS sends the SMR towards and that was extracted from the original Map-Request. The destination locator is one of the ITR-RLOCs associated with the EID of the (P)ITR that were received in the Map-Request. As source locator for the SMR message, the MS uses one of its available locators. This has implications in the processing of the SMR at the (P)ITR as described in Section 4

As specified in [I-D.ietf-lisp-rfc6833bis] and noted in Section 7, SMRs MUST be rate-limited. It must be noted as well that, as described in Section 3, a MS that sends an SMR may not necessarily receive the SMR-invoked Map-Request that the (P)ITR generates as response to the SMR.

3. Interoperability with legacy (P)ITRs

This document introduces no changes in the specification of (P)ITRs and thus it is backwards compatible with legacy equipment only compliant with [I-D.ietf-lisp-rfc6833bis]. However, since SMRs were designed to be sent by ETRs, and legacy (P)ITRs expect to receive SMRs only from ETRs, the implications of sending SMRs from a MS are discussed in this section.

As indicated in Section 2, the MS generates the SMR message using one of its locators as source locator. However, this locator will not be present in the Locator-Set cached for that EID-prefix at the (P)ITR. Following [I-D.ietf-lisp-rfc6833bis], upon receiving the SMR message, the (P)ITR will check if the source locator is in the Locator-Set cached for that EID-record. Since it is not, the (P)ITR will send the SMR-invoked Map-Request always to the Mapping System and never to the source locator of the SMR message. This means that a MS can not force an SMR-invoked Map-Request to be sent directly towards itself. However, it is possible that the Mapping System in use is instantiated (even partially) by the MS originator of the SMR. In that case, it may be that the SMR-invoked Map Request will eventually reach the MS, either directly or after being internally forwarded through the Mapping System.

4. Deployment considerations

The extension defined in this document may be useful in scenarios where the MS wants to signal (P)ITRs about changes on mappings it is serving. For instance, when the MS is keeping track of the (P)ITRs that are requesting its mappings and wants to inform them intermediately whenever a mapping is updated.

SDN deployments that use LISP as a southbound protocol are particularly suitable to take advantage of this extension. On the SDN scenario, mapping updates will unlikely come from ETRs, but rather from a centralized entity that pushes the updates directly to the Mapping System. In such deployments, Map Servers will benefit from having a mechanism to inform directly (P)ITRs about updates in the mappings they are serving.

Due to scalability and security concerns, it is RECOMMENDED that this extension is only applied in intra-domain scenarios where all LISP devices are within a single administrative domain.

To limit the impact of the extension and to ease its integration with the rest of LISP signaling and operation, it is RECOMMENDED that the MS only sends SMR messages for those mappings it is proxy-replying for.

5. Acknowledgments

The authors would like to thank Joel Halpern and Luigi Iannone for their guidance regarding this document.

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

As described in [I-D.ietf-lisp-rfc6833bis], the SMR messages and the SMR-invoked Map-Request MUST be rate-limited. This does not change with the extension proposed in this document.

The (P)ITRs receiving SMRs from the MS will send Map-Request messages to the Mapping System to retrieve authoritative mappings. It is RECOMMENDED that the security mechanism described in [I-D.ietf-lisp-sec] and [RFC8111] are in place to secure the mapping retrieval and protect against unsolicited messages or hijacking attacks.

8. References

8.1. Normative References

[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, , <https://www.ietf.org/archive/id/draft-ietf-lisp-rfc6833bis-30.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc8111>.

8.2. Informative References

[I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, S., and M. Boucadair, "Publish/Subscribe Functionality for LISP", Work in Progress, Internet-Draft, draft-ietf-lisp-pubsub-09, , <https://www.ietf.org/archive/id/draft-ietf-lisp-pubsub-09.txt>.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, Internet-Draft, draft-ietf-lisp-sec-23, , <https://www.ietf.org/archive/id/draft-ietf-lisp-sec-23.txt>.

Authors' Addresses

Alberto Rodriguez-Natal
Cisco Systems
170 Tasman Drive
San Jose, CA
United States of America
Albert Cabellos-Aparicio
Technical University of Catalonia
Barcelona
Spain
Vina Ermagan
Google
United States of America
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, CA
United States of America
Sharon Barkai
Nexar Inc.
CA
United States of America