idnits 2.17.00 (12 Aug 2021) /tmp/idnits21616/draft-wu-pce-dns-pce-discovery-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5088], [RFC5089]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2013) is 3242 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) == Unused Reference: 'ALTO' is defined on line 418, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4641 (Obsoleted by RFC 6781) ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6805 == Outdated reference: draft-ietf-alto-server-discovery has been published as RFC 7286 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track July 5, 2013 5 Expires: January 6, 2014 7 Path Computation Element (PCE) Discovery using DNS 8 draft-wu-pce-dns-pce-discovery-00 10 Abstract 12 Discovery of the (Path Computation Element (PCE) within an IGP area 13 or domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. 14 However, in some deployment scenarios PCEs may not wish, or be able, 15 to participate within the IGP process. Therefore it would be 16 beneficial for the Path Computation Client (PCC) to discover PCEs via 17 an alternative mechanism to those proposed in [RFC5088] and 18 [RFC5089]. 20 This document specifies the requirements, use cases, procedures and 21 extensions to support DNS for PCE discovery. 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 January 6, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 4 60 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Load Sharing of Path Computation Requests . . . . . . . . 5 62 3.2. Network Address Translation Gateway . . . . . . . . . . . 5 63 3.3. Multiple-Provider Domains . . . . . . . . . . . . . . . . 5 64 4. Discovering a Path Computation Element . . . . . . . . . . . . 6 65 4.1. Determining the PCE Service and transport protocol . . . . 7 66 4.2. Determining the IP Address of the PCE . . . . . . . . . . 7 67 4.3. Determining path computation scope,the PCE domains and 68 Neighbor PCE domains . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The Path Computation Element Communication Protocol (PCEP) is a 79 transaction-based protocol carried over TCP. In order to be able to 80 direct path computation requests to the Path Computation Element 81 (PCE), a Path Computation Client (PCC) needs to know the location and 82 capability of a PCE. 84 In a network where an IGP is used and where the PCE participates in 85 the IGP, discovery mechanisms exist for PCC to learn the identify and 86 capability of each PCE. [RFC5088] defines a PCE Discovery (PCED) TLV 87 carried in an OSPF Router LSA. Similarly, [RFC5089] defines the PCED 88 sub-TLV for use in PCE Discovery using IS-IS. 90 However in certain scenarios not all PCEs will participate in the IGP 91 instance, section 3 (Motivation) outlines a number of use cases. In 92 these cases, current PCE Discovery mechanisms are therefore not 93 appropriate and another PCE announcement and discovery function would 94 be required. 96 1.1. Requirements 98 As described in [RFC4674], the PCE Discovery information should at 99 least be composed of: 101 o The PCE location: an IPv4 and/or IPv6 address that is used to 102 reach the PCE. It is RECOMMENDED to use an address that is always 103 reachable if there is any connectivity to the PCE; 105 o The PCE path computation scope (i.e., intra-layer, inter-area, 106 inter-AS, or inter-layer); 108 o The set of one or more PCE-Domain(s) into which the PCE has 109 visibility and for which the PCE can compute paths; 111 o The set of zero, one, or more neighbor PCE-Domain(s) toward which 112 the PCE can compute paths; 114 that allows PCCs to select appropriate PCEs: 116 This document specifies an extension to DNS for the above PCE 117 information discovery, which is complimentary to IS-IS extension and 118 OSPF extension that describe the support of PCE discovery. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC2119 [RFC2119]. 126 3. Motivation 128 This section discusses in more detail the motivation and use cases 129 for an alternative DNS based PCE discovery mechanism. 131 3.1. Load Sharing of Path Computation Requests 133 Inherent DNS based load balancing may be used for inbound load 134 balancing and implemented at the application level in both servers 135 and clients. Multiple host IP addresses are configured in DNS for a 136 single host server name. Also DNS is capable of automatically 137 detecting and reacting to errors. These allow you to provide load 138 balancing across two separate Systems and facilitate PCE system 139 failover and recovery. 141 3.2. Network Address Translation Gateway 143 Network address translation breaks end-to-end connectivity. The 144 internal network devices communicate with hosts on the external 145 network by changing the source address of outgoing requests to that 146 of the NAT device and relaying replies back to the originating 147 device. This poses a problem for PCEs that is behind the NAT 148 devices, as PCE information carried by PCE that is behind NAT devices 149 in the outgoing IGP advertisement doesn't require substitution or 150 special traversal techniques for NAT traversal and can not be used by 151 PCC that is on the external network to reach the PCE. 153 3.3. Multiple-Provider Domains 155 In the case of multiple ASes within different service provider 156 networks, the H-PCE [RFC6805] architecture does not require 157 disclosure of internals of a child domain to the parent PCE. It may 158 be necessary for a third party to manage the parent PCEs according to 159 commercial and policy agreements from each of the participating 160 service providers. 162 [RFC6805] specifies that a child PCE must be configured with the 163 address of its parent PCE in order for it to interact with its parent 164 PCE. However handling changes in parent PCE identities and coping 165 with failure events would be an issue for a configured system. 167 There is no scope for parent PCEs to advertise their presence, 168 however there is potential for directory systems (such as DNS 169 [RFC4848] as used in the ALTO discovery function [I-D.ietf-alto- 170 server-discovery]). 172 4. Discovering a Path Computation Element 174 The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to 175 implement lazy binding of strings to data, in order to support 176 dynamically configured delegation systems. The DDDS functions by 177 mapping some unique string to data stored within a DDDS database by 178 iteratively applying string transformation rules until a terminal 179 condition is reached. When DDDS uses DNS as a distributed database 180 of rules, these rules are encoded using the Naming Authority Pointer 181 (NAPTR) Resource Record (RR). One of these rules is the First Well 182 Known Rule, which says where the process starts. 184 In current specifications, the First Well Known Rule in a DDDS 185 application [RFC3403] is assumed to be fixed, i.e., the domain in the 186 tree where the lookups are to be routed to, is known. This document 187 proposes the input to the First Well Known Rule to be dynamic, based 188 on the search path the resolver discovers or is configured to use. 190 The search path of the resolver can either be pre-configured, or 191 discovered using DHCP. 193 When the PCC needs to discover PCEs in the domain into which the PCC 194 has visibility (e.g.,local domain), the input to the First Well Known 195 Rule MUST be the domain the PCC knows, which is assumed to be pre- 196 configured in the PCC or discovered using DHCP. 198 When the PCC needs to discover PCE in the other domain (e.g., Parent 199 PCE in the parent domain)into which the PCC has no visibility, it 200 SHOULD know the domain name of that domain and use DHCP to discover 201 IP address of the PCE in that domain that provides path computation 202 service along with some PCE location information useful to a PCC for 203 PCE selection, and contact it directly. In some instances, the 204 discovery may result in a per protocol/application list of domain 205 names that are then used as starting points for the subsequent NAPTR 206 lookups. If neither the IP address or PCE location information can 207 be discovered with the above procedure, the PCC MAY request a domain 208 search list, as described in [RFC3397] and [RFC3646], and use it as 209 input to the DDDS application. 211 When the PCC does not find valid domain names using the procedures 212 above, it MUST stop the attempt to discover any PCE. 214 The dynamic rule described above SHOULD NOT be used for discovering 215 services other than Path computation services described in this 216 document, unless stated otherwise by a future specification. 218 The procedures defined here result in an IP address, PCE domain, 219 neighboring PCE domain and PCE Computation Scope where the PCC can 220 contact the PCC that hosts the service the PCC is looking for. 222 4.1. Determining the PCE Service and transport protocol 224 The PCC should know the service identifier for the Path Computation 225 Discovery service. The service identifier for the Path Computation 226 Discovery service is defined as "PCED", The PCE supporting "PCED" 227 service MUST support only TCP as transport, as described in 228 [RFC5440]. 230 The services relevant for the task of transport protocol selection 231 are those with NAPTR service fields with values "ID+M2X", where ID is 232 the service identifier defined in the previous section, and X is a 233 letter that corresponds to a transport protocol supported by the 234 domain. This specification only defines M2T for TCP. This document 235 also establishes an IANA registry for mappings of NAPTR service name 236 to transport protocol. 238 These NAPTR [RFC3403] records provide a mapping from a domain to the 239 SRV [RFC2782] record for contacting a PCE with the specific transport 240 protocol in the NAPTR services field. The resource record MUST 241 contain an empty regular expression and a replacement value, which 242 indicates the domain name where the SRV record for that particular 243 transport protocol can be found. As per [RFC3403], the client 244 discards any records whose services fields are not applicable. 246 The PCC MUST discard any service fields that identify a resolution 247 service whose value is not "M2T", for values of T that indicate TCP 248 transport protocols supported by the client. The NAPTR processing as 249 described in RFC 3403 will result in the discovery of the most 250 preferred transport protocol of the PCE that is supported by the 251 client, as well as an SRV record for the PCE. 253 4.2. Determining the IP Address of the PCE 255 As an example, consider a client that wishes to find "PCED" service 256 in the example.com domain. The client performs a NAPTR query for 257 that domain, and the following NAPTR records are returned: 259 Order Pref Flags Service Regexp Replacement 260 IN NAPTR 50 50 "s" "PCED" "" 261 _PCED._tcp.example.com 262 IN NAPTR 90 50 "s" "PCED+M2T" "" 263 _PCED._udp.example.com 265 This indicates that the domain does have a PCE providing Path 266 Computation services over TCP, in that order of preference. Since 267 the client only supports TCP, TCP will be used, targeted to a host 268 determined by an SRV lookup of _PCED._tcp.example.com. That lookup 269 would return: 271 ;; Priority Weight Port Target 272 IN SRV 0 1 XXXX server1.example.com 273 IN SRV 0 2 XXXX server2.example.com 275 where XXXX represents the port number at which the service is 276 reachable. 278 Note that the regexp field in the NAPTR example above is empty. The 279 regexp field MUST NOT be used when discovering path computation 280 services, as its usage can be complex and error prone. Also, the 281 discovery of the path computation service does not require the 282 flexibility provided by this field over a static target present in 283 the TARGET field. 285 If the client is already configured with the information about which 286 transport protocol is used for a path computation service in a 287 particular domain, it can directly perform an SRV query for that 288 specific transport using the service identifier of the path 289 computation Service. For example, if the client knows that it should 290 be using TCP for path computation service, it can perform a SRV query 291 directly for_PCED._tcp.example.com. 293 Once the server providing the desired service and the transport 294 protocol has been determined, the next step is to determine the IP 295 address. 297 According to the specification of SRV RRs in [RFC2782], the TARGET 298 field is a fully qualified domain name (FQDN) that MUST have one or 299 more address records; the FQDN must not be an alias, i.e., there MUST 300 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 301 already has reported a sufficient number of these address records in 302 the Additional Data section of the DNS response (as recommended by 303 [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) 304 of the domain name, as appropriate. The result will be a list of IP 305 addresses, each of which can be contacted using the transport 306 protocol determined previously. 308 4.3. Determining path computation scope,the PCE domains and Neighbor 309 PCE domains 311 DNS servers MAY add new RRsets to the additional information section 312 that are relevant to the answer and have the same authenticity as the 313 data (the IP Address of the PCE)in the answer section. RRsets 314 include path computation scope, the PCE domains and Neighbor PCE 315 domains associated with. path information Applications on the PCC MAY 316 inspect those Additional Information section and be capable of 317 handling responses from nameservers that never fill in the Additional 318 Information part of a response. 320 5. IANA Considerations 322 The usage of NAPTR records described here requires well-known values 323 for the service fields for the transport supported by Path 324 Computation Services. The table of mappings from service field 325 values to transport protocols is to be maintained by IANA. 327 The registration in the RFC MUST include the following information: 329 Service Field: The service field being registered. 331 Protocol: The specific transport protocol associated with that 332 service field. This MUST include the name and acronym for the 333 protocol, along with reference to a document that describes the 334 transport protocol. 336 Name and Contact Information: The name, address, email address, 337 and telephone number for the person performing the registration. 339 The following values have been placed into the registry: 341 Service Fields Protocol 342 PCED+M2T TCP 344 New Service Fields are to be added via Standards Action as defined in 345 [RFC5226]. 347 IANA is also requested to register PCED as service name in the 348 Protocol and Service Names registry. 350 6. Security Considerations 352 It is believed that this proposed DNS extension introduces no new 353 security considerations (i.e., A list of known threats to services 354 using DNS) beyond those described in [RFC3833]. For most of those 355 identified threats, the DNS Security Extensions [RFC4033] does 356 provide protection. It is therefore recommended to consider the 357 usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational 358 Practices [RFC4641] when deploying Path Computation Services. 360 In deployments where DNSSEC usage is not feasible, measures should be 361 taken to protect against forged DNS responses and cache poisoning as 362 much as possible. Efforts in this direction are documented in 363 [RFC5452]. 365 Where inputs to the procedure described in this document are fed via 366 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 367 inability to authenticate DHCP discovery results may lead to the Path 368 Computation service results also being incorrect, even if the DNS 369 process was secured. 371 7. References 373 7.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", March 1997. 378 [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of 379 services (DNS SRV)", RFC 2782, February 2000. 381 [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) 382 Domain Search Option", RFC 3397, November 2002. 384 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 385 Part Three: The Domain Name System (DNS) Database", 386 RFC 3403, October 2002. 388 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 389 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 390 December 2003. 392 [RFC4033] Arends, R., "DNS Security Introduction and Requirements", 393 RFC 4033, March 2005. 395 [RFC4641] Kolkman, O., "DNSSEC Operational Practices", RFC 4641, 396 September 2006. 398 [RFC4674] Droms, R., "Requirements for Path Computation Element 399 (PCE) Discovery", RFC 4674, December 2003. 401 [RFC4848] Daigle, D., "Domain-Based Application Service Location 402 Using URIs and the Dynamic Delegation Discovery Service 403 (DDDS)", RFC 4848, April 2007. 405 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 406 Section in RFCs", RFC 5226, May 2008. 408 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 409 Communication Protocol (PCEP)", RFC 5440, April 2007. 411 [RFC6805] King, D. and A. Farrel, "The Application of the Path 412 Computation Element Architecture to the Determination of a 413 Sequence of Domains in MPLS and GMPLS", RFC 6805, 414 November 2012. 416 7.2. Informative References 418 [ALTO] Kiesel, S., "ALTO Server Discovery", 419 ID draft-ietf-alto-server-discovery-08, March 2013. 421 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 422 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 424 [RFC3833] Atkins, D., "Threat Analysis of the Domain Name System 425 (DNS)", RFC 3833, August 2004. 427 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 428 Computation Element (PCE) Discovery", RFC 5088, 429 January 2008. 431 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 432 Computation Element (PCE) Discovery", RFC 5089, 433 January 2008. 435 [RFC5452] Hubert, A., "Measures for Making DNS More Resilient 436 against Forged Answers", RFC 5452, January 2009. 438 Author's Address 440 Qin Wu 441 Huawei 442 101 Software Avenue, Yuhua District 443 Nanjing, Jiangsu 210012 444 China 446 Email: sunseawq@huawei.com