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