MS-originated SMRs
draft-rodrigueznatal-lisp-ms-smr-03
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-04-04
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
LISP Working Group A. Rodriguez-Natal
Internet-Draft Cisco Systems
Updates: 6830 (if approved) A. Cabellos-Aparicio
Intended status: Experimental Technical University of Catalonia
Expires: October 6, 2017 V. Ermagan
F. Maino
Cisco Systems
S. Barkai
Hewlett Packard Enterprise
April 4, 2017
MS-originated SMRs
draft-rodrigueznatal-lisp-ms-smr-03
Abstract
This document extends [RFC6830] 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 [RFC6830]. 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.
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 http://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 October 6, 2017.
Rodriguez-Natal, et al. Expires October 6, 2017 [Page 1]
Internet-Draft MS-originated SMRs April 2017
Copyright Notice
Copyright (c) 2017 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
(http://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 . . . . . . . . . . . . 3
4. Deployment considerations . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The Locator/ID Separation Protocol (LISP) [RFC6830] 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
[RFC6830]. 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 [RFC6830] only considers SMR messages to be sent by an ETR. This
document extends [RFC6830] to cover the case where SMRs can be sent
also by a Map Server (MS).
Show full document text