draft-ietf-pce-lsp-setup-type-09.txt   draft-ietf-pce-lsp-setup-type-10.txt 
PCE Working Group S. Sivabalan PCE Working Group S. Sivabalan
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: September 28, 2018 Individual Expires: November 5, 2018 Nuage Networks
I. Minei I. Minei
Google, Inc. Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
March 27, 2018 May 4, 2018
Conveying path setup type in PCEP messages Conveying path setup type in PCEP messages
draft-ietf-pce-lsp-setup-type-09 draft-ietf-pce-lsp-setup-type-10
Abstract Abstract
A Path Computation Element (PCE) can compute Traffic Engineering (TE) A Path Computation Element (PCE) can compute Traffic Engineering (TE)
paths through a network that are subject to various constraints. paths through a network that are subject to various constraints.
Currently, TE paths are Label Switched Paths (LSPs) which are set up Currently, TE paths are Label Switched Paths (LSPs) which are set up
using the RSVP-TE signaling protocol. However, other TE path setup using the RSVP-TE signaling protocol. However, other TE path setup
methods are possible within the PCE architecture. This document methods are possible within the PCE architecture. This document
proposes an extension to the PCE communication protocol (PCEP) to proposes an extension to the PCE communication protocol (PCEP) to
allow support for different path setup methods over a given PCEP allow support for different path setup methods over a given PCEP
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 28, 2018. This Internet-Draft will expire on November 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Manageability Considerations . . . . . . . . . . . . . . . . 7 6. Manageability Considerations . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 9
8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9 8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9
8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
Protocol (PCEP) for communication between a Path Computation Client Protocol (PCEP) for communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between a PCE and a (PCC) and a Path Computation Element (PCE), or between a PCE and a
PCE. A PCC requests a path subject to various constraints and PCE. A PCC requests a path subject to various constraints and
optimization criteria from a PCE. The PCE responds to the PCC with a optimization criteria from a PCE. The PCE responds to the PCC with a
hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the
skipping to change at page 3, line 43 skipping to change at page 3, line 43
This document defines a path setup type code for RSVP-TE. When a new This document defines a path setup type code for RSVP-TE. When a new
path setup type (other than RSVP-TE) is introduced for setting up a path setup type (other than RSVP-TE) is introduced for setting up a
path, a path setup type code and, optionally, a sub-TLV pertaining to path, a path setup type code and, optionally, a sub-TLV pertaining to
the new path setup type will be defined by the document that the new path setup type will be defined by the document that
specifies the new path setup type. specifies the new path setup type.
1.1. Requirements Language 1.1. Requirements Language
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology 2. Terminology
The following terminologies are used in this document: The following terminologies are used in this document:
ERO: Explicit Route Object. ERO: Explicit Route Object.
LSR: Label Switching Router. LSR: Label Switching Router.
PCC: Path Computation Client. PCC: Path Computation Client.
skipping to change at page 4, line 41 skipping to change at page 4, line 47
| PST#1 | ... | PST#N | Padding | | PST#1 | ... | PST#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional sub-TLVs (variable) // // Optional sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
The TLV type is TBD1 (to be assigned by IANA). Its reserved field The TLV type is TBD1 (to be assigned by IANA). Its reserved field
MUST be set to zero. The other fields in the TLV are as follows. MUST be set to zero by the sender and MUST be ignored by the
receiver. The other fields in the TLV are as follows.
Length: The total length of the remainder of the TLV, that is, Length: The total length in bytes of the remainder of the TLV, that
excluding the Type and Length fields. is, excluding the Type and Length fields.
Number of PSTs: The number of PSTs in the following list, excluding Number of PSTs: The number of PSTs in the following list, excluding
padding. padding.
List of PSTs: A list of the PSTs that the PCEP speaker supports. List of PSTs: A list of the PSTs that the PCEP speaker supports.
Each PST is a single byte in length. Duplicate entries in this Each PST is a single byte in length. Duplicate entries in this
list MUST be ignored. The PCEP speaker MUST pad the list with list MUST be ignored. The PCEP speaker MUST pad the list with
zeros so that it is a muliple of four bytes in length. This zeros so that it is a muliple of four bytes in length. This
document defines the following PST value: document defines the following PST value:
* PST = 0: Path is setup using the RSVP-TE signaling protocol. * PST = 0: Path is setup using the RSVP-TE signaling protocol.
Optional sub-TLVs: A list of sub-TLVs associated with the supported Optional sub-TLVs: A list of sub-TLVs associated with the supported
PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined PSTs. Each PST has zero or one sub-TLVs associated with it, and
in ([RFC5440]). That is, each sub-TLV MUST be padded to a four each sub-TLV is associated with exactly one PST. Each sub-TLV
byte alignment, and the length field of each sub-TLV MUST NOT MUST obey the rules for TLV formatting defined in ([RFC5440]).
include the padding bytes. This document does not define any sub- That is, each sub-TLV is padded to a four byte alignment, and the
TLVs. length field of each sub-TLV does not include the padding bytes.
This document does not define any sub-TLVs; an example can be
found in [I-D.ietf-pce-segment-routing].
A PCEP speaker MUST check that this TLV is correctly formatted, as A PCEP speaker MUST check that this TLV is correctly formatted, as
follows. The TLV Length field MUST be equal to the size of the follows.
appended sub-TLVs plus the size of the PST list (rounded up to the
nearest multiple of four) plus four bytes. The Number of PSTs field o If there are no sub-TLVs, then the TLV length field MUST be equal
MUST be greater than zero. If a PCEP speaker receives a PATH-SETUP- to four bytes plus the size of the PST list, excluding any padding
TYPE-CAPABILITY TLV which violates these rules, then the PCEP speaker bytes.
MUST send a PCErr message with Error-Type = 10 (Reception of an
invalid object) and Error-Value = 11 (Malformed object) and MUST o If there are sub-TLVs then the TLV Length field MUST be equal to
close the PCEP session. The PCEP speaker MAY include the malformed four bytes plus the size of the PST list (rounded up to the
OPEN object in the PCErr message as well. nearest multiple of four) plus the size of the appended sub-TLVs
excluding any padding bytes in the final sub-TLV.
o The Number of PSTs field MUST be greater than zero.
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV which
violates these rules, then the PCEP speaker MUST send a PCErr message
with Error-Type = 10 (Reception of an invalid object) and Error-Value
= 11 (Malformed object) and MUST close the PCEP session. The PCEP
speaker MAY include the malformed OPEN object in the PCErr message as
well.
If a PCEP speaker receives an OPEN object with more than one PATH- If a PCEP speaker receives an OPEN object with more than one PATH-
SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first
instance of this TLV. instance of this TLV.
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP
speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST
it supports is RSVP-TE. If a PCEP speaker supports other PSTs it supports is RSVP-TE. If a PCEP speaker supports other PSTs
besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE-
CAPABILITY TLV in its OPEN object. CAPABILITY TLV in its OPEN object.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
TLV, it MUST ignore the TLV in accordance with ([RFC5440]). TLV, it will ignore the TLV in accordance with [RFC5440].
4. Path Setup Type TLV 4. Path Setup Type TLV
When a PCEP session is used to set up TE paths using different When a PCEP session is used to set up TE paths using different
methods, the corresponding PCE and PCC must be aware of the path methods, the corresponding PCE and PCC must be aware of the path
setup method used. That means, a PCE must be able to specify paths setup method used. That means, a PCE must be able to specify paths
in the correct format and a PCC must be able to take control plane in the correct format and a PCC must be able to take control plane
and forwarding plane actions appropriate to the PST. and forwarding plane actions appropriate to the PST.
0 1 2 3 0 1 2 3
skipping to change at page 6, line 27 skipping to change at page 6, line 42
the above figure. The TLV type is 28. Its reserved field MUST be the above figure. The TLV type is 28. Its reserved field MUST be
set to zero. The one byte value contains the PST as defined for the set to zero. The one byte value contains the PST as defined for the
PATH-SETUP-TYPE-CAPABILITY TLV. PATH-SETUP-TYPE-CAPABILITY TLV.
The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-
TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit
the TLV if the PST is RSVP-TE. If the RP or SRP object contains more the TLV if the PST is RSVP-TE. If the RP or SRP object contains more
than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed
and the rest MUST be ignored. and the rest MUST be ignored.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will
ignore the TLV in accordance with ([RFC5440]). ignore the TLV in accordance with [RFC5440], and will use RSVP-TE to
set up the path.
5. Operation 5. Operation
During the PCEP initialization phase, if a PCEP speaker receives a During the PCEP initialization phase, if a PCEP speaker receives a
PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST consider that PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the
the peer suports only the PSTs listed in the TLV. If the PCEP peer supports only the PSTs listed in the TLV. If the PCEP speaker
speaker and its peer have no PSTs in common, then the PCEP speaker and its peer have no PSTs in common, then the PCEP speaker MUST send
MUST send a PCErr message with Error-Type = 21 (Invalid traffic a PCErr message with Error-Type = 21 (Invalid traffic engineering
engineering path setup type) and Error-Value = 2 (Mismatched path path setup type) and Error-Value = 2 (Mismatched path setup type) and
setup type) and close the PCEP session. close the PCEP session.
If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
speaker MUST infer that the peer supports path setup using at least speaker MUST infer that the peer supports path setup using at least
RSVP-TE. The PCEP speaker MAY also infer that the peer supports RSVP-TE. The PCEP speaker MAY also infer that the peer supports
other path setup types, but the means of inference are outside the other path setup types, but the means of inference are outside the
scope of this document. scope of this document.
When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST
include the PATH-SETUP-TYPE TLV in the RP object, unless the intended include the PATH-SETUP-TYPE TLV in the RP object, unless the intended
PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
skipping to change at page 7, line 41 skipping to change at page 8, line 10
PCInitiate message, then the PST that the PCC indicates in the PCRpt PCInitiate message, then the PST that the PCC indicates in the PCRpt
MUST match the PST that the stateful PCE intended in the PCUpd or MUST match the PST that the stateful PCE intended in the PCUpd or
PCInitiate. If it does not, then the PCE MUST send a PCErr message PCInitiate. If it does not, then the PCE MUST send a PCErr message
with Error-Type = 21 (Invalid traffic engineering path setup type) with Error-Type = 21 (Invalid traffic engineering path setup type)
and Error-Value = 2 (Mismatched path setup type) and close the PCEP and Error-Value = 2 (Mismatched path setup type) and close the PCEP
session. session.
6. Manageability Considerations 6. Manageability Considerations
This document generalises PCEP to allow path setup methods other than This document generalises PCEP to allow path setup methods other than
RSVP-TE to be used by the network. It is possible that, in a given RSVP-TE to be used by the network (but does not define any new path
setup types, besides RSVP-TE). It is possible that, in a given
network, multiple path setup methods will be used. It is also network, multiple path setup methods will be used. It is also
possible that not all devices will support the same set of path setup possible that not all devices will support the same set of path setup
methods. Managing networks that combine multiple path setup methods methods. Managing networks that combine multiple path setup methods
may therefore raise some challenges from a configuration and may therefore raise some challenges from a configuration and
observability point of view. observability point of view.
Each document that introduces a new path setup type to PCEP must Each document that defines a new Path Setup Type in the Path Setup
include a manageability section. The manageability section must Type Registry (Section 8.2) must include a manageability section.
explain how operators can manage PCEP with the new path setup type. The manageability section must explain how operators can manage PCEP
It must address the following questions, which are generally with the new path setup type. It must address the following
applicable when working with multiple path setup types in PCEP. questions, which are generally applicable when working with multiple
path setup types in PCEP.
o What are the criteria for when devices will use the new path setup o What are the criteria for when devices will use the new path setup
type in PCEP, and how can the operator control this? type in PCEP, and how can the operator control this?
o How can the network be migrated to the new path setup type, and o How can the network be migrated to the new path setup type, and
are there any backwards compatibility issues that operators need are there any backwards compatibility issues that operators need
to be aware of? to be aware of?
o Are paths set up using the new path setup type intended to coexist o Are paths set up using the new path setup type intended to coexist
with other paths over the long term and, if so, how is this with other paths over the long term and, if so, how is this
situation managed with PCEP? situation managed with PCEP?
o How can operators verify the correct operation of PCEP in the o How can operators verify the correct operation of PCEP in the
network with respect to the new path setup type? Which fault network with respect to the new path setup type? Which fault
conditions must be reported to the operators? conditions must be reported to the operators?
o Are there any existing management interfaces (such as YANG models) o Are there any existing management interfaces (such as YANG models)
that must be extended to model the operation of PCEP in the that must be extended to model the operation of PCEP in the
network with respect to the new path setup type? network with respect to the new path setup type?
See [RFC6123] for further guidance on how to write manageability See [RFC5706] for further guidance on how to write manageability
sections in PCEP standards-track documents. sections in standards-track documents.
7. Security Considerations 7. Security Considerations
The security considerations described in [RFC5440] and [RFC8281] are The security considerations described in [RFC5440] and [RFC8281] are
applicable to this specification. No additional security measure is applicable to this specification. No additional security measure is
required. required.
Note that, if the security mechanisms of [RFC5440] and [RFC8281] are
not used, then the protocol described by this draft could be attacked
in the following new way. An attacker, using a TCP man-in-the-middle
attack, could inject error messages into the PCEP session when a
particular PST is (or is not) used. By doing so, the attacker could
potentially force the use of a specific PST, which may allow them to
subsequently attack a weakness in that PST.
8. IANA Considerations 8. IANA Considerations
8.1. PCEP TLV Type Indicators 8.1. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code point in the PCEP TLV Type Indicators registry. code point in the PCEP TLV Type Indicators registry.
Value Description Reference Value Description Reference
28 PATH-SETUP-TYPE This document 28 PATH-SETUP-TYPE This document
skipping to change at page 10, line 23 skipping to change at page 11, line 5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-11 (work in progress),
November 2017.
[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, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>. 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Computation Element (PCE) Working Group Drafts", RFC 6123, Management of New Protocols and Protocol Extensions",
DOI 10.17487/RFC6123, February 2011, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc6123>. <https://www.rfc-editor.org/info/rfc5706>.
Authors' Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
skipping to change at page 11, line 14 skipping to change at page 12, line 4
Authors' Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Jeff Tantsura Jeff Tantsura
Individual Nuage Networks
755 Ravendale Drive
Mountain View, CA 94043
USA
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: inaminei@google.com Email: inaminei@google.com
 End of changes. 27 change blocks. 
54 lines changed or deleted 92 lines changed or added

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