< draft-wu-pce-dns-pce-discovery-06.txt   draft-wu-pce-dns-pce-discovery-07.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: November 10, 2014 D. King Expires: April 27, 2015 D. King
Old Dog Consulting Lancaster University
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
J. Tantsura J. Tantsura
Ericsson Ericsson
May 9, 2014 October 27, 2014
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-06 draft-wu-pce-dns-pce-discovery-07
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
routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. routing domain is possible using OSPF and IS-IS IGP discovery.
However, it has been established that in certain deployment scenarios However, it has been established that in certain deployment scenarios
PCEs may not wish, or be able to participate within the IGP process. PCEs may not wish, or be able to participate within the IGP process.
In those scenarios, it is beneficial for the Path Computation Client In those scenarios, it is beneficial for the Path Computation Client
(PCC) (or other PCE) to discover PCEs via an alternative mechanism to (PCC) (or other PCE) to discover PCEs via an alternative mechanism to
those proposed in [RFC5088] and [RFC5089]. using an IGP discovery.
This document specifies the requirements, use cases, procedures and This document specifies the requirements, use cases, procedures and
extensions to support PCE discovery along with certain relevant extensions to support PCE discovery along with certain relevant
information type and capability discovery via DNS. information type and capability discovery via DNS.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 10, 2014. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Outside the Routing Domain . . . . . . . . . . . . . . . . 6 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . 4
3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . 7 3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 5
3.2.1. Query-Response versus Advertisement . . . . . . . . . 7 3.2.1. Query-Response versus Advertisement . . . . . . . . . 5
3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . . 7 3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . 6
3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 7 3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 6
3.4.1. Handling Changes in PCE Identities . . . . . . . . . . 7 3.4.1. Handling Changes in PCE Identities . . . . . . . . . 6
3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 8 3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 6
3.4.3. Load Sharing of Path Computation Requests . . . . . . 8 3.4.3. Load Sharing of Path Computation Requests . . . . . . 7
4. Extended Naming Authority Pointer ( NAPTR )Service Field 4. Extended Naming Authority Pointer ( NAPTR )Service Field
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IETF Standards Track PCE Applications . . . . . . . . . . 10 4.1. IETF Standards Track PCE Applications . . . . . . . . . . 8
5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
6. Discovering a Path Computation Element . . . . . . . . . . . . 12 6. Discovering a Path Computation Element . . . . . . . . . . . 9
6.1. Determining the PCE Service and transport protocol . . . . 13 6.1. Determining the PCE Service and transport protocol . . . 10
6.2. Determining the IP Address of the PCE . . . . . . . . . . 13 6.2. Determining the IP Address of the PCE . . . . . . . . . . 10
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Determining the PCE domains and Neighbor PCE domains . . . 16 6.3. Determining the PCE domains and Neighbor PCE domains . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 17 7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 14
7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 17 7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. DNS-based PCE Discovery Experimentation . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 transaction-based protocol carried over TCP [RFC4655]. In order to
be 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 PCE) needs Element (PCE), a Path Computation Client (PCC) (or other PCE) 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-IS. Scope of the advertisement is limited to IGP area/level or 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 However in certain scenarios not all PCEs will participate in the
same IGP instance, section 3 (Motivation) outlines a number of use same IGP instance, section 3 (Motivation) outlines a number of use
cases. In these cases, current PCE Discovery mechanisms are cases. In these cases, current PCE Discovery mechanisms are
therefore not appropriate and another PCE discovery function would be therefore not appropriate and another PCE discovery function would be
required. (sec 4 of [PCE-QUESTION]). required. (sec 4 of [PCE-QUESTION]).
This document describes PCE discovery via DNS. The mechanism with This document describes PCE discovery via DNS. The mechanism with
which DNS comes to know about the PCE and its capability is out of which DNS comes to know about the PCE and its capability is out of
scope of this document. scope of this document.
1.1. Terminology 1.1. Terminology
The following terminology is used in this document. The following terminology is used in this document.
PCE-Domain: As per [RFC4655], any collection of network elements PCE-Domain: As per [RFC4655], any collection of network elements
within a common sphere of address management or path computational within a common sphere of address management or path computational
responsibility. Examples of domains include Interior Gateway responsibility. Examples of domains include Interior Gateway
Protocol (IGP) areas and Autonomous Systems (ASs). Protocol (IGP) areas and Autonomous Systems (ASs).
Domain-Name: An identification string that defines a realm of Domain-Name: An identification string that defines a realm of
administrative autonomy, authority, or control on the Internet. administrative autonomy, authority, or control on the Internet.
Any name registered in the DNS is a domain name. DNS Domain names Any name registered in the DNS is a domain name. DNS Domain names
are used in various networking contexts and application-specific are used in various networking contexts and application-specific
naming and addressing purposes. In general, a domain name naming and addressing purposes. In general, a domain name
represents an Internet Protocol (IP) resource. Examples of DNS represents an Internet Protocol (IP) resource. Examples of DNS
domain name is "www.example.com" or "example.com"[RFC1035]. domain name is "www.example.com" or "example.com" [RFC1035].
1.2. Requirements 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;
skipping to change at page 6, line 25 skipping to change at page 5, line 10
consists of using IGP flooding. consists of using IGP flooding.
It has been identified that the existing PCE discovery mechanisms do It has been identified that the existing PCE discovery mechanisms do
not work very well in following scenarios: not work very well in following scenarios:
Inter-AS: Per domain path computation mechanism [RFC5152] or Inter-AS: Per domain path computation mechanism [RFC5152] or
Backward recursive path computation (BRPC) [RFC5441] MAY be used Backward recursive path computation (BRPC) [RFC5441] MAY be used
by cooperating PCEs to compute inter-domain path. In which case by cooperating PCEs to compute inter-domain path. In which case
these cooperating PCEs should be known to other PCEs. In case of these cooperating PCEs should be known to other PCEs. In case of
inter-AS where the PCEs do not participate in a common IGP, the inter-AS where the PCEs do not participate in a common IGP, the
existing IGP discovery mechanism cannot be used to discover existing IGP discovery mechanism cannot be used to discover inter-
inter-AS PCE. AS PCE.
Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require
disclosure of internals of a child domain to the parent PCE. It disclosure of internals of a child domain to the parent PCE. It
may be necessary for a third party to manage the parent PCEs may be necessary for a third party to manage the parent PCEs
according to commercial and policy agreements from each of the according to commercial and policy agreements from each of the
participating service providers [PCE-QUESTION]. [RFC6805] participating service providers [PCE-QUESTION]. [RFC6805]
specifies that a child PCE must be configured with the address of 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. its parent PCE in order for it to interact with its parent PCE.
However handling changes in parent PCE identities and coping with However handling changes in parent PCE identities and coping with
failure events would be an issue for a configured system. There failure events would be an issue for a configured system. There
skipping to change at page 16, line 5 skipping to change at page 13, line 13
IN SRV 0 2 XXXX server2.as100.example.com IN SRV 0 2 XXXX server2.as100.example.com
where XXXX represents the port number at which the service is where XXXX represents the port number at which the service is
reachable. reachable.
As an alternative example, a client wishes to discover a PCE in the As an alternative example, a client wishes to discover a PCE in the
ex2.example.com realm that supports the GCO application over TCP. ex2.example.com realm that supports the GCO application over TCP.
The client performs a NAPTR query for that domain, and the following The client performs a NAPTR query for that domain, and the following
NAPTR records are returned: NAPTR records are returned:
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "pce:pce.tcp" "" IN NAPTR 150 50 "a" "pce:pce.tcp" ""
server1.ex2.example.com server1.ex2.example.com
IN NAPTR 150 50 "a" "pce:pce.tls.tcp" "" IN NAPTR 150 50 "a" "pce:pce.tls.tcp" ""
server2.ex2.example.com server2.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tcp" "" IN NAPTR 150 50 "a" "pce+gco:pce.tcp" ""
server1.ex2.example.com server1.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" "" IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" ""
server2.ex2.example.com server2.ex2.example.com
This indicates that the server supports GCO(ID=1) over TCP and TLS/ This indicates that the server supports GCO(ID=1) over TCP and TLS/
skipping to change at page 17, line 33 skipping to change at page 14, line 41
Future IETF PCE applications MUST reserve the S-NAPTR application Future IETF PCE applications MUST reserve the S-NAPTR application
service tag corresponding to the allocated PCE Application ID as service tag corresponding to the allocated PCE Application ID as
defined in Section 3. defined in Section 3.
7.2. PCE Application Protocol Tags 7.2. PCE Application Protocol Tags
IANA has reserved the following S-NAPTR Application Protocol Tags for IANA has reserved the following S-NAPTR Application Protocol Tags for
the PCE transport protocols in the "S-NAPTR Application Protocol Tag" the PCE transport protocols in the "S-NAPTR Application Protocol Tag"
registry created by [RFC3958]. registry created by [RFC3958].
+------------------+----------+ +------------------+----------+
| Tag | Protocol | | Tag | Protocol |
+------------------+----------+ +------------------+----------+
| pce.tcp | TCP | | pce.tcp | TCP |
+------------------+----------+ +------------------+----------+
Future PCE versions that introduce new transport protocols MUST Future PCE versions that introduce new transport protocols MUST
reserve an appropriate S-NAPTR Application Protocol Tag in the reserve an appropriate S-NAPTR Application Protocol Tag in the
"S-NAPTR Application Protocol Tag" registry created by [RFC3958]. "S-NAPTR Application Protocol Tag" registry created by [RFC3958].
8. Security Considerations 8. Implementation Status
The concept and protocol procedures describe in this I-D were used as
a prototype for a "Transport PCE" based on the principles of Network
Function Virtualization (NFV).
This work was lead by:
o Ricard Vilalta (ricard.vilalta@cttc.es)
o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
The experiment proposed the adoption of the NFV architecture to
deploy a PCE dedicated to path computation of a transport network as
a Virtual Network Function (VNF). Although the NFV architecture has
successfully been demonstrated for mobile networks, there have been
only few attempts to introduce this architecture to core networks.
A PCE NFV orchestrator is introduced, so that the proposed transport
PCE NFV is able to handle intense peak loads of path computation
requests. The NFV orchestrator dynamically deploys virtual PCEs
(vPCEs) on demand to keep the quality of the VNF (e.g., in terms of
latency, request processing time, dedicated algorithms, etc.).
A vPCE is a PCE instance, which is run as a software application on a
cloud computing environment (e.g., a virtual machine). The use of
DNS-based PCE discovery was to offer the deployed vPCEs mechanisms
(and multiple VNFs) to perceived as a single vPCE by the different
Path Computation Clients (PCC).
8.1. DNS-based PCE Discovery Experimentation
The prototype, using the DNS-based discovery proposal, is described
as follows:
o The cloud infrastructure used dynamic deployment and release of
virtual machines with custom images running vPCE as an
application.
o The cloud infrastructure assigned each vPCE a new IP address from
a pool of available IP addresses.
o This IP address is parsed and the PCE DNS is notified with the new
IP address for a new available vPCE.
o As a DNS is a query-response based mechanism. A PCC may use DNS
to discover a PCE only when it needs to compute a path.
In the case of vPCE applications and intermittent PCEP session, which
are systematically opened and closed for each PCEP request, a DNS-
based query-response mechanism is much more suitable, than IGP-based
discovery, in the virtualized environment.
It was also established that DNS-based discovery facilities load
balancing where multiple vPCEs (with different IP addresses) are
identified via DNS using a single PCE server name. This is seen by
the PCCs as a single resource. Ensuring requests are load-balanced
among vPCEs with with minimal complexity, and in the event of failure
of the VNFs, a new VNF or VM (hosting the VNFs) may be spawned
without having to update PCE reachability information on the PCC or
flooding the IGP with the PCE location each time the IP address
changes.
Full details of the prototyping can be found at:
R. Vilalta, R. Munoz, R. Casellas, R. Martinez, V. Lopez, D.
Lopez "Transport PCE Network Function Virtualization", in Proc. of
European Conference on Optical Communication (ECOC 2014), September
21-25, Cannes (France).
<http://www.vlopezalvarez.com/Profesional/Publications/
Conferences/2014_ECOC_2.pdf>
[Note to the RFC Editor - This section is intended to be removed
before publication.]
9. Security Considerations
This document specifies an enhancement to the NAPTR service field This document specifies an enhancement to the NAPTR service field
format. The enhancement and modifications are based on the S-NAPTR, format. The enhancement and modifications are based on the S-NAPTR,
which is actually a simplification of the NAPTR, and therefore the which is actually a simplification of the NAPTR, and therefore the
same security considerations described in [RFC3958] are applicable to same security considerations described in [RFC3958] are applicable to
this document. this document.
For most of those identified threats, the DNS Security Extensions For most of those identified threats, the DNS Security Extensions
[RFC4033] does provide protection. It is therefore recommended to [RFC4033] does provide protection. It is therefore recommended to
consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC
skipping to change at page 19, line 5 skipping to change at page 17, line 16
supported by PCEs in a certain realm faster, which might help the supported by PCEs in a certain realm faster, which might help the
malicious host to scan potential targets for an attack more malicious host to scan potential targets for an attack more
efficiently when some applications have known vulnerabilities. efficiently when some applications have known vulnerabilities.
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.
9. Acknowledgements 10. Acknowledgements
The author would like to thank Claire Bi,Ning Kong, Liang Xia, The author would like to thank Claire Bi,Ning Kong, Liang Xia,
Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart
Cheshire for their review and comments that help improvement to this Cheshire for their review and comments that help improvement to this
document. document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, November 1987. SPECIFICATION", RFC 1035, November 1987.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[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.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database", RFC
RFC 3403, October 2002. 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.
[RFC3958] Daigle, D. and A. Newton, "Domain-Based Application [RFC3958] Daigle, D. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4033] Arends, R., "DNS Security Introduction and Requirements", [RFC4033] Arends, R., "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Droms, R., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, December 2003.
[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.
[RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October
October 2012. 2012.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 11.2. Informative References
Operational Practices, Version 2", RFC 6781,
December 2012.
[RFC6805] King, D. and A. Farrel, "The Application of the Path [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Computation Element Architecture to the Determination of a Ray, "North-Bound Distribution of Link-State and TE
Sequence of Domains in MPLS and GMPLS", RFC 6805, Information using BGP", draft-ietf-idr-ls-distribution-06
November 2012. (work in progress), September 2014.
10.2. Informative References [STATEFUL-PCE]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-09 (work in progress), June 2014.
[ALTO] Kiesel, S., "ALTO Server Discovery", [PCE-QUESTION]
ID draft-ietf-alto-server-discovery-22, December 2013. Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", draft-ietf-pce-
questions-08 (work in progress), October 2014.
[BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
TE Information using BGP", Arbitrary String Attributes", RFC 1464, May 1993.
ID draft-ietf-idr-ls-distribution-04, November 2013.
[PCE-QUESTION] [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Farrel, A., "Unanswered Questions in the Path Computation Wellington, "Secret Key Transaction Authentication for
Element Architecture", DNS (TSIG)", RFC 2845, May 2000.
ID http://tools.ietf.org/html/draft-ietf-pce-questions-00,
July 2013.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
Signature Option", RFC 2385, August 1998. (TKEY RR)", RFC 2930, September 2000.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Droms, R., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, December 2003.
[RFC4927] Le Roux, JL., "Path Computation Element Communication [RFC4927] Le Roux, JL., "Path Computation Element Communication
Protocol (PCECP) Specific Requirements for Inter-Area MPLS Protocol (PCECP) Specific Requirements for Inter-Area MPLS
and GMPLS Traffic Engineering", RFC 4927, June 2007. and GMPLS Traffic Engineering", RFC 4927, June 2007.
[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
January 2008. 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
January 2008. 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
(ICE): A Protocol for Network Address Translator (NAT) Path Computation Method for Establishing Inter-Domain
Traversal for Offer/Answer Protocols", RFC 5245, Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC
April 2010. 5152, February 2008.
[RFC5295] Touch, J., "The TCP Authentication Option", RFC 5295, [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
June 2010. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation [RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation
Element Communication Protocol (PCECP)", RFC 5376, Element Communication Protocol (PCECP)", RFC 5376,
November 2008. November 2008.
[RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382,
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.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of
Global Concurrent Optimization", RFC 5557, July 2009.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of
the Path Computation Element (PCE) to Point-to-
Multipoint (P2MP) MPLS and GMPLS Traffic Engineering
(TE)", RFC 5671, October 2009.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter
Straightforward-Naming Authority Pointer (S-NAPTR)
Usage", RFC 6408, November 2011.
[RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery [RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery
Requirements for Inter-Layer Traffic Engineering", Requirements for Inter-Layer Traffic Engineering", RFC
RFC 6457, June 2007. 6457, June 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
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012.
[RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE", [RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE",
RFC 7025, September 2013. RFC 7025, September 2013.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
skipping to change at page 23, line 24 skipping to change at page 20, line 36
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
Email: dhruv.dhody@huawei.com Email: dhruv.dhody@huawei.com
Daniel King Daniel King
Old Dog Consulting Lancaster University
UK UK
Email: daniel@olddog.co.uk Email: d.king@lancaster.ac.uk
Diego R. Lopez Diego R. Lopez
Telefonica I+D Telefonica I+D
Email: diego@tid.es Email: diego@tid.es
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
 End of changes. 40 change blocks. 
99 lines changed or deleted 207 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/