[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

LISP Working Group                                    A. Rodriguez-Natal
Internet-Draft                                             Cisco Systems
Intended status: Informational                      A. Cabellos-Aparicio
Expires: October 6, 2019               Technical University of Catalonia
                                                              V. Ermagan
                                                                  Google
                                                                F. Maino
                                                           Cisco Systems
                                                               S. Barkai
                                                              Nexar Inc.
                                                           April 4, 2019


                           MS-originated SMRs
                  draft-rodrigueznatal-lisp-ms-smr-08

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."



Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 1]


Internet-Draft             MS-originated SMRs                 April 2019


   This Internet-Draft will expire on October 6, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Map Server extension  . . . . . . . . . . . . . . . . . . . .   3
   3.  Interoperability with legacy (P)ITRs  . . . . . . . . . . . .   4
   4.  Deployment considerations . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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



Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 2]


Internet-Draft             MS-originated SMRs                 April 2019


   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



Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 3]


Internet-Draft             MS-originated SMRs                 April 2019


   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



Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 4]


Internet-Draft             MS-originated SMRs                 April 2019


   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]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-24 (work in progress), February
              2019.







Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 5]


Internet-Draft             MS-originated SMRs                 April 2019


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.

8.2.  Informative References

   [I-D.ietf-lisp-pubsub]
              Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
              Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
              Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
              Subscribe Functionality for LISP", draft-ietf-lisp-
              pubsub-03 (work in progress), March 2019.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17
              (work in progress), November 2018.

Authors' Addresses

   Alberto Rodriguez-Natal
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: natal@cisco.com


   Albert Cabellos-Aparicio
   Technical University of Catalonia
   Barcelona
   Spain

   Email: acabello@ac.upc.edu


   Vina Ermagan
   Google
   USA

   Email: ermagan@gmail.com



Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 6]


Internet-Draft             MS-originated SMRs                 April 2019


   Fabio Maino
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: fmaino@cisco.com


   Sharon Barkai
   Nexar Inc.
   CA
   USA

   Email: sharon.barkai@getnexar.com




































Rodriguez-Natal, et al.  Expires October 6, 2019                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/