draft-ietf-pce-association-diversity-04.txt   draft-ietf-pce-association-diversity-05.txt 
PCE Working Group S. Litkowski PCE Working Group S. Litkowski
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: December 22, 2018 Cisco Systems, Inc. Expires: June 21, 2019 Cisco Systems, Inc.
C. Barth C. Barth
Juniper Networks Juniper Networks
D. Dhody D. Dhody
Huawei Huawei
June 20, 2018 December 18, 2018
Path Computation Element communication Protocol extension for signaling Path Computation Element communication Protocol (PCEP) extension for
LSP diversity constraint signaling LSP diversity constraint
draft-ietf-pce-association-diversity-04 draft-ietf-pce-association-diversity-05
Abstract Abstract
This document introduces a simple mechanism to associate a group of This document introduces a simple mechanism to associate a group of
Label Switched Paths (LSPs) via an extension to the Path Computation Label Switched Paths (LSPs) via an extension to the Path Computation
Element Communication Protocol (PCEP) with the purpose of computing Element (PCE) Communication Protocol (PCEP) with the purpose of
diverse paths for those LSPs. The proposed extension allows a PCC to computing diverse paths for those LSPs. The proposed extension
advertise to a PCE the belonging of a particular LSP to a disjoint- allows a Path Computation Client (PCC) to advertise to a PCE that a
group, thus the PCE knows that LSPs in the same group must be particular LSP belongs to a disjoint-group, thus the PCE knows that
disjoint from each other. LSPs in the same group needs to be disjoint from each other.
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 December 22, 2018. This Internet-Draft will expire on June 21, 2019.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol extension . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol extension . . . . . . . . . . . . . . . . . . . . . 7
4.1. Association group . . . . . . . . . . . . . . . . . . . . 7 4.1. Association group . . . . . . . . . . . . . . . . . . . . 7
4.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Disjointness objective functions . . . . . . . . . . . . 10 4.3. Disjointness objective functions . . . . . . . . . . . . 10
4.4. P-flag considerations . . . . . . . . . . . . . . . . . . 12 4.4. P-flag considerations . . . . . . . . . . . . . . . . . . 12
4.5. Disjointness computation issues . . . . . . . . . . . . . 14 4.5. Disjointness computation issues . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Association object Type Indicators . . . . . . . . . . . 15 6.1. Association object Type Indicators . . . . . . . . . . . 16
6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 16 6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 16
6.4. NO-PATH-VECTOR bit Flags . . . . . . . . . . . . . . . . 16 6.4. NO-PATH-VECTOR bit Flags . . . . . . . . . . . . . . . . 17
6.5. PCEP-ERROR codes . . . . . . . . . . . . . . . . . . . . 17 6.5. PCEP-ERROR codes . . . . . . . . . . . . . . . . . . . . 17
7. Manageability Considerations . . . . . . . . . . . . . . . . 17 7. Manageability Considerations . . . . . . . . . . . . . . . . 17
7.1. Control of Function and Policy . . . . . . . . . . . . . 17 7.1. Control of Function and Policy . . . . . . . . . . . . . 17
7.2. Information and Data Models . . . . . . . . . . . . . . . 17 7.2. Information and Data Models . . . . . . . . . . . . . . . 17
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 18
7.6. Impact On Network Operations . . . . . . . . . . . . . . 18 7.6. Impact On Network Operations . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
Protocol (PCEP) which enables the communication between a Path Protocol (PCEP) which enables the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655]. two PCEs based on the PCE architecture [RFC4655].
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
extensions to PCEP to enable active control of MPLS-TE and GMPLS extensions to PCEP to enable active control of MPLS-TE and GMPLS
skipping to change at page 3, line 20 skipping to change at page 3, line 20
[I-D.ietf-pce-association-group] introduces a generic mechanism to [I-D.ietf-pce-association-group] introduces a generic mechanism to
create a grouping of LSPs which can then be used to define create a grouping of LSPs which can then be used to define
associations between a set of LSPs and a set of attributes (such as associations between a set of LSPs and a set of attributes (such as
configuration parameters or behaviors) and is equally applicable to configuration parameters or behaviors) and is equally applicable to
the active and passive modes of a stateful PCE [RFC8231] or a the active and passive modes of a stateful PCE [RFC8231] or a
stateless PCE [RFC5440]. stateless PCE [RFC5440].
This document specifies a PCEP extension to signal that a particular This document specifies a PCEP extension to signal that a particular
group of LSPs should use diverse paths including the requested type group of LSPs should use diverse paths including the requested type
of diversity. A PCC can use this extension to signal to a PCE the of diversity. A PCC can use this extension to signal to a PCE that a
belonging of a particular LSP to a disjoint-group. When a PCE particular LSP belongs to a disjoint-group. When a PCE receives LSP
receives LSP states belonging to the same disjoint-group from some states belonging to the same disjoint-group from some PCCs, the PCE
PCCs, the PCE should ensure that the LSPs within the group are should ensure that the LSPs within the group are disjoint from each
disjoint from each other. other.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
skipping to change at page 8, line 9 skipping to change at page 8, line 9
association group. The Association parameters, as described in association group. The Association parameters, as described in
[I-D.ietf-pce-association-group] as the combination of the mandatory [I-D.ietf-pce-association-group] as the combination of the mandatory
fields Association type, Association ID and Association Source in the fields Association type, Association ID and Association Source in the
ASSOCIATION object, that uniquely identify the association group, ASSOCIATION object, that uniquely identify the association group,
uniquely identify the disjoint group. If the optional TLVs - Global uniquely identify the disjoint group. If the optional TLVs - Global
Association Source or Extended Association ID are included, then they Association Source or Extended Association ID are included, then they
are included in combination with mandatory fields to uniquely are included in combination with mandatory fields to uniquely
identifying the association group. This document defines a new identifying the association group. This document defines a new
Association type, based on the generic Association object - Association type, based on the generic Association object -
o Association type = TBD1 ("Disjointness Association Type"). o Association type = TBD1 ("Disjointness Association Type") for
Disjoint Association Group (DAG).
[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. Disjointness Association Type) MUST described in this document (i.e. Disjointness Association Type) MUST
be done before using the disjointness association. Thus the PCEP be done before using the disjointness association. Thus the PCEP
speaker MUST include the Disjointness Association Type (TBD1) in the speaker MUST include the Disjointness Association Type (TBD1) in the
ASSOC-Type-List TLV before using the disjoint association group in ASSOC-Type-List TLV before using the disjoint association group (DAG)
the PCEP messages. in the PCEP messages.
This association type is considered to be both dynamic and operator- This association type is considered to be both dynamic and operator-
configured in nature. The association group could be created by the configured in nature. The association group could be created by the
operator manually on the PCEP peers and the LSPs belonging to this operator manually on the PCEP peers and the LSPs belonging to this
associations is conveyed via PCEP messages to the PCEP peer; or the associations is conveyed via PCEP messages to the PCEP peer; or the
association group could be created dynamically by the PCEP speaker association group could be created dynamically by the PCEP speaker
and both the association group information and the LSPs belonging to and both the association group information and the LSPs belonging to
the association group is conveyed to the PCEP peer. The Operator- the association group is conveyed to the PCEP peer. The Operator-
configured Association Range MUST be set for this association-type to configured Association Range MUST be set for this association-type to
mark a range of association identifiers that are used for operator- mark a range of association identifiers that are used for operator-
skipping to change at page 15, line 44 skipping to change at page 15, line 44
SHOULD NOT try to compute disjointness path and SHOULD reply a PCErr SHOULD NOT try to compute disjointness path and SHOULD reply a PCErr
with Error-type 26 (Association Error) and Error-Value 6 (Association with Error-type 26 (Association Error) and Error-Value 6 (Association
information mismatch) to all PCCs involved in the disjoint group. information mismatch) to all PCCs involved in the disjoint group.
5. Security Considerations 5. Security Considerations
This document defines one new type for association, which do not add This document defines one new type for association, which do not add
any new security concerns beyond those discussed in [RFC5440], any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [I-D.ietf-pce-association-group] in itself. [RFC8231] and [I-D.ietf-pce-association-group] in itself.
As stated in [I-D.ietf-pce-association-group], much of the
information carried in the Disjointness Association object, as per
this document is not extra sensitive. It often reflects information
that can also be derived from the LSP Database, but association
provides a much easier grouping of related LSPs and messages. The
disjointness association could provides an adversary with the
opportunity to eavesdrop on the relationship between the LSPs. Thus
securing the PCEP session using Transport Layer Security (TLS)
[RFC8253], as per the recommendations and best current practices in
[RFC7525], is RECOMMENDED.
6. IANA Considerations 6. IANA Considerations
6.1. Association object Type Indicators 6.1. Association object Type Indicators
This document defines the following new association type originally This document defines the following new association type originally
defined in [I-D.ietf-pce-association-group]. defined in [I-D.ietf-pce-association-group].
Value Name Reference Value Name Reference
TBD1 Disjoint-group TBD1 Disjoint-group
skipping to change at page 19, line 28 skipping to change at page 19, line 41
Constraints in the Path Computation Element Communication Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>. <https://www.rfc-editor.org/info/rfc7470>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[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>.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Orange
skipping to change at page 20, line 4 skipping to change at page 20, line 25
EMail: stephane.litkowski@orange.com EMail: stephane.litkowski@orange.com
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
Colby Barth Colby Barth
Juniper Networks Juniper Networks
EMail: cbarth@juniper.net EMail: cbarth@juniper.net
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Divyashree Techno Park, Whitefield
Bangalore, KA 560066
India
EMail: dhruv.dhody@huawei.com EMail: dhruv.ietf@gmail.com
 End of changes. 17 change blocks. 
25 lines changed or deleted 54 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/