draft-ietf-pce-stateful-path-protection-04.txt   draft-ietf-pce-stateful-path-protection-05.txt 
PCE Working Group H. Ananthakrishnan PCE Working Group H. Ananthakrishnan
Internet-Draft Netflix Internet-Draft Netflix
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: August 7, 2019 Cisco Expires: December 6, 2019 Cisco
C. Barth C. Barth
R. Torvi R. Torvi
Juniper Networks Juniper Networks
I. Minei I. Minei
Google, Inc Google, Inc
E. Crabbe E. Crabbe
Individual Contributor Individual Contributor
M. Negi M. Negi
Huawei Technologies Huawei Technologies
February 3, 2019 June 4, 2019
PCEP Extensions for Associating Working and Protection LSPs with PCEP Extensions for Associating Working and Protection LSPs with
Stateful PCE Stateful PCE
draft-ietf-pce-stateful-path-protection-04 draft-ietf-pce-stateful-path-protection-05
Abstract Abstract
A stateful Path Computation Element (PCE) is capable of computing as A stateful Path Computation Element (PCE) is capable of computing as
well as controlling via Path Computation Element Protocol (PCEP) well as controlling via Path Computation Element Communication
Multiprotocol Label Switching Traffic Engineering Label Switched Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering
Paths (MPLS LSP). Furthermore, it is also possible for a stateful Label Switched Paths (MPLS LSP). Furthermore, it is also possible
PCE to create, maintain, and delete LSPs. This document describes for a stateful PCE to create, maintain, and delete LSPs. This
PCEP extension to associate two or more LSPs to provide end-to-end document describes PCEP extension to associate two or more LSPs to
path protection. provide end-to-end path protection.
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 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 August 7, 2019. This Internet-Draft will expire on December 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Path Protection Association Type . . . . . . . . . . . . 5 3.1. Path Protection Association Type . . . . . . . . . . . . 5
3.2. Path Protection Association TLV . . . . . . . . . . . . . 5 3.2. Path Protection Association TLV . . . . . . . . . . . . . 6
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7
4.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 7
4.3. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.3. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 8
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 8 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 8
4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8
5. Other considerations . . . . . . . . . . . . . . . . . . . . 9 5. Other considerations . . . . . . . . . . . . . . . . . . . . 9
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9
6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Manageability Considerations . . . . . . . . . . . . . . . . 11 8. Manageability Considerations . . . . . . . . . . . . . . . . 11
8.1. Control of Function and Policy . . . . . . . . . . . . . 11 8.1. Control of Function and Policy . . . . . . . . . . . . . 11
8.2. Information and Data Models . . . . . . . . . . . . . . . 11 8.2. Information and Data Models . . . . . . . . . . . . . . . 11
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12
8.6. Impact On Network Operations . . . . . . . . . . . . . . 12 8.6. Impact On Network Operations . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC5440] describes PCEP for communication between a Path Computation [RFC5440] describes PCEP for communication between a Path Computation
Client (PCC) and a PCE or between one a pair of PCEs as per Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. A
[RFC4655]. A PCE computes paths for MPLS-TE LSPs based on various PCE computes paths for MPLS-TE LSPs based on various constraints and
constraints and optimization criteria. optimization criteria.
Stateful pce [RFC8231] specifies a set of extensions to PCEP to Stateful PCE [RFC8231] specifies a set of extensions to PCEP to
enable stateful control of paths such as MPLS TE LSPs between and enable stateful control of paths such as MPLS TE LSPs between and
across PCEP sessions in compliance with [RFC4657]. It includes across PCEP sessions in compliance with [RFC4657]. It includes
mechanisms to effect LSP state synchronization between PCCs and PCEs, mechanisms to effect LSP state synchronization between PCCs and PCEs,
delegation of control of LSPs to PCEs, and PCE control of timing and delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions and sequence of path computations within and across PCEP sessions and
focuses on a model where LSPs are configured on the PCC and control focuses on a model where LSPs are configured on the PCC and control
over them is delegated to the PCE. Furthermore, a mechanism to over them is delegated to the PCE. Furthermore, a mechanism to
dynamically instantiate LSPs on a PCC based on the requests from a dynamically instantiate LSPs on a PCC based on the requests from a
stateful PCE or a controller using stateful PCE, is specified in stateful PCE or a controller using stateful PCE, is specified in
[RFC8281]. [RFC8281].
Path protection [RFC4427] refers to a paradigm in which the working Path protection [RFC4427] refers to a paradigm in which the working
LSP is protected by one or more protection LSP(s). When the working LSP is protected by one or more protection LSP(s). When the working
LSP fails, protection LSP(s) is/are activated. When the working LSPs LSP fails, protection LSP(s) is/are activated. When the working LSPs
are computed and controlled by the PCE, there is benefit in a mode of are computed and controlled by the PCE, there is benefit in a mode of
operation where protection LSPs are as well. operation where protection LSPs are as well. [RFC8051] describes
applicability of Path protection in PCE deployment.
This document specifies a stateful PCEP extension to associate two or This document specifies a stateful PCEP extension to associate two or
more LSPs for the purpose of setting up path protection. The more LSPs for the purpose of setting up path protection. The
proposed extension covers the following scenarios: proposed extension covers the following scenarios:
o A PCC initiates a protection LSP and retains the control of the o A PCC initiates a protection LSP and retains the control of the
LSP. The PCC computes the path itself or makes a request for path LSP. The PCC computes the path itself or makes a request for path
computation to a PCE. After the path setup, it reports the computation to a PCE. After the path setup, it reports the
information and state of the path to the PCE. This includes the information and state of the path to the PCE. This includes the
association group identifying the working and protection LSPs. association group identifying the working and protection LSPs.
skipping to change at page 4, line 44 skipping to change at page 4, line 46
The following terminologies are used in this document: The following terminologies are used in this document:
ERO: Explicit Route Object. ERO: Explicit Route Object.
LSP: Label Switched Path. LSP: Label Switched Path.
PCC: Path Computation Client. PCC: Path Computation Client.
PCE: Path Computation Element PCE: Path Computation Element
PCEP: Path Computation Element Protocol. PCEP: Path Computation Element Communication Protocol.
PPAG: Path Protection Association Group. PPAG: Path Protection Association Group.
TLV: Type, Length, and Value. TLV: Type, Length, and Value.
3. PCEP Extensions 3. PCEP Extensions
3.1. Path Protection Association Type 3.1. Path Protection Association Type
LSPs are not associated by listing the other LSPs with which they LSPs are not associated by listing the other LSPs with which they
interact, but rather by making them belong to an association group interact, but rather by making them belong to an association group
referred to as "Path Protection Association Group" (PPAG) in this referred to as "Path Protection Association Group" (PPAG) in this
document. All LSPs join a PPAG individually. PPAG is based on the document. All LSPs join a PPAG individually. PPAG is based on the
generic Association object used to associate two or more LSPs generic Association object used to associate two or more LSPs
specified in [I-D.ietf-pce-association-group]. A member of a PPAG specified in [I-D.ietf-pce-association-group]. A member of a PPAG
can take the role of working or protection LSP. This document can take the role of working or protection LSP. This document
defines a new association type called "Path Protection Association defines a new Association type called "Path Protection Association
Type" of value TBD1. A PPAG can have one working LSP and/or one or Type" of value TBD1. A PPAG can have one working LSP and/or one or
more protection LSPs. The source, destination and Tunnel ID (as more protection LSPs. The source, destination and Tunnel ID (as
carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per
[RFC3209]) of all LSPs within a PPAG MUST be the same. As per [RFC3209]) of all LSPs within a PPAG MUST be the same. As per
[RFC3209], TE tunnel is used to associate a set of LSPs during [RFC3209], TE tunnel is used to associate a set of LSPs during
reroute or to spread a traffic trunk over multiple paths. reroute or to spread a traffic trunk over multiple paths.
The format of the Association object used for PPAG is specified in The format of the Association object used for PPAG is specified in
[I-D.ietf-pce-association-group]. [I-D.ietf-pce-association-group].
This document defines a new Association type, the Path Protection This document defines a new Association type, the "Path Protection
Association type, value will be assigned by IANA (TBD1). Association Type", value will be assigned by IANA (TBD1).
[I-D.ietf-pce-association-group] specify the mechanism for the [I-D.ietf-pce-association-group] specify the mechanism for the
capability advertisement of the association types supported by a PCEP capability advertisement of the Association types supported by a PCEP
speaker by defining a ASSOC-Type-List TLV to be carried within an speaker by defining a ASSOC-Type-List TLV to be carried within an
OPEN object. This capability exchange for the association type OPEN object. This capability exchange for the Association type
described in this document (i.e. Path Protection Association Type) described in this document (i.e. Path Protection Association Type)
MAY be done before using the policy association, i.e., the PCEP MAY be done before using the policy association, i.e., the PCEP
speaker MAY include the Path Protection Association Type (TBD1) in speaker MAY include the Path Protection Association Type (TBD1) in
the ASSOC-Type-List TLV before using the PPAG in the PCEP messages. the ASSOC-Type-List TLV before using the PPAG in the PCEP messages.
This Association-Type is dynamic in nature and created by the PCC or This Association type is dynamic in nature and created by the PCC or
PCE for the LSPs belonging to the same TE tunnel (as described in PCE for the LSPs belonging to the same TE tunnel (as described in
[RFC3209]) originating at the same head node and terminating at the [RFC3209]) originating at the same head node and terminating at the
same destination. These associations are conveyed via PCEP messages same destination. These associations are conveyed via PCEP messages
to the PCEP peer. Operator-configured Association Range MUST NOT be to the PCEP peer. As per [I-D.ietf-pce-association-group], the
set for this association-type and MUST be ignored. association source is set to the local PCEP speaker address that
created the association, unless local policy dictates otherwise.
Operator-configured Association Range MUST NOT be set for this
Association type and MUST be ignored.
3.2. Path Protection Association TLV 3.2. Path Protection Association TLV
The Path Protection Association TLV is an optional TLV for use with The Path Protection Association TLV is an optional TLV for use with
the Path Protection Association Object Type. The Path Protection the Path Protection Association Type. The Path Protection
Association TLV MUST NOT be present more than once. If it appears Association TLV MUST NOT be present more than once. If it appears
more than once, only the first occurrence is processed and any others more than once, only the first occurrence is processed and any others
MUST be ignored. MUST be ignored.
The Path Protection Association TLV follows the PCEP TLV format of The Path Protection Association TLV follows the PCEP TLV format of
[RFC5440]. [RFC5440].
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is to be assigned by IANA. The length
field is 16 bit-long and has a fixed value of 4. field is 16 bit-long and has a fixed value of 4.
skipping to change at page 7, line 25 skipping to change at page 7, line 35
4. Operation 4. Operation
An LSP is associated with other LSPs with which they interact by An LSP is associated with other LSPs with which they interact by
adding them to a common association group via the ASSOCIATION object. adding them to a common association group via the ASSOCIATION object.
All procedures and error-handling for the ASSOCIATION object is as All procedures and error-handling for the ASSOCIATION object is as
per [I-D.ietf-pce-association-group]. per [I-D.ietf-pce-association-group].
4.1. State Synchronization 4.1. State Synchronization
During state synchronization, a PCC MUST report all the existing path During state synchronization, a PCC reports all the existing LSP
protection association groups as well as any path protection flags to states as described in [RFC8231], the the association group
PCE(s) as per [I-D.ietf-pce-association-group]. membership pertaining to a LSP is also reported as per
[I-D.ietf-pce-association-group]. This includes PPAG.
4.2. PCC Initiated LSPs 4.2. PCC Initiated LSPs
A PCC can associate a set of LSPs under its control for path A PCC can associate a set of LSPs under its control for path
protection purpose. Similarly, the PCC can remove on or more LSPs protection purpose. Similarly, the PCC can remove on or more LSPs
under its control from the corresponding PPAG. In both cases, the under its control from the corresponding PPAG. In both cases, the
PCC would report the change in association to PCE(s) via PCRpt PCC would report the change in association to PCE(s) via Path
message. A PCC can also delegate the working and protection LSPs to Computation Report(PCRpt) message. A PCC can also delegate the
a stateful PCE, where PCE would control the LSPs. The stateful PCE working and protection LSPs to a stateful PCE, where PCE would
could update the paths and attributes of the LSPs in the association control the LSPs. The stateful PCE could update the paths and
group via PCUpd message. A PCE could also update the association to attributes of the LSPs in the association group via Path Computation
Update(PCUpd) message. A PCE could also update the association to
PCC via PCUpd message. These procedures are described in PCC via PCUpd message. These procedures are described in
[I-D.ietf-pce-association-group]. [I-D.ietf-pce-association-group].
It is expected that both working and protection LSP are delegated It is expected that both working and protection LSP are delegated
together (and to the same PCE) to avoid any race conditions. Refer together (and to the same PCE) to avoid any race conditions. Refer
[I-D.litkowski-pce-state-sync] for the problem description. [I-D.litkowski-pce-state-sync] for the problem description.
4.3. PCE Initiated LSPs 4.3. PCE Initiated LSPs
A PCE can create/update working and protection LSPs independently. A PCE can create/update working and protection LSPs independently.
As specified in [I-D.ietf-pce-association-group], Association Groups As specified in [I-D.ietf-pce-association-group], Association Groups
can be created by both PCE and PCC. Further, a PCE can remove a can be created by both the PCE and PCC. Further, a PCE can remove a
protection LSP from a PPAG as specified in protection LSP from a PPAG as specified in
[I-D.ietf-pce-association-group]. The PCE uses PCUpd or Path
[I-D.ietf-pce-association-group]. The PCE uses PCUpd or PCInitiate Computation Initiate(PCInitiate) message to communicate the
message to communicate the association information to the PCC. association information to the PCC.
4.4. Session Termination 4.4. Session Termination
As per [I-D.ietf-pce-association-group] the association information As per [I-D.ietf-pce-association-group] the association information
is cleared along with the LSP state information. When a PCEP session is cleared along with the LSP state information. When a PCEP session
is terminated, after expiry of State Timeout Interval at PCC, the LSP is terminated, after expiry of State Timeout Interval at PCC, the LSP
state associated with that PCEP session is reverted to operator- state associated with that PCEP session is reverted to operator-
defined default parameters or behaviors as per [RFC8231]. Same defined default parameters or behaviors as per [RFC8231]. Same
procedure is also followed for the association information. On procedure is also followed for the association information. On
session termination at the PCE, when the LSP state reported by PCC is session termination at the PCE, when the LSP state reported by PCC is
cleared, the association information is also cleared as per cleared, the association information is also cleared as per
[I-D.ietf-pce-association-group]. Where there are no LSPs in a [I-D.ietf-pce-association-group]. Where there are no LSPs in a
association group, the association is considered to be deleted.. association group, the association is considered to be deleted.
4.5. Error Handling 4.5. Error Handling
As per the processing rules specified in section 5.4 of As per the processing rules specified in section 5.4 of
[I-D.ietf-pce-association-group], if a PCEP speaker does not support [I-D.ietf-pce-association-group], if a PCEP speaker does not support
this Path Protection association-type, it would return a PCErr this Path Protection Association Type, it would return a PCErr
message with Error-Type 26 (Early allocation by IANA) "Association message with Error-Type 26 (Early allocation by IANA) "Association
Error" and Error-Value 1 "Association-type is not supported". Error" and Error-Value 1 "Association type is not supported".
All LSPs (working or protection) within a PPAG MUST belong to the All LSPs (working or protection) within a PPAG MUST belong to the
same TE Tunnel (as described in [RFC3209]) and have the same source same TE Tunnel (as described in [RFC3209]) and have the same source
and destination. If a PCEP speaker attempts to add an LSP to a PPAG and destination. If a PCEP speaker attempts to add an LSP to a PPAG
and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with
description as per [RFC3209]) or source or destination of the LSP is description as per [RFC3209]) or source or destination of the LSP is
different from the LSP(s) in the PPAG, the PCC MUST send PCErr with different from the LSP(s) in the PPAG, the PCC MUST send PCErr with
Error-Type= 29 (Early allocation by IANA) (Association Error) Error-Type= 29 (Early allocation by IANA) (Association Error)
[I-D.ietf-pce-association-group] and Error-Value = TBD3 (Tunnel ID or [I-D.ietf-pce-association-group] and Error-Value = TBD3 (Tunnel ID or
End points mismatch for Path Protection Association). In case of End points mismatch for Path Protection Association). In case of
Path Protection, LSP-IDENTIFIERS TLV SHOULD be included for all LSPs Path Protection, LSP-IDENTIFIERS TLV SHOULD be included for all LSPs
(including segment routing (SR) [I-D.ietf-pce-segment-routing]. (including Segment Routing (SR) [I-D.ietf-pce-segment-routing]).
When the protection type is set to 1+1 or 1:N (with N=1), there MUST When the protection type is set to 1+1 or 1:N (with N=1), there MUST
be only one working LSP and protection LSP within a PPAG. If a PCEP be only one working LSP and protection LSP within a PPAG. If a PCEP
Speaker attempts to add another working/protection LSP, the PCEP peer Speaker attempts to add another working/protection LSP, the PCEP peer
MUST send PCErr with Error-Type=29 (Early allocation by IANA) MUST send PCErr with Error-Type=29 (Early allocation by IANA)
(Association Error) [I-D.ietf-pce-association-group] and Error-Value (Association Error) [I-D.ietf-pce-association-group] and Error-Value
= TBD4 (Attempt to add another working/protection LSP for Path = TBD4 (Attempt to add another working/protection LSP for Path
Protection Association). Protection Association).
All processing as per section 5.4 of [I-D.ietf-pce-association-group] All processing as per section 5.4 of [I-D.ietf-pce-association-group]
continue to apply. continue to apply.
5. Other considerations 5. Other considerations
The working and protection LSPs are typically resource disjoint The working and protection LSPs are typically resource disjoint
(e.g., node, SRLG disjoint). This ensures that a single failure will (e.g., node, SRLG disjoint). This ensures that a single failure will
not affect both the working and protection LSPs.The disjoint not affect both the working and protection LSPs.The disjoint
requirement for a group of LSPs is handled via another association requirement for a group of LSPs is handled via another Association
type called "Disjointness Association", as described in type called "Disjointness Association", as described in
[I-D.ietf-pce-association-diversity]. The diversity requirements for [I-D.ietf-pce-association-diversity]. The diversity requirements for
the the protection LSP are also handled by including both ASSOCIATION the the protection LSP are also handled by including both ASSOCIATION
object identifying both the protection association group and disjoint object identifying both the protection association group and disjoint
association group for the group of LSPs. association group for the group of LSPs.
6. IANA considerations 6. IANA considerations
6.1. Association Type 6.1. Association Type
This document defines a new association type, originally defined in This document defines a new Association type, originally defined in
[I-D.ietf-pce-association-group], for path protection. IANA is [I-D.ietf-pce-association-group], for path protection. IANA is
requested to make the assignment of a new value for the sub-registry requested to make the assignment of a new value for the sub-registry
"ASSOCIATION Type Field" (request to be created in "ASSOCIATION Type Field" (request to be created in
[I-D.ietf-pce-association-group]), as follows: [I-D.ietf-pce-association-group]), as follows:
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
| Association Type | Association Name | Reference | | Association type | Association Name | Reference |
| Value | | | | Value | | |
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
| TBD1 | Path Protection | This | | TBD1 | Path Protection | This |
| | Association | document | | | Association | document |
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
6.2. PPAG TLV 6.2. PPAG TLV
This document defines a new TLV for carrying additional information This document defines a new TLV for carrying additional information
of LSPs within a path protection association group. IANA is of LSPs within a path protection association group. IANA is
skipping to change at page 13, line 21 skipping to change at page 13, line 35
[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>.
[I-D.ietf-pce-association-group] [I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "PCEP Extensions for Dhody, D., and Y. Tanaka, "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft- Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-07 (work in progress), December ietf-pce-association-group-09 (work in progress), April
2018. 2019.
10.2. Informative References 10.2. Informative References
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/info/rfc4427>. <https://www.rfc-editor.org/info/rfc4427>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
skipping to change at page 14, line 20 skipping to change at page 14, line 37
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-09 (work in progress), October 2018. yang-11 (work in progress), March 2019.
[I-D.ietf-pce-association-diversity] [I-D.ietf-pce-association-diversity]
Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody, Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element communication Protocol (PCEP) "Path Computation Element communication Protocol (PCEP)
extension for signaling LSP diversity constraint", draft- extension for signaling LSP diversity constraint", draft-
ietf-pce-association-diversity-05 (work in progress), ietf-pce-association-diversity-06 (work in progress),
December 2018. February 2019.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-14 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
October 2018. March 2019.
[I-D.litkowski-pce-state-sync] [I-D.litkowski-pce-state-sync]
Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element communication Stateful Path Computation Element (PCE) Communication
procedures", draft-litkowski-pce-state-sync-04 (work in Procedures.", draft-litkowski-pce-state-sync-05 (work in
progress), October 2018. progress), March 2019.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
 End of changes. 37 change blocks. 
62 lines changed or deleted 68 lines changed or added

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