< draft-wu-pce-dns-pce-discovery-01.txt   draft-wu-pce-dns-pce-discovery-02.txt >
PCE Working Group Q. Wu PCE Working Group Q. Wu
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: January 16, 2014 July 15, 2013 Expires: February 13, 2014 D. King
Old Dog Consulting
D. Lopez
Telefonica I+D
August 12, 2013
Path Computation Element (PCE) Discovery using Domain Name System(DNS) Path Computation Element (PCE) Discovery using Domain Name System(DNS)
draft-wu-pce-dns-pce-discovery-01 draft-wu-pce-dns-pce-discovery-02
Abstract Abstract
Discovery of the Path Computation Element (PCE) within an IGP area or Discovery of the Path Computation Element (PCE) within an IGP area or
domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089].
However, in some deployment scenarios PCEs may not wish, or be able, However, in some deployment scenarios PCEs may not wish, or be able,
to participate within the IGP process,therefore it would be to participate within the IGP process, therefore it would be
beneficial for the Path Computation Client (PCC) (or other PCEs) to beneficial for the Path Computation Client (PCC) (or other PCEs) to
discover PCEs via an alternative mechanism to those proposed in discover PCEs via an alternative mechanism to those proposed in
[RFC5088] and [RFC5089]. [RFC5088] and [RFC5089].
This document specifies the requirements, use cases, procedures and This document specifies the requirements, use cases, procedures and
extensions to support discovery via DNS for PCE. extensions to support discovery via DNS for PCE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on February 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3.1. Load Sharing of Path Computation Requests . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Network Address Translation Gateway . . . . . . . . . . . 5 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . . 6
3.3. Multiple-Provider Domains . . . . . . . . . . . . . . . . 5 3.2. Query-Response v/s Advertisement . . . . . . . . . . . . . 7
3.4. Multiple PCE Servers . . . . . . . . . . . . . . . . . . . 6 3.3. Network Address Translation Gateway . . . . . . . . . . . 7
3.5. End to End Path Computation . . . . . . . . . . . . . . . 6 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Discovering a Path Computation Element . . . . . . . . . . . . 7 4.1. Load Sharing of Path Computation Requests . . . . . . . . 8
4.1. Determining the PCE Service and transport protocol . . . . 8 5. Discovering a Path Computation Element . . . . . . . . . . . . 9
4.2. Determining the IP Address of the PCE . . . . . . . . . . 8 5.1. Determining the PCE Service and transport protocol . . . . 10
4.3. Determining path computation scope,the PCE domains and 5.2. Determining the IP Address of the PCE . . . . . . . . . . 10
Neighbor PCE domains . . . . . . . . . . . . . . . . . . . 9 5.3. Determining path computation scope,capability,the PCE
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 domains and Neighbor PCE domains . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.4. Relationship between PCE-Domain and DNS Domain-Name . . . 12
7. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Path Computation Element Communication Protocol (PCEP) is a The Path Computation Element Communication Protocol (PCEP) is a
transaction-based protocol carried over TCP[RFC4655]. In order to be transaction-based protocol carried over TCP [RFC4655]. In order to
able to direct path computation requests to the Path Computation be able to direct path computation requests to the Path Computation
Element (PCE), a Path Computation Client (PCC) (or other PCEs) needs Element (PCE), a Path Computation Client (PCC) (or other PCEs) needs
to know the location and capability of a PCE. to know the location and capability of a PCE.
In a network where an IGP is used and where the PCE participates in In a network where an IGP is used and where the PCE participates in
the IGP, discovery mechanisms exist for PCC (or PCE) to learn the the IGP, discovery mechanisms exist for PCC (or PCE) to learn the
identity and capability of each PCE. [RFC5088] defines a PCE identity and capability of each PCE. [RFC5088] defines a PCE
Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly,
[RFC5089] defines the PCED sub-TLV for use in PCE Discovery using [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using
IS-IS. Scope of the advertisement is limited to IGP area/level or IS-IS. Scope of the advertisement is limited to IGP area/level or
Autonomous System (AS). Autonomous System (AS).
However in certain scenarios not all PCEs will participate in the IGP However in certain scenarios not all PCEs will participate in the IGP
instance, section 3 (Motivation) outlines a number of use cases. In instance, section 3 (Motivation) outlines a number of use cases. In
these cases, current PCE Discovery mechanisms are therefore not these cases, current PCE Discovery mechanisms are therefore not
appropriate and another PCE discovery function would be required. appropriate and another PCE discovery function would be required.
1.1. Requirements This document describes PCE discovery via DNS. The mechanism with
which DNS comes to know about the PCE and its capability is out of
scope of this document.
1.1. Terminology
The following terminology is used in this document.
Domain: As per [RFC4655], any collection of network elements within
a common sphere of address management or path computational
responsibility. Examples of domains include Interior Gateway
Protocol (IGP) areas and Autonomous Systems (ASs).
Domain-Name: TBD.
1.2. Requirements
As described in [RFC4674], the PCE Discovery information should at As described in [RFC4674], the PCE Discovery information should at
least be composed of: least be composed of:
o The PCE location: an IPv4 and/or IPv6 address that is used to o The PCE location: an IPv4 and/or IPv6 address that is used to
reach the PCE. It is RECOMMENDED to use an address that is always reach the PCE. It is RECOMMENDED to use an address that is always
reachable if there is any connectivity to the PCE; reachable if there is any connectivity to the PCE;
o The PCE path computation scope (i.e., intra-layer, inter-area, o The PCE path computation scope (i.e., intra-layer, inter-area,
inter-AS, or inter-layer); inter-AS, or inter-layer);
skipping to change at page 5, line 10 skipping to change at page 6, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Motivation 3. Motivation
This section discusses in more detail the motivation and use cases This section discusses in more detail the motivation and use cases
for an alternative DNS based PCE discovery mechanism. for an alternative DNS based PCE discovery mechanism.
3.1. Load Sharing of Path Computation Requests 3.1. Outside the Routing Domain
Multiple PCE servers can be present in a single network domain for When the PCE is a router participating in the Interior Gateway
redundancy. However load balance decision is made by PCC,it doesn't Protocol (IGP), or even a server participating passively in the IGP,
enable real load balance across the PCE servers if PCC still tries with all PCEP speakers in the same routing domain, a simple and
PCE one by one and PCE doesn't indicate the load status to the PCC. efficient way to announce PCEs consists of using IGP flooding.
Inherent DNS based load balancing may be used for inbound load But the existing mechanism does not work in following situations:
balancing and implemented at the application level in both servers
and clients. Multiple host IP addresses are configured in DNS for a
single host server name. Also DNS is query-response based mechanism
and capable of automatically detecting and reacting to errors. These
allow you to provide load balancing across two separate Systems and
facilitate PCE system failover and recovery.
Comparing with advertisement based PCE discovery Inter-AS: Per domain path computation mechanism [RFC5152] or
[RFC5088][RFC5089],it can mitigate flooding issue (see section 3.2 of Backward recursive path computation (BRPC) [RFC5441] MAY be used
[RFC5088])and avoid unwanted traffic and reduce a large amount of by cooperating PCEs to compute inter-domain path. In which case
unnecessary advertisement, especially when PCE information needs these cooperating PCEs should be known to other PCEs. In case of
frequent changes. inter-AS where the PCEs do not participate in a common IGP, the
existing IGP discovery mechanism cannot be used to discover
inter-AS PCE.
3.2. Network Address Translation Gateway Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require
disclosure of internals of a child domain to the parent PCE. It
may be necessary for a third party to manage the parent PCEs
according to commercial and policy agreements from each of the
participating service providers [PCE-QUESTION]. [RFC6805]
specifies that a child PCE must be configured with the address of
its parent PCE in order for it to interact with its parent PCE.
However handling changes in parent PCE identities and coping with
failure events would be an issue for a configured system. There
is no scope for parent PCEs to advertise their presence to child
PCEs when they are not a part of the same routing domain.
PCEP uses TCP as the transport [RFC5440]. To secure TCP connection BGP: [I.D.draft-ietf-idr-ls-distribution] describes a mechanism by
that underly PCEP sessions, TLS can be used besides using TCP-MD5. which links state and traffic engineering information can be
When NAT gateway is in place, a TCP or TCP/TLS connection can be collected from networks and shared with external components using
opened by ICE for the purpose of connectivity checks. However the the BGP routing protocol. An external PCE MAY use this mechanism
TCP connection cannot be established in cases where one of the agents to populate its TED and not take part in the same IGP routing
is behind a NAT with connection-dependent filtering properties domain.
[RFC5382]. Therefore IGP discovery is limited within an IGP domain
and cannot be used in this case.
3.3. Multiple-Provider Domains NMS/OSS: PCE server MAY gain the knowledge of Topology information
from some management system (e.g.,NMS/OSS) and not take part in
the same routing domain. Also note that in some case PCC may not
be a router and instead be a management system like NMS and may
not be able to discover PCE via IGP discovery.
Backward recursive path computation (BRPC) [RFC5441] MAY be used by 3.2. Query-Response v/s Advertisement
cooperating PCEs to compute inter-domain path. In which case these
cooperating PCEs should known to other PCEs. In case of inter-AS
where the PCE do not participate in a common IGP, the existing IGP
discovery mechanism cannot be used to discover inter-AS PCE.
Also in the case of multiple ASes within different service provider Advertisement based IGP PCE discovery [RFC5088] and [RFC5089] floods
networks, the H-PCE [RFC6805] architecture does not require the PCE information to an area, a subset of areas or to a full
disclosure of internals of a child domain to the parent PCE. It may routing domain. By the very nature of flooding and advertisements it
be necessary for a third party to manage the parent PCEs according to generates unwanted traffic and may lead to unnecessary advertisement,
commercial and policy agreements from each of the participating especially when PCE information needs frequent changes.
service providers.
[RFC6805] specifies that a child PCE must be configured with the DNS is a query-response based mechanism, a client (say PCC) can use
address of its parent PCE in order for it to interact with its parent DNS to discover a PCE only when it needs it and does not require any
PCE. However handling changes in parent PCE identities and coping other node in the network to be involved.
with failure events would be an issue for a configured system.
There is no scope for parent PCEs to advertise their presence, Incase of Intermittent PCEP session, where PCEP sessions are
however there is potential for directory systems (such as DNS systematically open and closed for each PCEP request, a DNS based
[RFC4848] as used in the ALTO discovery function [I-D.ietf-alto- query-response mechanism is more suitable. One may utilize DNS based
server-discovery]). load-balancing and recovery functions.
3.4. Multiple PCE Servers 3.3. Network Address Translation Gateway
In some cases, each network domain may have multiple PCE server, only PCEP uses TCP as the transport [RFC5440]. To secure TCP connection
one main PCE sever is responsible for Establish topology database by that underlay PCEP sessions, TLS can be used besides using TCP-MD5
participating in OSPF/ISIS routing protocol, the other PCE server [RFC2385] and TCP-AUTH [RFC5295]. When PCC and PCE support TCP-MD5
gains knowledge of Topology information either from TED maintained by or TCP-AUTH while NAT does not, TCP connection establishment fails.
the main PCE server or some management system(e.g.,NMS/OSS). In such When NAT gateway is in presence, a TCP or TCP/TLS connection can be
cases, it is desirable to use DNS based mechanism to discover PCE. opened by Interactive Connectivity Establishment (ICE) [RFC5245] for
the purpose of connectivity checks. However the TCP connection
cannot be established in cases where one of the peers is behind a NAT
with connection-dependent filtering properties [RFC5382]. Therefore
IGP discovery is limited within an IGP domain and cannot be used in
this case.
3.5. End to End Path Computation 4. Other Considerations
To compute end to end paths across domains, PCE has the following 4.1. Load Sharing of Path Computation Requests
limitations:
o Within a single area, the PCE can not offers enhanced Multiple PCE servers can be present in a single network domain for
computational power for end to end path computation,e.g., redundancy. DNS supports inherent load balancing where multiple PCEs
coordination of computation across the whole area. (with different IP addresses) are known in DNS for a single PCE
server name and are hidden from the PCC.
o A single router participating in IGP area lacks visibility of In an IGP advertisement based PCE discovery, one learns of all the
complete topology with its own TED. PCEs and it is the job of the PCC to do load-balancing.
Per domain path computation mechanism[RFC5152]can be used to compute A DNS based load-balancing mechanism works well in case of
end to end path, however it may lead to sub-optimal paths or result Intermittent PCEP sessions and request are load-balanced among PCEs
in no end to end path to be found when the PCE only has visibility similar to HTTP request without any complexity at the client.
into the IGP area it serves. This issue can be resolved when one
powerful PCE is responsible for multiple areas,i.e., PCE sits in one
area it serves and also can get access to topology information
provided by PCE server in other IGP area using BGP. In such case, it
will be desirable to use DNS based mechanism to discover those PCE
that has visibility to multiple areas.
4. Discovering a Path Computation Element 5. Discovering a Path Computation Element
The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to
implement lazy binding of strings to data, in order to support implement lazy binding of strings to data, in order to support
dynamically configured delegation systems. The DDDS functions by dynamically configured delegation systems. The DDDS functions by
mapping some unique string to data stored within a DDDS database by mapping some unique string to data stored within a DDDS database by
iteratively applying string transformation rules until a terminal iteratively applying string transformation rules until a terminal
condition is reached. When DDDS uses DNS as a distributed database condition is reached. When DDDS uses DNS as a distributed database
of rules, these rules are encoded using the Naming Authority Pointer of rules, these rules are encoded using the Naming Authority Pointer
(NAPTR) Resource Record (RR). One of these rules is the First Well (NAPTR) Resource Record (RR). One of these rules is the First Well
Known Rule, which says where the process starts. Known Rule, which says where the process starts.
skipping to change at page 7, line 29 skipping to change at page 9, line 29
tree where the lookups are to be routed to, is known. This document tree where the lookups are to be routed to, is known. This document
proposes the input to the First Well Known Rule to be dynamic, based proposes the input to the First Well Known Rule to be dynamic, based
on the search path the resolver discovers or is configured to use. on the search path the resolver discovers or is configured to use.
The search path of the resolver can either be pre-configured, or The search path of the resolver can either be pre-configured, or
discovered using DHCP. discovered using DHCP.
When the PCC or other PCEs needs to discover PCEs in the domain into When the PCC or other PCEs needs to discover PCEs in the domain into
which the PCEP speaker has visibility (e.g.,local domain), the input which the PCEP speaker has visibility (e.g.,local domain), the input
to the First Well Known Rule MUST be the domain the PCC knows, which to the First Well Known Rule MUST be the domain the PCC knows, which
is assumed to be pre- configured in the PCC or discovered using DHCP. is assumed to be pre-configured in the PCC or discovered using DHCP.
When the PCC needs to discover PCE in the other domain (e.g., AS, When the PCC needs to discover PCE in the other domain (e.g., AS,
Parent PCE in the parent domain)into which the PCC has no visibility, Parent PCE in the parent domain)into which the PCC has no visibility,
it SHOULD know the domain name of that domain and use DHCP to it SHOULD know the domain name of that domain and use DHCP to
discover IP address of the PCE in that domain that provides path discover IP address of the PCE in that domain that provides path
computation service along with some PCE location information useful computation service along with some PCE location information useful
to a PCC for PCE selection, and contact it directly. In some to a PCC for PCE selection, and contact it directly. In some
instances, the discovery may result in a per protocol/application instances, the discovery may result in a per protocol/application
list of domain names that are then used as starting points for the list of domain names that are then used as starting points for the
subsequent NAPTR lookups. If neither the IP address or PCE location subsequent NAPTR lookups. If neither the IP address nor other PCE
information can be discovered with the above procedure, the PCC MAY location information can be discovered with the above procedure, the
request a domain search list, as described in [RFC3397] and PCC MAY request a domain search list, as described in [RFC3397] and
[RFC3646], and use it as input to the DDDS application. [RFC3646], and use it as input to the DDDS application.
When the PCC does not find valid domain names using the procedures When the PCC does not find valid domain names using the procedures
above, it MUST stop the attempt to discover any PCE. above, it MUST stop the attempt to discover any PCE.
The dynamic rule described above SHOULD NOT be used for discovering The dynamic rule described above SHOULD NOT be used for discovering
services other than Path computation services described in this services other than Path computation services described in this
document, unless stated otherwise by a future specification. document, unless stated otherwise by a future specification.
The procedures defined here result in an IP address, PCE domain, The procedures defined here result in an IP address, PCE domain,
neighboring PCE domain and PCE Computation Scope where the PCC can neighboring PCE domain and PCE Computation Scope where the PCC can
contact the PCE that hosts the service the PCC is looking for. contact the PCE that hosts the service the PCC is looking for.
4.1. Determining the PCE Service and transport protocol 5.1. Determining the PCE Service and transport protocol
The PCC should know the service identifier for the Path Computation The PCC should know the service identifier for the Path Computation
Discovery service. The service identifier for the Path Computation Discovery service. The service identifier for the Path Computation
Discovery service is defined as "PCED", The PCE supporting "PCED" Discovery service is defined as "PCED", The PCE supporting "PCED"
service MUST support only TCP as transport, as described in service MUST support only TCP as transport, as described in
[RFC5440]. [RFC5440].
The services relevant for the task of transport protocol selection The services relevant for the task of transport protocol selection
are those with NAPTR service fields with values "ID+M2X", where ID is are those with NAPTR service fields with values "ID+M2X", where ID is
the service identifier defined in the previous section, and X is a the service identifier defined in the previous section, and X is a
skipping to change at page 8, line 37 skipping to change at page 10, line 37
transport protocol can be found. As per [RFC3403], the client transport protocol can be found. As per [RFC3403], the client
discards any records whose services fields are not applicable. discards any records whose services fields are not applicable.
The PCC MUST discard any service fields that identify a resolution The PCC MUST discard any service fields that identify a resolution
service whose value is not "M2T", for values of T that indicate TCP service whose value is not "M2T", for values of T that indicate TCP
transport protocols supported by the client. The NAPTR processing as transport protocols supported by the client. The NAPTR processing as
described in RFC 3403 will result in the discovery of the most described in RFC 3403 will result in the discovery of the most
preferred transport protocol of the PCE that is supported by the preferred transport protocol of the PCE that is supported by the
client, as well as an SRV record for the PCE. client, as well as an SRV record for the PCE.
4.2. Determining the IP Address of the PCE 5.2. Determining the IP Address of the PCE
As an example, consider a client that wishes to find "PCED" service As an example, consider a client that wishes to find PCED service in
in the example.com domain. The client performs a NAPTR query for the example.com domain. The client performs a NAPTR query for that
that domain, and the following NAPTR records are returned: domain, and the following NAPTR records are returned:
Order Pref Flags Service Regexp Replacement Order Pref Flags Service Regexp Replacement
IN NAPTR 50 50 "s" "PCED" "" IN NAPTR 50 50 "s" "PCED" ""
_PCED._tcp.example.com _PCED._tcp.example.com
IN NAPTR 90 50 "s" "PCED+M2T" "" IN NAPTR 90 50 "s" "PCED+M2T" ""
_PCED._tcp.example.com _PCED._tcp.example.com
This indicates that the domain does have a PCE providing Path This indicates that the domain does have a PCE providing Path
Computation services over TCP, in that order of preference. Since Computation services over TCP, in that order of preference. Since
the client only supports TCP, TCP will be used, targeted to a host the client only supports TCP, TCP will be used, targeted to a host
skipping to change at page 9, line 44 skipping to change at page 11, line 44
field is a fully qualified domain name (FQDN) that MUST have one or field is a fully qualified domain name (FQDN) that MUST have one or
more address records; the FQDN must not be an alias, i.e., there MUST more address records; the FQDN must not be an alias, i.e., there MUST
NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query
already has reported a sufficient number of these address records in already has reported a sufficient number of these address records in
the Additional Data section of the DNS response (as recommended by the Additional Data section of the DNS response (as recommended by
[RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s)
of the domain name, as appropriate. The result will be a list of IP of the domain name, as appropriate. The result will be a list of IP
addresses, each of which can be contacted using the transport addresses, each of which can be contacted using the transport
protocol determined previously. protocol determined previously.
4.3. Determining path computation scope,the PCE domains and Neighbor 5.3. Determining path computation scope,capability,the PCE domains and
PCE domains Neighbor PCE domains
DNS servers MAY use DNS TXT record and add new RRsets to the DNS servers MAY use DNS TXT record to give additional information
additional information section that are relevant to the answer and about PCE service and add TXT record to the additional information
have the same authenticity as the data (the IP Address of the PCE)in section that are relevant to the answer and have the same
the answer section. RRsets include path computation scope, the PCE authenticity as the data (Generally this will be made up of A and SRV
domains and Neighbor PCE domains associated with the PCE. the PCC MAY records)in the answer section. The additional information includes
inspect those Additional Information section and be capable of path computation scope, capability, the PCE domains and Neighbor PCE
handling responses from nameservers that never fill in the Additional domains associated with the PCE. the PCC MAY inspect those Additional
Information part of a response. Information section and be capable of handling responses from
nameservers that never fill in the Additional Information part of a
response.
5. IANA Considerations 5.4. Relationship between PCE-Domain and DNS Domain-Name
As per [RFC4655], PCE-Domain is a collection of network elements
within a common sphere of address management or path computational
responsibility. Examples of PCE-domains include Interior Gateway
Protocol (IGP) areas and Autonomous Systems (ASs). The DNS domain-
name should have a mechanism to link the IGP area or AS to the DNS
namespace.
Editors Note - To be discussed further
6. IANA Considerations
The usage of NAPTR records described here requires well-known values The usage of NAPTR records described here requires well-known values
for the service fields for the transport supported by Path for the service fields for the transport supported by Path
Computation Services. The table of mappings from service field Computation Services. The table of mappings from service field
values to transport protocols is to be maintained by IANA. values to transport protocols is to be maintained by IANA.
The registration in the RFC MUST include the following information: The registration in the RFC MUST include the following information:
Service Field: The service field being registered. Service Field: The service field being registered.
skipping to change at page 12, line 5 skipping to change at page 14, line 5
Service Fields Protocol Service Fields Protocol
PCED+M2T TCP PCED+M2T TCP
New Service Fields are to be added via Standards Action as defined in New Service Fields are to be added via Standards Action as defined in
[RFC5226]. [RFC5226].
IANA is also requested to register PCED as service name in the IANA is also requested to register PCED as service name in the
Protocol and Service Names registry. Protocol and Service Names registry.
6. Security Considerations 7. Security Considerations
It is believed that this proposed DNS extension introduces no new It is believed that this proposed DNS extension introduces no new
security considerations (i.e., A list of known threats to services security considerations (i.e., A list of known threats to services
using DNS) beyond those described in [RFC3833]. For most of those using DNS) beyond those described in [RFC3833]. For most of those
identified threats, the DNS Security Extensions [RFC4033] does identified threats, the DNS Security Extensions [RFC4033] does
provide protection. It is therefore recommended to consider the provide protection. It is therefore recommended to consider the
usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational
Practices [RFC4641] when deploying Path Computation Services. Practices [RFC6781] when deploying Path Computation Services.
In deployments where DNSSEC usage is not feasible, measures should be In deployments where DNSSEC usage is not feasible, measures should be
taken to protect against forged DNS responses and cache poisoning as taken to protect against forged DNS responses and cache poisoning as
much as possible. Efforts in this direction are documented in much as possible. Efforts in this direction are documented in
[RFC5452]. [RFC5452].
Where inputs to the procedure described in this document are fed via Where inputs to the procedure described in this document are fed via
DHCP, DHCP vulnerabilities can also cause issues. For instance, the DHCP, DHCP vulnerabilities can also cause issues. For instance, the
inability to authenticate DHCP discovery results may lead to the Path inability to authenticate DHCP discovery results may lead to the Path
Computation service results also being incorrect, even if the DNS Computation service results also being incorrect, even if the DNS
process was secured. process was secured.
7. Acknowledges 8. Acknowledges
The author would like to thank Claire Bi,Ning Kong and Liang Xia for The author would like to thank Claire Bi,Ning Kong, Liang Xia,
their review and comments that help improvement to this document. Stephane Bortzmeyer,Yi Yang, Ted Lemon and Adrian Farrel for their
review and comments that help improvement to this document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of
services (DNS SRV)", RFC 2782, February 2000. services (DNS SRV)", RFC 2782, February 2000.
[RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP)
Domain Search Option", RFC 3397, November 2002. Domain Search Option", RFC 3397, November 2002.
skipping to change at page 14, line 29 skipping to change at page 16, line 29
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002. RFC 3403, October 2002.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC4033] Arends, R., "DNS Security Introduction and Requirements", [RFC4033] Arends, R., "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4641] Kolkman, O., "DNSSEC Operational Practices", RFC 4641, [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
September 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Droms, R., "Requirements for Path Computation Element [RFC4674] Droms, R., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, December 2003. (PCE) Discovery", RFC 4674, December 2003.
[RFC4848] Daigle, D., "Domain-Based Application Service Location [RFC4848] Daigle, D., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 5226, May 2008. Section in RFCs", RFC 5226, May 2008.
[RFC5440] Le Roux, JL., "Path Computation Element (PCE) [RFC5440] Le Roux, JL., "Path Computation Element (PCE)
Communication Protocol (PCEP)", RFC 5440, April 2007. Communication Protocol (PCEP)", RFC 5440, April 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
December 2012.
[RFC6805] King, D. and A. Farrel, "The Application of the Path [RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, Sequence of Domains in MPLS and GMPLS", RFC 6805,
November 2012. November 2012.
8.2. Informative References 9.2. Informative References
[ALTO] Kiesel, S., "ALTO Server Discovery", [ALTO] Kiesel, S., "ALTO Server Discovery",
ID draft-ietf-alto-server-discovery-08, March 2013. ID draft-ietf-alto-server-discovery-08, March 2013.
[BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and
TE Information using BGP",
ID draft-ietf-idr-ls-distribution-03, May 2013.
[PCE-QUESTION]
Farrel, A., "Unanswered Questions in the Path Computation
Element Architecture",
ID http://tools.ietf.org/html/draft-ietf-pce-questions-00,
July 2013.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002. Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3833] Atkins, D., "Threat Analysis of the Domain Name System [RFC3833] Atkins, D., "Threat Analysis of the Domain Name System
(DNS)", RFC 3833, August 2004. (DNS)", RFC 3833, August 2004.
[RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path
Computation Element (PCE) Discovery", RFC 5088, Computation Element (PCE) Discovery", RFC 5088,
January 2008. January 2008.
[RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path
Computation Element (PCE) Discovery", RFC 5089, Computation Element (PCE) Discovery", RFC 5089,
January 2008. January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5295] Touch, J., "The TCP Authentication Option", RFC 5295,
June 2010.
[RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382, [RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382,
October 2008. October 2008.
[RFC5452] Hubert, A., "Measures for Making DNS More Resilient [RFC5452] Hubert, A., "Measures for Making DNS More Resilient
against Forged Answers", RFC 5452, January 2009. against Forged Answers", RFC 5452, January 2009.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
skipping to change at page 16, line 21 skipping to change at page 18, line 21
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
Email: dhruv.ietf@gmail.com Email: dhruv.dhody@huawei.com
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Diego R. Lopez
Telefonica I+D
Email: diego@tid.es
 End of changes. 47 change blocks. 
129 lines changed or deleted 190 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/