idnits 2.17.1 draft-boucadair-lisp-function-discovery-03.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 (November 24, 2016) is 2708 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-07) exists of draft-boucadair-lisp-bulk-03 == Outdated reference: A later version (-05) exists of draft-boucadair-lisp-subscribe-03 Summary: 2 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: Standards Track Orange 5 Expires: May 28, 2017 November 24, 2016 7 LISP Mapping Service Functions Discovery (LMSFD) using OSPF 8 draft-boucadair-lisp-function-discovery-03 10 Abstract 12 This document specifies extensions to the Open Shortest Path First 13 (OSPF) protocol for the discovery of Locator/ID Separation Protocol 14 (LISP) Mapping Service functions, especially the Map-Resolver (MR) 15 and Map-Server (MS) LISP components. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 28, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Mapping Service Function Discovery (MSFD) TLV . . . . . . . . 5 60 3.1. MSF-TYPE sub-TLV . . . . . . . . . . . . . . . . . . . . 6 61 3.2. MSF-LOCATOR sub-TLV . . . . . . . . . . . . . . . . . . . 6 62 3.3. MSF-DESCRIPTION sub-TLV . . . . . . . . . . . . . . . . . 7 63 3.4. MSF-EPOCH sub-TLV . . . . . . . . . . . . . . . . . . . . 7 64 3.5. MSF-UNAVAILABILITY-TIMER sub-TLV . . . . . . . . . . . . 8 65 3.6. MSF-REBOOT-TIMER sub-TLV . . . . . . . . . . . . . . . . 8 66 3.7. MSF-DIAGNOSIS sub-TLV . . . . . . . . . . . . . . . . . . 9 67 3.8. MS-STATUS sub-TLV . . . . . . . . . . . . . . . . . . . . 9 68 3.9. MSF-STATUS sub-TLV . . . . . . . . . . . . . . . . . . . 9 69 4. Mapping Service Reachability Information . . . . . . . . . . 10 70 5. OSPF Operation . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 82 upon a mapping mechanism that is used by ingress/egress Tunnel 83 Routers (xTR) to forward traffic over the LISP network. The ability 84 of dynamically discovering the Map-Resolver (MR) and Map-Server (MS) 85 entities that provide such mapping services is meant to facilitate 86 global LISP operation (automatic discovery of Map-Resolvers and Map- 87 Servers). 89 The dynamically-acquired information will not only be used by xTR 90 routers but also by management platforms (e.g., a service controller, 91 a network manager, etc.) to forward traffic over the LISP network or 92 to get an up-to-date view of the global LISP network topology, 93 including the location of the resolvers and servers. For example, 94 ETRs will register in all instances that are reachable in a given 95 domain. 97 The ability to dynamically discover LISP mapping component 98 information and update such information as appropriate is also useful 99 to ease state synchronization among the various Mapping Service 100 Functions that can be solicited in the LISP network, especially 101 whenever a new MS joins the LISP Mapping System. This specification 102 allows the following: 104 1. Ease the introduction of new MS servers: Additional MS instances 105 may be added to a Mapping Service domain. New MSes need to build 106 an updated mapping database to avoid service disruption. Owing 107 to the mechanism defined in this document, 109 * Peer MSes can be discovered by a new MS, thereby triggering a 110 state synchronisation procedure. How state synchronisation is 111 achieved is out of scope of this document. 113 * xTRs can immediately send registration messages to the new MS. 115 [RFC7215] indicates that, "for some LISP sites, there is a need 116 for mechanisms to dynamically obtain the address of the Map- 117 Server in the ETR of the AS". 119 2. Minimize service disruption when multiple MS/MRs are available: 120 this specification allows to disseminate information that will 121 drive the selection process undertaken by an xTR to select an MS/ 122 MR and solicit it. For example, MRs with empty databases will be 123 avoided; "ready-to-serve" MRs will be solicited instead. Map- 124 Register requests can thus be sent to multiple MSes whenever 125 needed. When a Mapping Service function loses its state, an 126 explicit message can be generated accordingly so that xTRs (and 127 also management platforms) can trigger appropriate actions. 129 This document specifies a means to dynamically discover Map-Resolver 130 and Map-Server instances of a LISP network within a domain. Also, it 131 introduces some features to enhance the serviceability of LISP (e.g., 132 detect that a MS lost its state so that a registration procedure is 133 triggered immediately, inform an xTR that a MS/MR instance is about 134 to be unavailable for some reason, indicate the synchronisation 135 status of the mapping database, etc.). 137 The document exclusively focuses on the dynamic information 138 discovery; how this information is actually used by an xTR to infer 139 its MS/MR selection procedures is out of the scope. 141 The reader should be familiar with the terms defined in [RFC6833]. 143 2. Overview 145 This document defines extensions to OSPFv2 [RFC2328] and OSPFv3 146 [RFC5340] so that routers of the OSPF routing domain (a single area 147 or the entire routing domain) can advertise a Mapping Service 148 Function within the domain, along with some other useful information. 149 To do so, a new TLV (named the LISP Mapping Service Function 150 Discovery TLV (LMSFD TLV)) is used to announce LISP MR and MS 151 information. This TLV is carried by the OSPF Router Information LSA 152 [RFC7770]. 154 The location of each Mapping Service Function is then flooded into an 155 OSPF area or the whole OSPF routing domain (in the case the LSA is 156 AS-scoped). The xTR routers deployed within the OSPF domain must 157 listen to the flooding messages sent by active Mapping Service 158 Function instances. Such messages are referred to "Mapping Service 159 Discovery" messages in this document. 161 The information to be announced by means of the LMSFD TLV carried in 162 the Router Information LSA during the LISP Mapping Service Function 163 Discovery procedure includes (but is not necessarily limited to): 165 o Mapping Service Function type: Indicates whether the MSF acts as 166 Map-Resolver (MR), Map-Server (MS), or both. 168 o Mapping Service Function Service locator(s): Includes one or 169 several IPv4 addresses, one or several IPv6 addresses or a 170 combination thereof. This information lists the set of locators 171 that unambiguously indicate where the Mapping Service Function can 172 be reached. The locator information must be included in the 173 Mapping Service Function Discovery messages. 175 o Mapping Service Function unavailability timer: Indicates the time 176 when the Mapping Service Function will be unavailable. This 177 parameter can be used for planned maintenance operations, for 178 instance. This parameter does not provide any indication about 179 when the Mapping Service Function instance will be available 180 again. This information is optional and may therefore be included 181 in the Mapping Service Function Discovery messages. 183 o Mapping Service Function reboot timer: Operational teams often 184 proceed with a reboot of the devices deployed in the network, 185 within the context of major software upgrade campaigns, for 186 example. This timer is used to indicate that a Mapping Service 187 Function will be unavailable during the reboot of the device that 188 supports the function. Unlike the previous timer, this timer is 189 used to indicate that the Mapping Service Function will be 190 available immediately after the reboot of the device that supports 191 this function is completed. This information is optional and may 192 therefore be included in the Mapping Service Function Discovery 193 messages. 195 o Mapping Service Function Diagnosis: Indicates whether this Mapping 196 Service Function instance supports a diagnostic mechanism. This 197 information is optional and may therefore be included in the 198 Mapping Service Function Discovery messages. 200 o Mapping Service Status: Provides information about the status of 201 the mapping database. In particular, it indicates whether the 202 database is empty, synchronized with other MS servers located in 203 the same OSPF domain, etc. This information is optional and may 204 therefore be included in the Mapping Service Function Discovery 205 messages. 207 o Mapping Service Function Status: Indicates the status of the 208 Mapping Service Function Instance (enabled, disabled). This 209 information is optional and may therefore be included in the LMSFD 210 messages. 212 o Additional capabilities such as the support of mapping bulk 213 retrieval [I-D.boucadair-lisp-bulk] or notifications 214 [I-D.boucadair-lisp-subscribe] may be advertised. 216 3. Mapping Service Function Discovery (MSFD) TLV 218 The format of the OSPF Mapping Service Function Discovery TLV (LMSFD 219 TLV, Figure 1) and its sub-TLVs use the same TLV format as in the 220 Traffic Engineering Extensions to OSPF [RFC3630]. 222 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 : sub-TLVs : 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1 234 The description of the fields is as follows: 236 o Type: To be assigned by IANA (see Section 7). 238 o Length: Variable (octets). 240 o sub-TLVs: Includes the list of sub-TLVs. The following sub-TLVs 241 are defined in this document: 243 Sub-TLV type Length Name 244 1 1 MSF-TYPE sub-TLV 245 2 variable MSF-LOCATOR sub-TLV 246 3 variable MSF-DESCRIPTION sub-TLV 247 4 4 MSF-EPOCH sub-TLV 248 5 4 MSF-UNAVAILABILITY-TIMER sub-TLV 249 6 4 MSF-REBOOT-TIMER sub-TLV 250 7 1 MSF-DIAGNOSIS sub-TLV 251 8 4 MS-STATUS sub-TLV 252 9 4 MSF-STATUS sub-TLV 254 The MSF-TYPE and MSF-LOCATOR sub-TLVs MUST always be present within 255 the LMSFD TLV. Additional optional sub-TLVs MAY be included. 257 3.1. MSF-TYPE sub-TLV 259 The format of MSF-TYPE sub-TLV is shown in Figure 2. 261 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type = 1 | Length=4 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 The current type values are defined: 270 0: Map-Server 271 1: Map-Resolver 272 2: Both 274 Figure 2: MSF-TYPE sub-TLV 276 3.2. MSF-LOCATOR sub-TLV 278 The format of MSF-LOCATOR sub-TLV is shown in Figure 3. 280 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type = 2 | Length=Variable | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 : IPv4 or IPv6 address : 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: MSF-LOCATOR sub-TLV 290 The MSF-LOCATOR sub-TLV MAY appear twice, especially when the SF can 291 be reached via either an IPv4 or an IPv6 address or both. It MAY 292 also appear more than once for the same address family if the Service 293 Function is assigned several addresses of the same family. 295 3.3. MSF-DESCRIPTION sub-TLV 297 The format of MSF-DESCRIPTION sub-TLV is shown in Figure 4. 299 1 2 3 300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type = 3 | Length=Variable | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 : Description : 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 4: MSF-DESCRIPTION sub-TLV 309 When present, the MSF-DESCRIPTION sub-TLV MUST carry UTF-8 encoded 310 [RFC3629] description text. The description text SHOULD NOT be null 311 terminated. 313 3.4. MSF-EPOCH sub-TLV 315 The format of MSF-EPOCH sub-TLV is shown in Figure 5. 317 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type = 4 | Length=4 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Value (seconds) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 5: MSF-EPOCH sub-TLV 327 When a Mapping Service Function loses its state (e.g., power failure, 328 bug, reset by an administrator, etc.), it may use this sub-TLV with a 329 value set to 0. This value is then incremented by one. 331 If the value field of the MSF-EPOCH sub-TLV is set to 0, it indicates 332 that the Mapping Service Function instance has been reset or lost its 333 state. This information is particularly important for ETRs so that 334 they can send their registration request immediately. 336 Receivers may maintain a record of transmitted values to detect 337 anomalies in the Mapping Service Function. 339 3.5. MSF-UNAVAILABILITY-TIMER sub-TLV 341 The format of MSF-UNAVAILABILITY-TIMER sub-TLV is shown in Figure 6. 343 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type = 5 | Length=4 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Timer (seconds) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 6: MSF-UNAVAILABILITY-TIMER sub-TLV 353 The MSF-UNAVAILABILITY-TIMER sub-TLV indicates, in seconds, when the 354 Mapping Service Function instance will be unavailable. 356 If the value field of the MSF-UNAVAILABILITY-TIMER sub-TLV is set to 357 0, it indicates the Mapping Service Function instance will be 358 unavailable immediately. 360 3.6. MSF-REBOOT-TIMER sub-TLV 362 The format of MSF-REBOOT-TIMER sub-TLV is shown in Figure 7. 364 1 2 3 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type = 6 | Length=4 | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Timer (seconds) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 7: MSF-REBOOT-TIMER sub-TLV 374 The MSF-REBOOT-TIMER sub-TLV indicates, in seconds, when the Mapping 375 Service Function instance will start to reboot. The function will be 376 operational right after the reboot is completed. 378 3.7. MSF-DIAGNOSIS sub-TLV 380 The format of MSF-DIAGNOSIS sub-TLV is shown in Figure 8. 382 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type = 7 | Length=0 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 8: MSF-DIAGNOSIS sub-TLV 390 The presence of this sub-TLV indicates that the Mapping Service 391 Function supports diagnostic functions. 393 3.8. MS-STATUS sub-TLV 395 The format of MS-STATUS sub-TLV is shown in Figure 9 397 1 2 3 398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type = 8 | Length=4 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Status | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 The current Status values are defined: 406 0: Reset 407 1: Partial 408 2: Synchronized 410 Figure 9: MS-STATUS sub-TLV 412 The presence of this sub-TLV indicates the status of the Mapping 413 Service database. This is important for influencing the selection 414 process of Map-Resolvers, in particular. 416 3.9. MSF-STATUS sub-TLV 418 The format of MSF-STATUS sub-TLV is shown in Figure 10 419 1 2 3 420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = 9 | Length=4 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Status | Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 The current Status values are defined: 428 0: Enabled 429 1: Disabled 431 Figure 10: MSF-STATUS sub-TLV 433 The presence of this sub-TLV indicates the status of Mapping Service 434 Function. 436 The presence of this sub-TLV is particularly useful to indicate that 437 a given instance is disabled. 439 4. Mapping Service Reachability Information 441 This document assumes that Mapping Service Reachability information 442 can be injected into OSPF by a router that embeds a Mapping Service 443 Function instance, or which has been instructed (by means of specific 444 configuration tasks, for example) to advertise such information on 445 behalf of a third party Mapping Service Function. 447 The mechanism defined in this document may be used to advertise and 448 learn Mapping Service Functions that are available in the same 449 administrative domain than xTRs. Also, it can be used to dynamically 450 advertise related reachability information that is learned using 451 other means when the Mapping Service Functions and xTRs do not belong 452 to the same administrative entity. 454 Some of the information carried in the LMSFD TLV may be automatically 455 set by an OSPF speaker while other may be explicitly configured. 457 5. OSPF Operation 459 The LMSFD TLV is advertised within OSPFv2 or OSPFv3 Router 460 Information LSAs [RFC7770]. 462 A change in the operational status of a Mapping Service Function 463 instance (e.g., enabled, disabled) MUST trigger the generation of a 464 Router Information LSA that carries the LMSFD TLV with the updated 465 information. 467 The flooding scope is defined by the Opaque LSA type for OSPFv2 468 [RFC5250], and by the S1/S2 bits for OSPFv3 [RFC5340]. 470 6. Security Considerations 472 The extensions defined in this document do not introduce any 473 additional security threats than those already documented in the 474 current OSPF protocol specifications. 476 OSPF does not support any encryption mechanism for protecting the 477 integrity of Mapping Service Function discovery information. Means 478 such as [RFC2154] may be enabled. 480 7. IANA Considerations 482 This document requests IANA to assign a Router Information TLV type 483 for the LISP Mapping Service Discovery Function (LMSFD) TLV. 485 8. Acknowledgments 487 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 488 009-X. 490 Thanks to Liu Xiang for the comments. 492 9. References 494 9.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 502 DOI 10.17487/RFC2328, April 1998, 503 . 505 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 506 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 507 2003, . 509 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 510 (TE) Extensions to OSPF Version 2", RFC 3630, 511 DOI 10.17487/RFC3630, September 2003, 512 . 514 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 515 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 516 July 2008, . 518 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 519 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 520 . 522 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 523 Locator/ID Separation Protocol (LISP)", RFC 6830, 524 DOI 10.17487/RFC6830, January 2013, 525 . 527 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 528 Protocol (LISP) Map-Server Interface", RFC 6833, 529 DOI 10.17487/RFC6833, January 2013, 530 . 532 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 533 S. Shaffer, "Extensions to OSPF for Advertising Optional 534 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 535 February 2016, . 537 9.2. Informative References 539 [I-D.boucadair-lisp-bulk] 540 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 541 Retrieval", draft-boucadair-lisp-bulk-03 (work in 542 progress), July 2016. 544 [I-D.boucadair-lisp-subscribe] 545 Boucadair, M. and C. Jacquenet, "LISP Subscription", 546 draft-boucadair-lisp-subscribe-03 (work in progress), July 547 2016. 549 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 550 Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June 551 1997, . 553 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 554 Pascual, J., and D. Lewis, "Locator/Identifier Separation 555 Protocol (LISP) Network Element Deployment 556 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 557 2014, . 559 Authors' Addresses 561 Mohamed Boucadair 562 Orange 563 Rennes 35000 564 France 566 Email: mohamed.boucadair@orange.com 568 Christian Jacquenet 569 Orange 570 Rennes 35000 571 France 573 Email: christian.jacquenet@orange.com