idnits 2.17.00 (12 Aug 2021) /tmp/idnits58985/draft-boucadair-lisp-idr-ms-discovery-01.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 (March 9, 2016) is 2257 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-Document' is mentioned on line 274, but not defined == Outdated reference: draft-boucadair-connectivity-provisioning-protocol has been published as RFC 8921 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental Orange 5 Expires: September 10, 2016 March 9, 2016 7 LISP Mapping Service Discovery at Large 8 draft-boucadair-lisp-idr-ms-discovery-01 10 Abstract 12 Locator/ID Separation Protocol (LISP) operation relies upon a mapping 13 mechanism that is used by ingress/egress Tunnel Routers (xTR) to 14 forward traffic over the LISP network. The ability of dynamically 15 discovering the Map-Resolver and Map-Server entities that provide 16 such mapping services is meant to facilitate global LISP operation 17 (automatic discovery of Map-Resolvers and Map-Servers). 19 This document specifies a BGP Extended Communities attribute that can 20 be used to dynamically discover LISP Mapping Systems of different 21 domains. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. LISP Mapping System Target BGP Extended Community . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative references . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative references . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 77 upon a mapping mechanism that is used by ingress/egress Tunnel 78 Routers (xTR) to forward traffic over the LISP network. The ability 79 of dynamically discovering the Map-Resolver and Map-Server entities 80 that provide such mapping services is meant to facilitate global LISP 81 operation (automatic discovery of Map-Resolvers and Map-Servers). 83 Within this document, a Mapping System provides the LISP mapping 84 service [RFC6833]. Map-Resolvers, Map-Servers, and other components 85 may be part of a Mapping System such as authorization, subscription 86 profiles, etc. These components are considered as black boxes; only 87 the external behavior of the Mapping System is in scope. 89 Distinct LISP mapping systems may emerge if LISP users or network 90 operators who solicit or manage the Mapping System want to avoid some 91 region-centric systems, for example, or if they want to position 92 themselves as a core provider of the Mapping System. The lack of 93 clear policies of the management and operation of the LISP Mapping 94 Systems may encourage such practices. 96 This document assumes a hierarchy in the Mapping System organisation 97 for business, governance, control, and regulatory purposes in 98 particular. In such contexts, the document assumes that a Mapping 99 System may maintain a portion of or a global mapping table. 101 Because of its experimental nature of LISP and the various platforms 102 LISP operation relies upon (like the platforms used by the LISP 103 mapping systems) should encourage innovation by testing new services 104 that may take advantage of LISP in inter-domain deployment scenarios 105 without requiring the participation of all LISP-enabled domains. 106 Such approach is also meant to avoid any risk of freezing LISP 107 developments. 109 Because the design and operation of a consistent Mapping System is 110 critical for the adoption of LISP at large scale, this document 111 advocates for means to dynamically discover other Mapping Systems 112 that are open to cooperate in inter-domain LISP deployment scenarios, 113 typically . 115 Deploying LISP for inter-domain use cases may raise the following 116 issues: 118 Issue#1: A LISP domain may need to discover available Mapping 119 Systems so that it can rely upon them to extend the reachability 120 scope. 122 Issue#2: Various Mapping Systems can be deployed over the Internet. 123 These Mapping Systems need to interconnect to extend the 124 reachability scope and avoid pressure on PTR (Proxy Tunnel Router) 125 devices. Also, various Mapping Systems encourage the enforcement 126 of policies that aim at optimizing LISP forwarding: for example, 127 policies that consist in avoiding the solicitation of specific 128 domains/ASes. 130 Issue#3: Distinct flavors of Mapping Systems may be deployed. 131 These mappings may not rely on the same database mapping system 132 (e.g., NERD, ALT, CONS, etc.). As such, a clear interface to ease 133 interconnection between these realms is needed. Standard 134 solutions to discover Mapping Systems capabilities are likely to 135 ease the interconnection of Mapping Systems. 137 Issue#4: Security concerns may arise during the discovery of the 138 available Mapping Systems: for example, a given Mapping System may 139 deny access from another domain, or available Mapping Systems need 140 to make sure that they are entitled to exchange information with 141 one another or that an xTR of a given LISP network is entitled to 142 solicit a mapping system of another LISP network, etc. 144 An efficient and scalable deployment of LISP within an inter-domain 145 context for traffic engineering purposes, in particular, relies 146 heavily on the availability of an inter-domain mapping system that 147 spans several domains. From this perspective, the success of a 148 global LISP adoption and deployment will mainly depend on how LISP- 149 enabled domains will graft to existing mapping systems that can 150 guarantee a global reachability scope. To minimize the risk of a 151 fragmented Mapping System that would jeopardize the overall 152 efficiency of an inter-domain LISP routing system, there is a need to 153 encourage and facilitate the coordination of participating Mapping 154 Systems. 156 This document relies on extended BGP communities [RFC4360] to 157 advertise that a given domain supports the LISP Mapping Service. A 158 contact IPv4 address and/or IPv6 address are also included in the 159 attribute so that remote LISP Mapping Systems or LISP domains may 160 initiate negotiation cycles for the sake of LISP Mapping System 161 Interconnection or subscription to the Mapping Service offered by 162 that Mapping System. 164 Section 3 specifies a solution for the discovery of LISP Mapping 165 Systems that are deployed in distinct administrative domains. This 166 BGP-based solution assumes that domains that support a LISP Mapping 167 Service will use the BGP Extended Communities attribute to inform 168 other domains about the support of the service. EIDs that can be 169 serviced with LISP will be tagged accordingly. Note that an EID can 170 be serviced by multiple Mapping Systems. Remote LISP Mapping Systems 171 will rely upon that BGP-based advertising capability to discover the 172 existence and the status of other Mapping Systems. Once a Mapping 173 System is discovered, a local Mapping System can establish an 174 interconnection agreement with that remote Mapping System. The 175 contact IP address provided as part of the BGP Extended Communities 176 attribute will be used to contact a remote Mapping System to request 177 for further LISP-related capabilities, possibly negotiate an 178 interconnection agreement and, consequently, extend the scope of the 179 networks that can be serviced using LISP. Also, leaf LISP-aware 180 networks can rely upon the information carried in the BGP Extended 181 Communities attribute to discover Mapping Systems that may be 182 solicited to invoke their mapping service. Subscription cycles may 183 then be considered. 185 2. Rationale 187 This document focuses on the discovery of LISP Mapping Systems that 188 are deployed in distinct administrative domains. 190 The rationale is as follows: 192 1. Announce: Domains that support a LISP Mapping Service will use 193 the BGP Extended Communities attribute (Section 3) to inform 194 other domains about the support of the service. EIDs that can be 195 serviced with LISP can be tagged accordingly. Note that an EID 196 can be serviced by multiple Mapping Systems. 198 2. Discover: Remote LISP Mapping Systems will rely upon that BGP- 199 based advertising capability (Section 3) to discover the 200 existence of other Mapping Systems. 202 3. Negotiate/Interconnect/Invoke: The contact IP address provided as 203 part of the BGP Extended Communities attribute (Section 3) will 204 be used to contact a remote Mapping System to request for further 205 LISP-related capabilities, possibly negotiate an interconnection 206 agreement and, consequently, extend the scope of the networks 207 that can be serviced using LISP. 209 4. Negotiate/Subscribe/Invoke: Also, leaf LISP-aware networks can 210 rely upon the information carried in the BGP Extended Communities 211 attribute to discover Mapping Systems that may be solicited to 212 invoke their mapping service. Subscription cycles may then be 213 considered. 215 Only the first two steps are in scope of this document; the remaining 216 steps can be achieved by other means such as 217 [I-D.boucadair-connectivity-provisioning-protocol]. 219 3. LISP Mapping System Target BGP Extended Community 221 The LISP Mapping System Target Community identifies one or more 222 Mapping System contact points that can receive mapping system 223 interconnect and/or subscription requests. These contact points are 224 identified with IPv4 and/or IPv6 addresses. 226 The LISP Mapping System Target Community is of an extended type. As 227 such, the behavior specified in Section 6 of [RFC4360] applies to the 228 LISP Mapping System Target Community. 230 The presence of this community is an explicit indication that 231 associated networks can be managed by a LISP Mapping System that is 232 reachable at the addresses carried in the attribute. 234 This document reuses the Transitive IPv4-Address-Specific Extended 235 Community [RFC4360] and Transitive IPv6-Address-Specific Extended 236 Community [RFC5701] for the purpose of this document. Dedicated sub- 237 types are to be allocated (see Section 5). 239 The Global Administrator field MUST be set to an IP address of the 240 Mapping System. This address MUST be configured on the originating 241 BGP speaker. 243 The "Local Administrator" field of the LISP Mapping System Target 244 Community is used to encode an identifier of the Mapping System. 245 Considerations about the assignment of globally unique identifiers to 246 LISP Mapping Systems are out of scope. A configurable parameter may 247 be supported by BGP implementations to provide the value carried in 248 the "Local Administrator" field. If no identifier is configured on 249 the originating BGP speaker, the "Local Administrator" field MUST be 250 set to 0. 252 4. Security Considerations 254 This document does not introduce any additional security issues other 255 than those discussed in [RFC4360] and [RFC5701]. 257 5. IANA Considerations 259 According to [RFC7153], this document requests the assignment of a 260 sub-type in the "0x00-0xbf" range from the Transitive IPv4-Address- 261 Specific Extended Community Sub-Types registry available at 262 http://www.iana.org/assignments/bgp-extended-communities/bgp- 263 extended-communities.xml#trans-ipv4: 265 Type Value Name Reference 266 TBA LISP Mapping System Target [This-Document] 268 Also, this document requests the assignment of a sub-type from the 269 Transitive IPv6-Address-Specific Extended Community Types registry 270 available at http://www.iana.org/assignments/bgp-extended- 271 communities/bgp-extended-communities.xml#trans-ipv6: 273 Type Value Name Reference 274 TBA LISP Mapping System Target [This-Document] 276 6. Acknowledgments 278 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 279 009-X. 281 7. References 283 7.1. Normative references 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 291 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 292 February 2006, . 294 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 295 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 296 . 298 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 299 Locator/ID Separation Protocol (LISP)", RFC 6830, 300 DOI 10.17487/RFC6830, January 2013, 301 . 303 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 304 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 305 March 2014, . 307 7.2. Informative references 309 [I-D.boucadair-connectivity-provisioning-protocol] 310 Boucadair, M., Jacquenet, C., Zhang, D., and P. 311 Georgatsos, "Connectivity Provisioning Negotiation 312 Protocol (CPNP)", draft-boucadair-connectivity- 313 provisioning-protocol-10 (work in progress), September 314 2015. 316 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 317 Protocol (LISP) Map-Server Interface", RFC 6833, 318 DOI 10.17487/RFC6833, January 2013, 319 . 321 Authors' Addresses 323 Mohamed Boucadair 324 Orange 325 Rennes 35000 326 France 328 EMail: mohamed.boucadair@orange.com 329 Christian Jacquenet 330 Orange 331 Rennes 35000 332 France 334 EMail: christian.jacquenet@orange.com