Internet-Draft LISP External Connectivity October 2022
Jain, et al. Expires 21 April 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-jain-lisp-site-external-connectivity-07
Published:
Intended Status:
Experimental
Expires:
Authors:
P. Jain
Cisco Systems
V. Moreno
Google
S. Hooda
Cisco Systems

LISP Site External Connectivity

Abstract

This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination).

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

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 21 April 2023.

Table of Contents

1. Introduction

The LISP architecture and protocol [I-D.ietf-lisp-rfc6833bis] introduces two types of replies to a map-request sent by an ITR:

- when the EID is known or registered to the mapping system, a regular map-reply with mapping information is sent, or

- when the EID is unknown or known but not registered, a negative-map-reply (NMR) is sent.

Currently the NMR does not convey pETR RLOC-set information to specify where the ITR should send the packet.

This document describes how to use the LISP messages to register and provide pETR RLOC-set information for destinations which are EIDs not registered with the Mapping System, or simply are "not known" to be an existing EID. These destinations could be the destinations which are outside of the LISP site belonging to non-LISP domains, hence are not registered with the LISP Mapping System.

The reachability of these destinations can be provided either by configuring pETR information directly into the Mapping System, or by the registration done by certain pETRs. The pETR registration is specifically useful when the traffic to these external destinations needs to be sent encapsulated to a preferred pETR/gateway chosen dynamically. This mechanism also helps to achieve faster convergence.

This document also specifies the structure of the map-reply containing pETR RLOC-set information.

2. Definition of Terms

Same as defined in [I-D.ietf-lisp-rfc6833bis].

3. pETR Registration/Notification

pETRs having external or internet connectivity MAY register the pETR with the mapping system. The pETR Map-Register/Map-Notify procedures and record format are the same as in [I-D.ietf-lisp-rfc6833bis] with the following contents:

- An "EID-Prefix" as an agreed upon or configurable "Distinguished Name" according to [I-D.ietf-lisp-name-encoding].

- RLOC-set for pETR information.

- Each locator in the RLOC-set MAY be encoded as per [I-D.ietf-lisp-vpn]. This enables dynamic external connectivity in VPN environments.

- Additional information MAY be encoded in vendor specific LCAF type [I-D.ietf-lisp-vendor-lcaf] about the registering pETR such as its performance matrix, resource availability for the Mapping System to make preference decision.

4. pETR Request/Resolution

The Map-Request procedures and record format are the same as in [I-D.ietf-lisp-rfc6833bis].

When the Map-Server (or ETR) determines that the requested destination is external or unknown to the mapping system, it sends a Map-Reply containing the pETR information. The Map-Reply procedures and record format are the same as described in the Map-Server processing section of [I-D.ietf-lisp-rfc6833bis]. This Map-Reply has the following content (as defined per regular map-reply and negative-map-reply in [I-D.ietf-lisp-rfc6833bis]):

- An EID-Prefix calculated as non-LISP "hole" per the procedures in [I-D.ietf-lisp-rfc6833bis] for negative map-reply.

- RLOC count MUST be non-zero.

- Each locator in the RLOC-set MAY be encoded as per [I-D.ietf-lisp-vpn]. This enables dynamic external connectivity in VPN environments.

- TTL MAY be shorter than regular map-reply.

- Additional information MAY be encoded in vendor specific LCAF type [I-D.ietf-lisp-vendor-lcaf] about the mapping such as whether the mapping is based upon policy or registration.

5. IANA Considerations

No IANA considerations apply to this document.

6. Security Considerations

There are no additional security considerations except what already discussed in [I-D.ietf-lisp-rfc6833bis].

7. Acknowledgements

The authors would like to thank Fabio Maino for the suggestions and review of this document.

8. Normative Reference

[I-D.ietf-lisp-name-encoding]
Farinacci, D., "LISP Distinguished Name Encoding", Work in Progress, Internet-Draft, draft-ietf-lisp-name-encoding-00, , <https://www.ietf.org/archive/id/draft-ietf-lisp-name-encoding-00.txt>.
[I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", Work in Progress, Internet-Draft, draft-ietf-lisp-rfc6833bis-25, , <https://www.ietf.org/archive/id/draft-ietf-lisp-rfc6833bis-25.txt>.
[I-D.ietf-lisp-vendor-lcaf]
Rodriguez-Natal, A., Ermagan, V., Smirnov, A., Ashtaputre, V., and D. Farinacci, "Vendor Specific LISP Canonical Address Format (LCAF)", Work in Progress, Internet-Draft, draft-ietf-lisp-vendor-lcaf-05, , <http://www.ietf.org/internet-drafts/draft-ietf-lisp-vendor-lcaf-05.txt>.
[I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Work in Progress, Internet-Draft, draft-ietf-lisp-vpn-04, , <https://www.ietf.org/archive/id/draft-ietf-lisp-vpn-04.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>.

Authors' Addresses

Prakash Jain
Cisco Systems
San Jose, CA
United States of America
Victor Moreno
Google
Mountainview, CA
United States of America
Sanjay Hooda
Cisco Systems
San Jose, CA
United States of America