draft-ietf-pce-applicability-actn-10.txt   draft-ietf-pce-applicability-actn-11.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft Y. Lee Internet-Draft Y. Lee
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: September 9, 2019 D. Ceccarelli Expires: October 8, 2019 D. Ceccarelli
Ericsson Ericsson
March 08, 2019 April 6, 2019
Applicability of the Path Computation Element (PCE) to the Abstraction Applicability of the Path Computation Element (PCE) to the Abstraction
and Control of TE Networks (ACTN) and Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-10 draft-ietf-pce-applicability-actn-11
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control and virtual network (VN) operations needed to orchestrate, control and
manage large-scale multi-domain TE networks so as to facilitate manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function end-to-end virtual service aware connectivity and network function
virtualization services. virtualization services.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 9, 2019. This Internet-Draft will expire on October 8, 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 7, line 28 skipping to change at page 7, line 28
o Virtual service coordination o Virtual service coordination
Section 3 of [RFC8453] describes these functions. Section 3 of [RFC8453] describes these functions.
It should be noted that this document lists all possible ways in It should be noted that this document lists all possible ways in
which PCE could be used for each of the above functions, but all which PCE could be used for each of the above functions, but all
functions are not required to be implemented via PCE. Similarly, functions are not required to be implemented via PCE. Similarly,
this document presents the ways in which PCEP could be used as the this document presents the ways in which PCEP could be used as the
communications medium between functional components. Operators may communications medium between functional components. Operators may
choose to use the PCEP for multi-domain coordination via stateful choose to use the PCEP for multi-domain coordination via stateful
H-PCE, but alternatively use RESTCONF [RFC8040] or BGP-LS [RFC7752] H-PCE, but alternatively use NETCONF [RFC6241], RESTCONF [RFC8040],
to get access to the topology and support abstraction function. or BGP-LS [RFC7752] to get access to the topology and support
abstraction function.
3.1. Multi-Domain Coordination via Hierarchy 3.1. Multi-Domain Coordination via Hierarchy
With the definition of domain being "everything that is under the With the definition of domain being "everything that is under the
control of the single logical controller", as per [RFC8453], it is control of the single logical controller", as per [RFC8453], it is
needed to have a control entity that oversees the specific aspects of needed to have a control entity that oversees the specific aspects of
the different domains and to build a single abstracted end-to-end the different domains and to build a single abstracted end-to-end
network topology in order to coordinate end-to-end path computation network topology in order to coordinate end-to-end path computation
and path/service provisioning. and path/service provisioning.
skipping to change at page 11, line 18 skipping to change at page 11, line 18
and the functions as set out in the ACTN framework [RFC8453]. Its and the functions as set out in the ACTN framework [RFC8453]. Its
recursive nature is well suited via the multi-level hierarchy of PCE. recursive nature is well suited via the multi-level hierarchy of PCE.
PCEP can also be applied to the CMI as the CNC can be a path PCEP can also be applied to the CMI as the CNC can be a path
computation client while the MDSC can be a path computation server. computation client while the MDSC can be a path computation server.
Section 5 describes how PCE and PCEP could help realize ACTN on the Section 5 describes how PCE and PCEP could help realize ACTN on the
MPI. MPI.
5. Realizing ACTN with PCE (and PCEP) 5. Realizing ACTN with PCE (and PCEP)
As per the example in Figure 2, there are 4 domains, each with its As per the example in Figure 2, there are 4 domains, each with its
own PNC and an MDSC on top. The PNC and MDSC need PCE as a important own PNC and an MDSC on top. The PNC and MDSC need PCE as an
function. The PNC (or Child PCE) already uses PCEP to communicate to important function. The PNC (or Child PCE) already uses PCEP to
the network device. It can utilize the PCEP as the MPI to communicate to the network device. It can utilize the PCEP as the
communicate between controllers too. MPI to communicate between controllers too.
****** ******
..........*MDSC*.............................. ..........*MDSC*..............................
. ****** .. MPI . . ****** .. MPI .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
skipping to change at page 13, line 36 skipping to change at page 13, line 36
MDSC (or Parent PCE) triggers the end to end path computation MDSC (or Parent PCE) triggers the end to end path computation
for these two paths. MDSC can do path computation based on the for these two paths. MDSC can do path computation based on the
abstracted domain topology that it already has or it may use abstracted domain topology that it already has or it may use
the H-PCE procedures (Section 3.1) using the PCReq and PCRep the H-PCE procedures (Section 3.1) using the PCReq and PCRep
messages to get the end to end path with the help of the Child messages to get the end to end path with the help of the Child
PCEs (PNC). Either way, the resultant E2E paths may be broken PCEs (PNC). Either way, the resultant E2E paths may be broken
into per-domain paths. into per-domain paths.
* A-B: (A-B13,B13-B31,B31-B) * A-B: (A-B13,B13-B31,B31-B)
* A-C: (A-B13,B13-B31,B34-B43,B43-C) * A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C)
* Per Domain Path Instantiation: Based on the above path * Per Domain Path Instantiation: Based on the above path
computation, MDSC can issue the path instantiation request to computation, MDSC can issue the path instantiation request to
each PNC via PCInitiate message (see each PNC via PCInitiate message (see
[I-D.ietf-pce-stateful-hpce] and [I-D.ietf-pce-stateful-hpce] and
[I-D.leedhody-pce-vn-association]). A suitable stitching [I-D.leedhody-pce-vn-association]). A suitable stitching
mechanism would be used to stitch these per domain LSPs. One mechanism would be used to stitch these per domain LSPs. One
such mechanism is described in such mechanism is described in
[I-D.dugeon-pce-stateful-interdomain], where PCEP is extended [I-D.dugeon-pce-stateful-interdomain], where PCEP is extended
to support stitching in stateful H-PCE context. to support stitching in stateful H-PCE context.
skipping to change at page 14, line 35 skipping to change at page 14, line 35
removed (via PCInitiate message). removed (via PCInitiate message).
o VN Update (based on network changes): Any change in the per-domain o VN Update (based on network changes): Any change in the per-domain
LSP is reported to the MDSC (via PCRpt message) as per LSP is reported to the MDSC (via PCRpt message) as per
[I-D.ietf-pce-stateful-hpce]. This may result in changes in the [I-D.ietf-pce-stateful-hpce]. This may result in changes in the
E2E path or VN status. This may also trigger a re-optimization E2E path or VN status. This may also trigger a re-optimization
leading to a new per-domain path, update to existing path, or leading to a new per-domain path, update to existing path, or
deletion of the path. deletion of the path.
o VN Protection: The VN protection/restoration requirements, need to o VN Protection: The VN protection/restoration requirements, need to
applied to each E2E path as well as each per domain path. The be applied to each E2E path as well as each per domain path. The
MDSC needs to play a crucial role in coordinating the right MDSC needs to play a crucial role in coordinating the right
protection/restoration policy across each PNC. The existing protection/restoration policy across each PNC. The existing
protection/restoration mechanism of PCEP can be applied on each protection/restoration mechanism of PCEP can be applied on each
path. path.
o In case PNC generates an abstract topology to the MDSC, the o In case a PNC generates an abstract topology towards the MDSC, the
PCInitiate/PCUpd messages from the MDSC to a PNC will contain a PCInitiate/PCUpd messages from the MDSC to a PNC will contain a
path with abstract nodes and links. PNC would need to take that path with abstract nodes and links. A PNC would need to take that
as an input for path computation to get a path with physical nodes as an input for path computation to get a path with physical nodes
and links. Similarly, a PNC would convert the path received from and links. Similarly, a PNC would convert the path received from
the device (with physical nodes and links) into abstract path the device (with physical nodes and links) into an abstract path
(based on the abstract topology generated before with abstract (based on the abstract topology generated before with abstract
nodes and links) and reported to the MDSC. nodes and links) and report it to the MDSC.
6. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
7. Security Considerations 7. Security Considerations
Various security considerations for PCEP are described in [RFC5440], Various security considerations for PCEP are described in [RFC5440],
[RFC6952], and [RFC8253]. Further, this document lists various [RFC6952], and [RFC8253]. Further, this document lists various
extensions of PCEP that are applicable, each of them specify various extensions of PCEP that are applicable, each of them specify various
skipping to change at page 16, line 16 skipping to change at page 16, line 16
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Jonathan Hardwick for the inspiration The authors would like to thank Jonathan Hardwick for the inspiration
behind this document. Further thanks to Avantika for her comments behind this document. Further thanks to Avantika for her comments
with suggested text. with suggested text.
Thanks to Adrian Farrel and Daniel King for their substantial Thanks to Adrian Farrel and Daniel King for their substantial
reviews. reviews.
Thanks to Yingzhen Qu for RTGDIR reviews.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
skipping to change at page 17, line 38 skipping to change at page 17, line 43
Procedure to Compute Shortest Constrained Inter-Domain Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009, DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>. <https://www.rfc-editor.org/info/rfc5441>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS "Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>. September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
skipping to change at page 19, line 47 skipping to change at page 20, line 6
draft-lee-pce-pcep-ls-optical-07 (work in progress), March draft-lee-pce-pcep-ls-optical-07 (work in progress), March
2019. 2019.
[I-D.leedhody-pce-vn-association] [I-D.leedhody-pce-vn-association]
Lee, Y., Zhang, X., and D. Ceccarelli, "PCEP Extensions Lee, Y., Zhang, X., and D. Ceccarelli, "PCEP Extensions
for Establishing Relationships Between Sets of LSPs and for Establishing Relationships Between Sets of LSPs and
Virtual Networks", draft-leedhody-pce-vn-association-07 Virtual Networks", draft-leedhody-pce-vn-association-07
(work in progress), February 2019. (work in progress), February 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.
[I-D.ietf-pce-association-policy] [I-D.ietf-pce-association-policy]
Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J.,
and M. Negi, "Path Computation Element communication and M. Negi, "Path Computation Element communication
Protocol extension for associating Policies and LSPs", Protocol extension for associating Policies and LSPs",
draft-ietf-pce-association-policy-05 (work in progress), draft-ietf-pce-association-policy-05 (work in progress),
February 2019. February 2019.
[I-D.dugeon-pce-stateful-interdomain] [I-D.dugeon-pce-stateful-interdomain]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
 End of changes. 15 change blocks. 
20 lines changed or deleted 28 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/