< draft-leedhody-pce-vn-association-07.txt   draft-leedhody-pce-vn-association-08.txt >
PCE Working Group Y. Lee PCE Working Group Y. Lee
Internet-Draft X. Zhang Internet-Draft Futurewei
Intended Status: Standards track Huawei Technologies Intended Status: Standards track X. Zhang
Expires: August 09, 2019 D. Ceccarelli Expires: December 21, 2019 Huawei Technologies
D. Ceccarelli
Ericsson Ericsson
February 05, 2019
PCEP Extensions for Establishing Relationships Between Sets of LSPs June 19, 2019
and Virtual Networks
draft-leedhody-pce-vn-association-07 Path Computation Element communication Protocol (PCEP) extensions
for Establishing Relationships between sets of LSPs and Virtual
Networks
draft-leedhody-pce-vn-association-08
Abstract Abstract
This document describes how to extend Path Computation Element (PCE) This document describes how to extend Path Computation Element (PCE)
Communication Protocol (PCEP) association mechanism introduced by the Communication Protocol (PCEP) association mechanism introduced by the
PCEP Association Group specification, to further associate sets of PCEP Association Group specification, to further associate sets of
LSPs with a higher-level structure such as a virtual network (VN) LSPs with a higher-level structure such as a virtual network (VN)
requested by clients or applications. This extended association requested by clients or applications. This extended association
mechanism can be used to facilitate virtual network control using PCE mechanism can be used to facilitate virtual network control using PCE
architecture. architecture.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
https://www.ietf.org/ietf/1id-abstracts.txt https://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html https://www.ietf.org/shadow.html
This Internet-Draft will expire on August 09, 2019. This Internet-Draft will expire on December 21, 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
(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...................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language.....................................3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Terminology....................................................4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation Overview.............................................4 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Extensions to PCEP.............................................4 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 7
5. Applicability to H-PCE architecture............................6 5. Applicability to H-PCE architecture . . . . . . . . . . . . . . 8
6. Security Considerations........................................7 6. Implementation Status . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations............................................7 6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 9
7.1. Association Object Type Indicator.........................7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
7.2. PCEP TLV Type Indicator...................................8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7.3. PCEP Error................................................8 8.1. Association Object Type Indicator . . . . . . . . . . . . . 10
8. References.....................................................8 8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . . 10
8.1. Normative References......................................8 8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References....................................9 9. Manageability Considerations . . . . . . . . . . . . . . . . . 11
Author's Addresses................................................9 9.1. Control of Function and Policy . . . . . . . . . . . . . . 11
9.2. Information and Data Models . . . . . . . . . . . . . . . 11
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 11
9.6. Impact On Network Operations . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Path Computation Element communication Protocol (PCEP) provides The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients' (PCCs) computations in response to Path Computation Clients' (PCCs)
requests. requests.
[RFC8051] describes general considerations for a stateful PCE [RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits, as well as
skipping to change at page 5, line 34 skipping to change at page 5, line 34
minimize the load of the most loaded link (MLL) [RFC5541] and minimize the load of the most loaded link (MLL) [RFC5541] and
other could be applied for all the LSP belonging to the same VN, other could be applied for all the LSP belonging to the same VN,
identified by the VN association. identified by the VN association.
o Path Re-Optimization: The child PCE or the parent PCE would like o Path Re-Optimization: The child PCE or the parent PCE would like
to use advanced path computation algorithm and optimization to use advanced path computation algorithm and optimization
technique that consider all the LSPs belonging to a VN/customer technique that consider all the LSPs belonging to a VN/customer
and optimize them all together during the re-optimization. and optimize them all together during the re-optimization.
This association is useful in PCEP session between parent PCE This association is useful in PCEP session between parent PCE
(MDSC) and child PCE (PNC). (MDSC) and child PCE (PNC). The figure describes a typical VN
operations using PCEP for illustration purpose.
****** ******
..........*MDSC*.............................. ..........*MDSC*..............................
. ****** .. MPI . . ****** .. MPI .
. . . PCEP . . . . PCEP .
. . . PCInitiate LSPx . . . . PCInitiate LSPx .
. . . with VNAG = 10 . . . . with VNAG = 10 .
. . . . . . . .
. . . . . . . .
. . . . . . . .
skipping to change at page 6, line 51 skipping to change at page 6, line 51
o VN Association Group (VNAG) o VN Association Group (VNAG)
One new Association type is defined as described in the Association One new Association type is defined as described in the Association
object - object -
o Association type = TBD1 ("VN Association") for VNAG o Association type = TBD1 ("VN Association") for VNAG
The scope and handling of VNAG identifier is similar to the generic The scope and handling of VNAG identifier is similar to the generic
association identifier defined in [I-D.ietf-pce-association-group]. association identifier defined in [I-D.ietf-pce-association-group].
In this document VNAG object refers to an Association Object with the
Association type set to "VNAG".
Local polices on the PCE MAY define the computational and Local polices on the PCE MAY define the computational and
optimization behavior for the LSPs in the VN. An LSP MUST belong to a optimization behavior for the LSPs in the VN. An LSP MUST NOT belong
single VNAG. If an implementation encounters more than one VNAG, it to more than one VNAG. If an implementation encounters more than one
MUST consider the first occurrence and ignore the others. VNAG, it MUST consider the first occurrence and ignore the others.
[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. VN Association Type) MUST be done described in this document (i.e. VN Association Type) MUST be done
before using the policy association. Thus the PCEP speaker MUST before using the policy association. Thus the PCEP speaker MUST
include the VN Association Type (TBD1) in the ASSOC-Type-List TLV include the VN Association Type (TBD1) in the ASSOC-Type-List TLV
before using the VNAG in the PCEP messages. before using the VNAG in the PCEP messages.
skipping to change at page 9, line 24 skipping to change at page 9, line 26
client's request), the parent PCE sends an PCUpd Message to inform client's request), the parent PCE sends an PCUpd Message to inform
each affected child PCE of this change. each affected child PCE of this change.
The Child PCE could then use this association to optimize all LSPs The Child PCE could then use this association to optimize all LSPs
belonging to the same VN association together. The Child PCE could belonging to the same VN association together. The Child PCE could
further take VN specific actions on the LSPs such as relaxation of further take VN specific actions on the LSPs such as relaxation of
constraints, policy actions, setting default behavior etc. The parent constraints, policy actions, setting default behavior etc. The parent
PCE could also maintain all E2E LSP or per-domain path segments under PCE could also maintain all E2E LSP or per-domain path segments under
a single VN association. a single VN association.
6. Security Considerations 6. Implementation Status
This document defines one new type for association, which do not add [Note to the RFC Editor - remove this section before publication, as
any new security concerns beyond those discussed in [RFC5440], well as remove the reference to RFC 7942.]
[RFC8231] and [I-D.ietf-pce-association-group] in itself.
Some deployments may find VN associations and their implications as This section records the status of known implementations of the
extra sensitive and thus should employ suitable PCEP security protocol defined by this specification at the time of posting of this
mechanisms like TCP-AO [RFC5925] or [RFC8253]. Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
7. IANA Considerations According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. It
is up to the individual working groups to use this information as
they see fit".
7.1. Association Object Type Indicator 6.1. Huawei's Proof of Concept based on ONOS
The PCE function was developed in the ONOS open source platform. This
extension was implemented on a private version as a proof of concept
to ACTN.
This document defines a new association type, originally defined in o Organization: Huawei
[I-D.ietf-pce-association-group], for path protection. IANA is
requested to make the assignment of a new value for the sub-registry o Implementation: Huawei's PoC based on ONOS
"ASSOCIATION Type Field" (request to be created in [I-D.ietf-pce-
association-group]), as follows: o Description: PCEP as a southbound plugin was added to ONOS. To
support ACTN, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol
o Maturity Level: Prototype
o Coverage: Full
o Contact: satishk@huawei.com
7. Security Considerations
This document defines one new type for association, which do not
add any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [I-D.ietf-pce-association-group] in itself.
Some deployments may find the Virtual Network Name and the VN
associations as extra sensitive; and thus should employ suitable
PCEP security mechanisms like TCP-AO [RFC5925] or [RFC8253].
8. IANA Considerations
8.1. Association Object Type Indicator
This document defines a new association type, originally defined
in [I-D.ietf-pce-association-group], for path protection. IANA is
requested to make the assignment of a new value for the sub-
registry "ASSOCIATION Type Field" (request to be created in [I-
D.ietf-pce-association-group]), as follows:
Value Name Reference Value Name Reference
TBD1 VN Association Type [This I.D.] TBD1 VN Association Type [This I.D.]
7.2. PCEP TLV Type Indicator 8.2. PCEP TLV Type Indicator
This document defines a new TLV for carrying additional information This document defines a new TLV for carrying additional
of LSPs within a path protection association group. IANA is information of LSPs within a path protection association group.
requested to make the assignment of a new value for the existing IANA is requested to make the assignment of a new value for the
"PCEP TLV Type Indicators" registry as follows: existing "PCEP TLV Type Indicators" registry as follows:
Value Name Reference Value Name Reference
TBD2 VIRTUAL-NETWORK-TLV [This I.D.] TBD2 VIRTUAL-NETWORK-TLV [This I.D.]
7.3. PCEP Error 8.3. PCEP Error
This document defines new Error-Type and Error-Value related to path This document defines new Error-Type and Error-Value related to
protection association. IANA is requested to allocate new error path protection association. IANA is requested to allocate new
values within the "PCEP-ERROR Object Error Types and Values" sub- error values within the "PCEP-ERROR Object Error Types and Values"
registry of the PCEP Numbers registry, as follows: sub- registry of the PCEP Numbers registry, as follows:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
I.D.] I.D.]
8. Manageability Considerations 9. Manageability Considerations
8.1. Control of Function and Policy 9.1. Control of Function and Policy
An operator MUST BE allowed to mark LSPs that belong to the same VN. An operator MUST BE allowed to mark LSPs that belong to the same
This could also be done automatically based on the VN configuration. VN. This could also be done automatically based on the VN
configuration.
8.2. Information and Data Models 9.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
association between LSPs including VN association. association between LSPs including VN association.
8.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
8.4. Verify Correct Operations 9.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440]. [RFC5440].
8.5. Requirements On Other Protocols 9.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new
on other protocols. requirements on other protocols.
8.6. Impact On Network Operations 9.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network Mechanisms defined in this document do not have any impact on
operations in addition to those already listed in [RFC5440]. network operations in addition to those already listed in
[RFC5440].
9. References 10. References
9.1. Normative References 10.1. Normative References
[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, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997. 10.17487/RFC2119, March 1997.
[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,
March 2009. March 2009.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 11, line 36 skipping to change at page 12, line 36
[RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP [RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP
Extensions for Stateful PCE", RFC 8231, September 2017. Extensions for Stateful PCE", RFC 8231, September 2017.
[RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP [RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP
Setup in a Stateful PCE Model", RFC 8281, December 2017. Setup in a Stateful PCE Model", RFC 8281, December 2017.
[I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft- Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group, work in progress. ietf-pce-association-group, work in progress.
9.2. Informative References 10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6805] A. Farrel and D. King, "The Application of the Path [RFC6805] A. Farrel and D. King, "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.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, RFC
7942, DOI 10.17487/RFC7942, July 2016.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, <https://www.rfc- DOI 10.17487/RFC8453, August 2018, <https://www.rfc-
editor.org/info/rfc8453>. editor.org/info/rfc8453>.
[I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D. [I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D.
Ceccarelli, "Applicability of Path Computation Element Ceccarelli, "Applicability of Path Computation Element
(PCE) for Abstraction and Control of TE Networks (ACTN)", (PCE) for Abstraction and Control of TE Networks (ACTN)",
draft-ietf-pce-applicability-actn, work-in-progress. draft-ietf-pce-applicability-actn, work-in-progress.
skipping to change at page 13, line 24 skipping to change at page 14, line 24
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Author's Addresses Author's Addresses
Young Lee Young Lee
Huawei Technologies Futurewei
5340 Legacy Drive, Building 3 5340 Legacy Drive, Building 3
Plano, TX 75023, Plano, TX 75023,
USA USA
Email: leeyoung@huawei.com Email: younglee.tx@gmail.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
China China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
 End of changes. 38 change blocks. 
78 lines changed or deleted 143 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/