< draft-wu-pce-dns-pce-discovery-07.txt   draft-wu-pce-dns-pce-discovery-08.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: April 27, 2015 D. King Expires: October 31, 2015 D. King
Lancaster University Lancaster University
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
J. Tantsura J. Tantsura
Ericsson Ericsson
October 27, 2014 April 29, 2015
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-07 draft-wu-pce-dns-pce-discovery-08
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 and IS-IS IGP discovery. 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
using an IGP discovery. using an IGP discovery.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 April 27, 2015. This Internet-Draft will expire on October 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Outside the Routing Domain . . . . . . . . . . . . . . . 4 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . 4
3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 5 3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 5
3.2.1. Query-Response versus Advertisement . . . . . . . . . 5 3.2.1. Query-Response versus Advertisement . . . . . . . . . 5
3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . 6 3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . 6
3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 6 3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 6
3.4.1. Handling Changes in PCE Identities . . . . . . . . . 6 3.4.1. Handling Changes in PCE Identities . . . . . . . . . 6
3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 6 3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 6
3.4.3. Load Sharing of Path Computation Requests . . . . . . 7 3.4.3. Load Sharing of Path Computation Requests . . . . . . 6
4. Extended Naming Authority Pointer ( NAPTR )Service Field 4. Extended Naming Authority Pointer ( NAPTR )Service Field
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IETF Standards Track PCE Applications . . . . . . . . . . 8 4.1. IETF Standards Track PCE Applications . . . . . . . . . . 8
5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8
6. Discovering a Path Computation Element . . . . . . . . . . . 9 6. Discovering a Path Computation Element . . . . . . . . . . . 9
6.1. Determining the PCE Service and transport protocol . . . 10 6.1. Determining the PCE Service and transport protocol . . . 10
6.2. Determining the IP Address of the PCE . . . . . . . . . . 10 6.2. Determining the IP Address of the PCE . . . . . . . . . . 10
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Determining the PCE domains and Neighbor PCE domains . . 13 6.3. Determining the PCE domains and Neighbor PCE domains . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 14 7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 14
7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 14 7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 14
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. DNS-based PCE Discovery Experimentation . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
skipping to change at page 13, line 13 skipping to change at page 13, line 5
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 15, line 5 skipping to change at page 14, line 44
+------------------+----------+ +------------------+----------+
| 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. Implementation Status 8. Security Considerations
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 17, line 16 skipping to change at page 15, line 27
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.
10. Acknowledgements 9. 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.
11. References 10. References
11.1. Normative References 10.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.
[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.
skipping to change at page 18, line 11 skipping to change at page 16, line 22
[RFC4033] Arends, R., "DNS Security Introduction and Requirements", [RFC4033] Arends, R., "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[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, October [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October
2012. 2012.
11.2. Informative References 10.2. Informative References
[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-06
(work in progress), September 2014.
[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.
[PCE-QUESTION] [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and
Farrel, A. and D. King, "Unanswered Questions in the Path TE Information using BGP", ID draft-ietf-idr-ls-
Computation Element Architecture", draft-ietf-pce- distribution-10, January 2015.
questions-08 (work in progress), October 2014.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993. Arbitrary String Attributes", RFC 1464, May 1993.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Wellington, "Secret Key Transaction Authentication for Signature Option", RFC 2385, August 1998.
DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
(TKEY RR)", RFC 2930, September 2000. Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 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.
[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.
skipping to change at page 19, line 21 skipping to change at page 17, line 25
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC
5152, February 2008. 5152, February 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. 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.
[RFC5452] Hubert, A., "Measures for Making DNS More Resilient
against Forged Answers", RFC 5452, January 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009. Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5452] Hubert, A., "Measures for Making DNS More Resilient
against Forged Answers", RFC 5452, January 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Requirements and Protocol Extensions in Support of Global
Global Concurrent Optimization", RFC 5557, July 2009. Concurrent Optimization", RFC 5557, July 2009.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
the Path Computation Element (PCE) to Point-to- Computation Element (PCE) to Point-to-Multipoint (P2MP)
Multipoint (P2MP) MPLS and GMPLS Traffic Engineering MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
(TE)", RFC 5671, October 2009. October 2009.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter
Straightforward-Naming Authority Pointer (S-NAPTR) Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
Usage", RFC 6408, November 2011. 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", RFC Requirements for Inter-Layer Traffic Engineering", RFC
6457, June 2007. 6457, June 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December Operational Practices, Version 2", RFC 6781, December
2012. 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, November Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012. 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.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, October 2014.
[STATEFUL-PCE]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", ID draft-ietf-pce-stateful-
pce-11, April 2015.
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
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
skipping to change at page 20, line 34 skipping to change at page 19, line 4
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.dhody@huawei.com Email: dhruv.dhody@huawei.com
Daniel King Daniel King
Lancaster University Lancaster University
UK UK
Email: d.king@lancaster.ac.uk Email: daniel@olddog.co.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. 26 change blocks. 
130 lines changed or deleted 51 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/