idnits 2.17.1 draft-jain-lisp-site-external-connectivity-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2021) is 910 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lisp-vpn' is defined on line 186, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-07 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-25 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vendor-lcaf-05 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jain 3 Internet-Draft V. Moreno 4 Intended status: Experimental S. Hooda 5 Expires: April 25, 2022 Cisco Systems 6 October 22, 2021 8 LISP Site External Connectivity 9 draft-jain-lisp-site-external-connectivity-04 11 Abstract 13 This draft defines how to register/retrieve pETR mapping information 14 in LISP when the destination is not registered/known to the local 15 site and its mapping system (e.g. the destination is an internet or 16 external site destination). 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 60 3. pETR Registration/Notification . . . . . . . . . . . . . . . 3 61 4. pETR Request/Resolution . . . . . . . . . . . . . . . . . . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 8. Normative Reference . . . . . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The LISP architecture and protocol [I-D.ietf-lisp-rfc6833bis] 71 introduces two types of replies to a map-request sent by an ITR: 73 - when the EID is known or registered to the mapping system, a 74 regular map-reply with mapping information is sent, or 76 - when the EID is unknown or known but not registered, a negative- 77 map-reply (NMR) is sent. 79 Currently the NMR does not convey pETR RLOC-set information to 80 specify where the ITR should send the packet. 82 This document describes how to use the LISP messages to register and 83 provide pETR RLOC-set information for destinations which are EIDs not 84 registered with the Mapping System, or simply are "not known" to be 85 an existing EID. These destinations could be the destinations which 86 are outside of the LISP site belonging to non-LISP domains, hence are 87 not registered with the LISP Mapping System. 89 The reachability of these destinations can be provided either by 90 configuring pETR information directly into the Mapping System, or by 91 the registration done by certain pETRs. The pETR registration is 92 specifically useful when the traffic to these external destinations 93 needs to be sent encapsulated to a preferred pETR/gateway chosen 94 dynamically. This mechanism also helps to achieve faster 95 convergence. 97 This document also specifies the structure of the map-reply 98 containing pETR RLOC-set information. 100 2. Definition of Terms 102 Same as defined in [I-D.ietf-lisp-rfc6833bis]. 104 3. pETR Registration/Notification 106 pETRs having external or internet connectivity MAY register the pETR 107 with the mapping system. The pETR Map-Register/Map-Notify procedures 108 and record format are the same as in [I-D.ietf-lisp-rfc6833bis] with 109 the following contents: 111 - An "EID-Prefix" as an agreed upon or configurable "Distinguished 112 Name" according to [I-D.farinacci-lisp-name-encoding]. 114 - RLOC-set for pETR information. 116 - Each locator in the RLOC-set MAY be encoded as per [I-D.ietf-lisp- 117 vpn]. This enables dynamic external connectivity in VPN 118 environments. 120 - Additional information MAY be encoded in vendor specific LCAF type 121 [I-D.ietf-lisp-vendor-lcaf] about the registering pETR such as its 122 performance matrix, resource availability for the Mapping System to 123 make preference decision. 125 4. pETR Request/Resolution 127 The Map-Request procedures and record format are the same as in [I- 128 D.ietf-lisp-rfc6833bis]. 130 When the Map-Server (or ETR) determines that the requested 131 destination is external or unknown to the mapping system, it sends a 132 Map-Reply containing the pETR information. The Map-Reply procedures 133 and record format are the same as described in the Map-Server 134 processing section of [I-D.ietf-lisp-rfc6833bis]. This Map-Reply has 135 the following content (as defined per regular map-reply and negative- 136 map-reply in [I-D.ietf-lisp-rfc6833bis]): 138 - An EID-Prefix calculated as non-LISP "hole" per the procedures in 139 [I-D.ietf-lisp-rfc6833bis] for negative map-reply. 141 - RLOC count MUST be non-zero. 143 - Each locator in the RLOC-set MAY be encoded as per [I-D.ietf-lisp- 144 vpn]. This enables dynamic external connectivity in VPN 145 environments. 147 - TTL MAY be shorter than regular map-reply. 149 - Additional information MAY be encoded in vendor specific LCAF type 150 [I-D.ietf-lisp-vendor-lcaf] about the mapping such as whether the 151 mapping is based upon policy or registration. 153 5. IANA Considerations 155 No IANA considerations apply to this document. 157 6. Security Considerations 159 There are no additional security considerations except what already 160 discussed in [I-D.ietf-lisp-rfc6833bis]. 162 7. Acknowledgements 164 The authors would like to thank Fabio Maino for the suggestions and 165 review of this document. 167 8. Normative Reference 169 [I-D.farinacci-lisp-name-encoding] 170 Farinacci, D., "LISP Distinguished Name Encoding", draft- 171 farinacci-lisp-name-encoding-07 (work in progress), March 172 2019. 174 [I-D.ietf-lisp-rfc6833bis] 175 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 176 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 177 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 178 June 2019. 180 [I-D.ietf-lisp-vendor-lcaf] 181 Rodriguez-Natal, A., Ermagan, V., Smirnov, A., Ashtaputre, 182 V., and D. Farinacci, "Vendor Specific LISP Canonical 183 Address Format (LCAF)", draft-ietf-lisp-vendor-lcaf-05 184 (work in progress), September 2019. 186 [I-D.ietf-lisp-vpn] 187 Moreno, V. and D. Farinacci, "LISP Virtual Private 188 Networks (VPNs)", draft-ietf-lisp-vpn-04 (work in 189 progress), May 2019. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, 194 . 196 Authors' Addresses 198 Prakash Jain 199 Cisco Systems 200 San Jose, CA 201 USA 203 Email: prakjain@cisco.com 205 Victor Moreno 206 Cisco Systems 207 San Jose, CA 208 USA 210 Email: vimoreno@cisco.com 212 Sanjay Hooda 213 Cisco Systems 214 San Jose, CA 215 USA 217 Email: shooda@cisco.com