rfc9689xml2.original.xml | rfc9689.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version="1.0" encoding="utf-8"?> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.2119.xml"> | ||||
<!ENTITY RFC4206 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4206.xml"> | ||||
<!ENTITY RFC5150 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5150.xml"> | ||||
<!ENTITY RFC5151 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5151.xml"> | ||||
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5440.xml"> | ||||
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5441.xml"> | ||||
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5541.xml"> | ||||
<!ENTITY RFC5376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.5376.xml"> | ||||
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8174.xml"> | ||||
<!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8231.xml"> | ||||
<!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8281.xml"> | ||||
<!ENTITY RFC8283 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8283.xml"> | ||||
<!ENTITY RFC8355 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8355.xml"> | ||||
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8402.xml"> | ||||
<!ENTITY RFC4364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4364.xml"> | ||||
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7432.xml"> | ||||
<!ENTITY RFC3985 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.3985.xml"> | ||||
<!ENTITY RFC7665 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7665.xml"> | ||||
<!ENTITY RFC8279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8279.xml"> | ||||
<!ENTITY RFC8986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8986.xml"> | ||||
<!ENTITY RFC9168 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9168.xml"> | ||||
<!ENTITY RFC8821 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8821.xml"> | ||||
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4655.xml"> | ||||
<!ENTITY RFC7399 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7399.xml"> | ||||
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8253.xml"> | ||||
<!ENTITY RFC7491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7491.xml"> | ||||
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9256.xml"> | ||||
<!ENTITY RFC9012 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9012.xml"> | ||||
<!ENTITY RFC8300 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8300.xml"> | ||||
<!ENTITY I-D.chen-pce-bier SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/r | ||||
eference.I-D.chen-pce-bier.xml"> | ||||
<!ENTITY RFC8664 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8664.xml"> | ||||
<!ENTITY RFC8751 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8751.xml"> | ||||
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8754.xml"> | ||||
<!ENTITY RFC7025 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.7025.xml"> | ||||
<!ENTITY RFC9087 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9087.xml"> | ||||
<!ENTITY RFC9262 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9262.xml"> | ||||
<!ENTITY RFC9491 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9491.xml"> | ||||
<!ENTITY RFC9522 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9522.xml"> | ||||
<!ENTITY RFC9552 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9552.xml"> | ||||
<!ENTITY RFC8955 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8955.xml"> | ||||
<!ENTITY RFC4456 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.4456.xml"> | ||||
<!ENTITY RFC8408 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.8408.xml"> | ||||
<!ENTITY I-D.li-pce-controlled-id-space SYSTEM "https://xml2rfc.ietf.org/public/ | ||||
rfc/bibxml3/reference.I-D.li-pce-controlled-id-space.xml"> | ||||
<!ENTITY I-D.ietf-pce-stateful-interdomain SYSTEM "https://xml2rfc.ietf.org/publ | ||||
ic/rfc/bibxml3/reference.I-D.ietf-pce-stateful-interdomain.xml"> | ||||
<!ENTITY RFC9050 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
C.9050.xml"> | ||||
<!ENTITY I-D.ietf-pce-pcep-extension-pce-controller-sr SYSTEM "https://xml2rfc.i | ||||
etf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-extension-pce-controller- | ||||
sr.xml"> | ||||
<!ENTITY I-D.cbrt-pce-stateful-local-protection SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.cbrt-pce-stateful-local-protection.xml"> | ||||
<!ENTITY I-D.ietf-pce-segment-routing-ipv6 SYSTEM "https://xml2rfc.ietf.org/publ | ||||
ic/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-ipv6.xml"> | ||||
<!ENTITY I-D.ietf-spring-sr-service-programming SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-service-programming.xml"> | ||||
<!ENTITY I-D.ietf-pce-segment-routing-policy-cp SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-policy-cp.xml"> | ||||
<!ENTITY I-D.ietf-spring-segment-routing-policy SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml"> | ||||
<!ENTITY I-D.ietf-idr-segment-routing-te-policy SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-idr-segment-routing-te-policy.xml"> | ||||
<!ENTITY I-D.ietf-pce-binding-label-sid SYSTEM "https://xml2rfc.ietf.org/public | ||||
/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid.xml"> | ||||
<!ENTITY I-D.chen-pce-pcep-extension-pce-controller-bier SYSTEM "https://xml2rf | ||||
c.ietf.org/public/rfc/bibxml3/reference.I-D.chen-pce-pcep-extension-pce-controll | ||||
er-bier.xml"> | ||||
<!ENTITY I-D.ietf-pce-pcep-extension-native-ip SYSTEM "https://xml2rfc.ietf.org | ||||
/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-extension-native-ip.xml"> | ||||
<!ENTITY I-D.dhody-pce-pcep-extension-pce-controller-srv6 SYSTEM "https://xml2r | ||||
fc.ietf.org/public/rfc/bibxml3/reference.I-D.dhody-pce-pcep-extension-pce-contro | ||||
ller-srv6.xml"> | ||||
<!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "https://xml2rfc.ietf.org/public/rf | ||||
c/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml"> | ||||
<!ENTITY RFC1195 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.1195.xml"> | ||||
<!ENTITY RFC2328 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.2328.xml"> | ||||
<!ENTITY RFC5340 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.5340.xml"> | ||||
<!ENTITY RFC8735 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.8735.xml"> | ||||
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.3209.xml"> | ||||
<!ENTITY RFC5036 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.5036.xml"> | ||||
<!ENTITY RFC9262 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.9262.xml"> | ||||
<!DOCTYPE rfc [ | ||||
<!ENTITY nbsp " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<rfc submissionType="IETF" docName="draft-ietf-teas-pcecc-use-cases-18" category | ||||
="info" ipr="trust200902"><?rfc compact="yes"?> | ||||
<?rfc text-list-symbols="oo*+-"?> | ||||
<?rfc subcompact="no"?> | ||||
<?rfc sortrefs="yes"?> | ||||
<?rfc symrefs="yes"?> | ||||
<?rfc strict="yes"?> | ||||
<?rfc toc="yes"?> | ||||
<front> | ||||
<title abbrev="PCECC">Use Cases for a PCE as a Central Controller (PCECC) | ||||
</title> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d | ||||
raft-ietf-teas-pcecc-use-cases-18" number="9689" category="info" consensus="true | ||||
" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRef | ||||
s="true" tocInclude="true" version="3"> | ||||
<front> | ||||
<title abbrev="PCECC">Use Cases for a PCE as a Central Controller (PCECC)</t | ||||
itle> | ||||
<seriesInfo name="RFC" value="9689"/> | ||||
<author fullname="Zhenbin (Robin) Li" initials="Z." surname="Li"> | <author fullname="Zhenbin (Robin) Li" initials="Z." surname="Li"> | |||
<organization>Huawei Technologies</organization> | <organization>Huawei Technologies</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Huawei Bld., No.156 Beiqing Rd.</street> | <street>Huawei Bld., No.156 Beiqing Rd.</street> | |||
<city>Beijing</city> | <city>Beijing</city> | |||
<region></region> | ||||
<code>100095</code> | <code>100095</code> | |||
<country>China</country> | <country>China</country> | |||
</postal> | </postal> | |||
<email>lizhenbin@huawei.com</email> | <email>lizhenbin@huawei.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> | ||||
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> | <organization>Huawei Technologies</organization> | |||
<organization>Huawei Technologies</organization> | ||||
<address> | <address> | |||
<postal> | <postal> | |||
<street></street> | ||||
<city></city> | ||||
<region></region> | ||||
<country>India</country> | <country>India</country> | |||
</postal> | </postal> | |||
<email>dhruv.ietf@gmail.com</email> | <email>dhruv.ietf@gmail.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="Q" | <author initials="Q" surname="Zhao" fullname="Quintin Zhao"> | |||
surname="Zhao" | ||||
fullname="Quintin Zhao"> | ||||
<organization>Etheric Networks</organization> | <organization>Etheric Networks</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>1009 S CLAREMONT ST</street> | <street>1009 S Claremont St.</street> | |||
<city>SAN MATEO</city> | <city>San Mateo</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>94402</code> | <code>94402</code> | |||
<country>USA</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>qzhao@ethericnetworks.com</email> | <email>qzhao@ethericnetworks.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="King He" initials="K." surname="He"> | <author fullname="King He" initials="K." surname="He"> | |||
<organization>Tencent Holdings Ltd.</organization> | <organization>Tencent Holdings Ltd.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street></street> | ||||
<city>Shenzhen</city> | <city>Shenzhen</city> | |||
<region></region> | ||||
<country>China</country> | <country>China</country> | |||
</postal> | </postal> | |||
<email>kinghe@tencent.com</email> | <email>kinghe@tencent.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Boris Khasanov" initials="B." surname="Khasanov"> | <author fullname="Boris Khasanov" initials="B." surname="Khasanov"> | |||
<organization>Yandex LLC</organization> | <organization>Yandex LLC</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Ulitsa Lva Tolstogo 16</street> | <street>Ulitsa Lva Tolstogo 16</street> | |||
<city>Moscow</city> | <city>Moscow</city> | |||
<region></region> | <country>Russian Federation</country> | |||
<code></code> | ||||
<country>Russia</country> | ||||
</postal> | </postal> | |||
<email>bhassanov@yahoo.com</email> | <email>bhassanov@yahoo.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<!--<author fullname="Luyuan Fang" initials="L." surname="Fang"> | ||||
<!-- [auth] | ||||
<author fullname="Luyuan Fang" initials="L." surname="Fang"> | ||||
<organization>Expedia, Inc.</organization> | <organization>Expedia, Inc.</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street></street> | <street></street> | |||
<city></city> | <city></city> | |||
<region></region> | <region></region> | |||
<country>USA</country> | <country>USA</country> | |||
</postal> | </postal> | |||
<email>luyuanf@gmail.com</email> | <email>luyuanf@gmail.com</email> | |||
</address> | </address> | |||
skipping to change at line 222 ¶ | skipping to change at line 143 ¶ | |||
<street>Krasnoarmeyskaya str., 24</street> | <street>Krasnoarmeyskaya str., 24</street> | |||
<city>Minsk</city> | <city>Minsk</city> | |||
<code>220030</code> | <code>220030</code> | |||
<region></region> | <region></region> | |||
<country>Belarus</country> | <country>Belarus</country> | |||
</postal> | </postal> | |||
<email>anton.gulida@life.com.by</email> | <email>anton.gulida@life.com.by</email> | |||
</address> | </address> | |||
</author> --> | </author> --> | |||
<date/> | <date month="November" year="2024"/> | |||
<workgroup>TEAS Working Group</workgroup> | <area>RTG</area> | |||
<abstract> | <workgroup>teas</workgroup> | |||
<t>The PCE is a core component of | ||||
a Software-Defined Networking (SDN) system. It can be used to compute optima | ||||
l paths for network traffic and update existing paths to reflect | ||||
changes in the network or traffic demands. PCE was developed to | ||||
derive traffic-engineered paths in MPLS networks, | ||||
which are supplied to the head end of the paths using the Path | ||||
Computation Element Communication Protocol (PCEP).</t> | ||||
<t>SDN has much broader applicability than signaled MPLS traffic-engineered | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
(TE) networks, and the PCE may be used to determine paths in a range | the title) for use on https://www.rfc-editor.org/search. --> | |||
of use cases including static LSPs, Segment Routing (SR), Service Function | ||||
Chaining (SFC), and most forms of a routed or switched network. It | ||||
is, therefore, reasonable to consider PCEP as a control protocol for | ||||
use in these environments to allow the PCE to be fully enabled as a | ||||
central controller.</t> | ||||
<t>A PCE as a Central Controller (PCECC) can simplify the processing of | <keyword>example</keyword> | |||
a distributed control plane by blending it with elements of SDN | ||||
without necessarily completely replacing it. This document describes | ||||
general considerations for PCECC deployment and examines its | ||||
applicability and benefits, as well as its challenges and | ||||
limitations, through a number of use cases. | ||||
PCEP extensions which are required for the PCECC use cases are | ||||
covered in separate documents.</t> | ||||
<!--<t>This is a living document to catalog the use cases for PCECC. There is | <abstract> | |||
currently no intention to publish this work as an RFC. [Update: Chairs are eval | <t>The PCE is a core component of a Software-Defined Networking (SDN) | |||
uating if the document should be published instead.]</t>--> | system. It can be used to compute optimal paths for network traffic and | |||
update existing paths to reflect changes in the network or traffic | ||||
demands. The PCE was developed to derive traffic-engineered (TE) paths in | ||||
MPLS | ||||
networks, which are supplied to the head end of the paths using the Path | ||||
Computation Element Communication Protocol (PCEP).</t> | ||||
<t>SDN has much broader applicability than signalled MPLS | ||||
TE networks, and the PCE may be used to determine | ||||
paths in a range of use cases including static Label-Switched Paths (LSPs) | ||||
, Segment Routing | ||||
(SR), Service Function Chaining (SFC), and most forms of a routed or | ||||
switched network. Therefore, it is reasonable to consider PCEP as a | ||||
control protocol for use in these environments to allow the PCE to be | ||||
fully enabled as a central controller.</t> | ||||
<t>A PCE as a Central Controller (PCECC) can simplify the processing of | ||||
a distributed control plane by blending it with elements of SDN without | ||||
necessarily completely replacing it. This document describes general | ||||
considerations for PCECC deployment and examines its applicability and | ||||
benefits, as well as its challenges and limitations, through a number of | ||||
use cases. PCEP extensions, which are required for the PCECC use cases, | ||||
are covered in separate documents.</t> | ||||
<!-- [auth] <t>This is a living document to catalog the use cases for PCEC | ||||
C. There is currently no intention to publish this work as an RFC. [Update: Chai | ||||
rs are evaluating if the document should be published instead.]</t>--> | ||||
</abstract> | </abstract> | |||
<!--<note title="Requirements Language"> | <!-- [auth] <note title="Requirements Language"> | |||
<t> | <t> | |||
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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the y appear in all | 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the y appear in all | |||
capitals, as shown here.</t> | capitals, as shown here.</t> | |||
</note>--> | </note>--> | |||
</front> | </front> | |||
<middle> | ||||
<middle> | <section anchor="sect-1" numbered="true" toc="default"> | |||
<section title="Introduction" anchor="sect-1"> | <name>Introduction</name> | |||
<t>The PCE <xref target="RFC4655"/> was developed to offload | <t>The PCE <xref target="RFC4655" format="default"/> was developed to offl | |||
oad | ||||
the path computation function from routers in an MPLS traffic-engineered (TE) network. It can compute optimal paths for traffic | the path computation function from routers in an MPLS traffic-engineered (TE) network. It can compute optimal paths for traffic | |||
across a network and can also update the paths to reflect changes in | across a network and can also update the paths to reflect changes in | |||
the network or traffic demands. The role and function of | the network or traffic demands. The role and function of | |||
PCE have grown to cover several other uses (such as GMPLS | the PCE have grown to cover several other uses (such as GMPLS | |||
<xref target="RFC7025"/> or Multicast), | <xref target="RFC7025" format="default"/> or Multicast) | |||
and to allow delegated stateful control <xref target="RFC8231"/> and PCE-init | and to allow delegated stateful control <xref target="RFC8231" format="defaul | |||
iated | t"/> and PCE-initiated | |||
use of network resources <xref target="RFC8281"/>.</t> | use of network resources <xref target="RFC8281" format="default"/>.</t> | |||
<t>According to <xref target="RFC7399" format="default"/>, Software-Define | ||||
<t>According to <xref target="RFC7399"/>, Software-Defined Networking (SDN) r | d Networking (SDN) refers to a | |||
efers to a | ||||
separation between the control elements and the forwarding components | separation between the control elements and the forwarding components | |||
so that software running in a centralized system, called a | so that software running in a centralized system, called a | |||
controller, can act to program the devices in the network to behave | "controller", can act to program the devices in the network to behave | |||
in specific ways. A required element in an SDN architecture is a | in specific ways. A required element in an SDN architecture is a | |||
component that plans how the network resources will be used and how | component that plans how the network resources will be used and how | |||
the devices will be programmed. It is possible to view this | the devices will be programmed. It is possible to view this | |||
component as performing specific computations to place traffic flows | component as performing specific computations to place traffic flows | |||
within the network given knowledge of the availability of the network | within the network given knowledge of the availability of the network | |||
resources, how other forwarding devices are programmed, and the way | resources, how other forwarding devices are programmed, and the way | |||
that other flows are routed. This is the function and purpose of a | that other flows are routed. This is the function and purpose of a | |||
PCE, and the way that a PCE integrates into a wider network control | PCE, and the way that a PCE integrates into a wider network control | |||
system (including an SDN system) is presented in <xref target="RFC7491"/>.</t > | system (including an SDN system) is presented in <xref target="RFC7491" fo rmat="default"/>.</t> | |||
<t><xref target="RFC8283"/> introduces the architecture for the PCE as a central | <!--[rfced] The text below suggests that RFC 8283 (rather than a person) | |||
controller as an extension to the architecture described in <xref target="RFC | can "assume" something. Since we try to avoid the personification of RFCs, | |||
4655"/> | may we rephrase the text as shown below for clarity? | |||
Original: | ||||
[RFC8283] introduces the architecture for the PCE as a central | ||||
controller as an extension to the architecture described in [RFC4655] | ||||
and assumes the continued use of PCEP as the protocol used between | and assumes the continued use of PCEP as the protocol used between | |||
the PCE and PCC. <xref target="RFC8283"/> further examines the motivations a | the PCE and PCC. | |||
nd | ||||
Perhaps: | ||||
[RFC8283] introduces the architecture for the PCE as a central | ||||
controller and as an extension to the architecture described in [RFC4655]. | ||||
It is assumed that PCEP continues to be used as the protocol between | ||||
the PCE and PCC. | ||||
--> | ||||
<t><xref target="RFC8283" format="default"/> introduces the architecture f | ||||
or the PCE as a central | ||||
controller as an extension to the architecture described in <xref target="RFC | ||||
4655" format="default"/> | ||||
and assumes the continued use of PCEP as the protocol used between | ||||
the PCE and Path Computation Client (PCC). <xref target="RFC8283" format="de | ||||
fault"/> further examines the motivations and | ||||
applicability of PCEP as a Southbound Interface (SBI) and introduces | applicability of PCEP as a Southbound Interface (SBI) and introduces | |||
the implications for the protocol. </t> | the implications for the protocol. </t> | |||
<!-- [auth] <t> | ||||
<!--<t> | ||||
An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Networ k with Central | An Architecture for Use of PCE and PCEP <xref target="RFC5440"/> in a Networ k with Central | |||
Control <xref target="RFC8283"/> describes a | Control <xref target="RFC8283"/> describes a | |||
SDN architecture where the Path Computation Element (PCE) determines | SDN architecture where the Path Computation Element (PCE) determines | |||
the paths for variety of different usecases, with PCEP as a general southboun d | the paths for variety of different usecases, with PCEP as a general southboun d | |||
communication protocol with all the nodes along the path.</t>--> | communication protocol with all the nodes along the path.</t>--> | |||
<t><xref target="RFC9050"/> introduces the procedures and | <t><xref target="RFC9050" format="default"/> introduces the procedures and | |||
extensions for PCEP to support the PCECC architecture <xref target="RFC8283"/ | extensions for PCEP to support the PCECC architecture <xref target="RFC8283" | |||
>.</t> | format="default"/>.</t> | |||
<t> | ||||
<t> | ||||
This document describes the various use cases for the PCECC architecture.</t> | This document describes the various use cases for the PCECC architecture.</t> | |||
<!-- [auth] <t>This is a living document to catalog the use cases for PCEC | ||||
<!--<t>This is a living document to catalog the use cases for PCECC. There i | C. There is currently no intention to publish this work as an RFC. [Update: Chai | |||
s currently no intention to publish this work as an RFC. [Update: Chairs are eva | rs are evaluating if the document should be published instead.]</t>--> | |||
luating if the document should be published instead.]</t>--> | ||||
</section> | </section> | |||
<section anchor="sect-2" numbered="true" toc="default"> | ||||
<section title="Terminology" anchor="sect-2"> | <!--[rfced] FYI - We have ordered the list of terms in Section 2 alphabetically. | |||
<t> | Please let us know of any objections. | |||
The following terminology is used in this document. | --> | |||
<list style="hanging" hangIndent="0"> | ||||
<t hangText="BGP-LS:"> | ||||
Border Gateway Protocol - Link State <xref target="RFC9552"/>. | ||||
</t> | ||||
<t hangText="LSP:"> | ||||
Label Switched Path. | ||||
</t> | ||||
<t hangText="IGP:"> | ||||
Interior Gateway Protocol. In the document, we assume either Open Shortes | ||||
t Path First (OSPF) <xref target="RFC2328"/><xref target="RFC5340"/> or Intermed | ||||
iate System | ||||
to Intermediate System (IS-IS) <xref target="RFC1195"/> as IGP. | ||||
</t> | ||||
<t hangText="PCC:"> | ||||
Path Computation Client. As per <xref target="RFC4655"/>, any client appl | ||||
ication requesting a | ||||
path computation to be performed by a Path Computation Element. | ||||
</t> | ||||
<t hangText="PCE:"> | ||||
Path Computation Element. As per <xref target="RFC4655"/>, an entity (com | ||||
ponent, application, | ||||
or network node) that is capable of computing a network path or | ||||
route based on a network graph and applying computational | ||||
constraints. | ||||
</t> | ||||
<t hangText="PCECC:"> | ||||
PCE as a Central Controller. Extension of PCE to support SDN functions as per | ||||
<xref target="RFC8283"/>. | ||||
</t> | ||||
<t hangText="PST:"> | ||||
Path Setup Type <xref target="RFC8408"/>. | ||||
</t> | ||||
<t hangText="RR:"> | ||||
Route Reflector <xref target='RFC4456'/>. | ||||
</t> | ||||
<t hangText="SID:"> | ||||
Segment Identifier <xref target='RFC8402'/>. | ||||
</t> | ||||
<t hangText="SR:"> | ||||
Segment Routing <xref target='RFC8402'/>. | ||||
</t> | ||||
<t hangText="SRGB:"> | ||||
Segment Routing Global Block <xref target='RFC8402'/>. | ||||
</t> | ||||
<t hangText="SRLB:"> | ||||
Segment Routing Local Block <xref target='RFC8402'/>. | ||||
</t> | ||||
<t hangText="TE:"> | ||||
Traffic Engineering <xref target='RFC9522'/>. | ||||
</t> | ||||
</list></t> | ||||
</section> | ||||
<section title="Use Cases"> | ||||
<t><xref target="RFC8283"/> describes various use cases for PCECC such as: | ||||
<list style="symbols"> | ||||
<t>Use of PCECC to set up Static TE LSPs. The PCEP extension for this use ca | ||||
se is in <xref target="RFC9050"/>.</t> | ||||
<t>Use of PCECC in Segment Routing <xref target="RFC8402"/>.</t> | ||||
<t>Use of PCECC to set up Multicast Point-to-Multipoint (P2MP) LSP.</t> | ||||
<t>Use of PCECC to set up Service Function Chaining (SFC) <xref target="RFC7 | ||||
665"/>.</t> | ||||
<t>Use of PCECC in Optical Networks.</t> | ||||
</list> | ||||
</t> | ||||
<t><xref target="sect-3"/> describes the general case of PCECC being in charge | ||||
of | ||||
managing MPLS label space which is a prerequisite for further use case | ||||
s. | ||||
Further, various use cases (SR, Multicast etc) are described in the fo | ||||
llowing sections to showcase scenarios that can benefit from the use of PCECC. | ||||
</t> | ||||
<t>It is interesting to note that some of the use cases listed can also be suppo | <name>Terminology</name> | |||
rted via BGP instead of PCEP. However, within the scope of this document, the fo | <t> | |||
cus is on the use of PCEP.</t> | The following terminology is used in this document. | |||
</t> | ||||
<dl newline="false" spacing="normal" indent="0"> | ||||
<dt>AS:</dt> <dd>Autonomous System</dd> | ||||
<dt>ASBR:</dt> <dd>Autonomous System Border Router</dd> | ||||
<dt>BGP-LS:</dt> | ||||
<dd>Border Gateway Protocol - Link State <xref target="RFC9552" format=" | ||||
default"/></dd> | ||||
<dt>IGP:</dt> | ||||
<dd>Interior Gateway Protocol (in this document, we assume IGP as either | ||||
Open Shortest Path First (OSPF) <xref target="RFC2328" format="default"/> <xref | ||||
target="RFC5340" format="default"/> or | ||||
Intermediate System to Intermediate System (IS-IS) <xref target="RFC1195 | ||||
" format="default"/>)</dd> | ||||
<dt>LSP:</dt> | ||||
<dd>Label-Switched Path</dd> | ||||
<dt>PCC:</dt> | ||||
<dd>Path Computation Client (as per <xref target="RFC4655" format="defau | ||||
lt"/>, any client application requesting a path | ||||
computation to be performed by a PCE)</dd> | ||||
<dt>PCE:</dt> | ||||
<dd>Path Computation Element (as per <xref target="RFC4655" format="defa | ||||
ult"/>, an entity such as a component, application, or network node that is capa | ||||
ble of computing a network path or route based on a | ||||
network graph and applying computational constraints)</dd> | ||||
<dt>PCECC:</dt> | ||||
<dd>PCE as a Central Controller (an extension of a PCE to support SDN fu | ||||
nctions as per <xref target="RFC8283" format="default"/>)</dd> | ||||
<dt>PST:</dt> | ||||
<dd>Path Setup Type <xref target="RFC8408" format="default"/></dd> | ||||
<dt>RR:</dt> | ||||
<dd>Route Reflector <xref target="RFC4456" format="default"/></dd> | ||||
<dt>SID:</dt> | ||||
<dd>Segment Identifier <xref target="RFC8402" format="default"/></dd> | ||||
<dt>SR:</dt> | ||||
<dd>Segment Routing <xref target="RFC8402" format="default"/></dd> | ||||
<dt>SRGB:</dt> | ||||
<dd>Segment Routing Global Block <xref target="RFC8402" format="default" | ||||
/></dd> | ||||
<dt>SRLB:</dt> | ||||
<dd>Segment Routing Local Block <xref target="RFC8402" format="default"/ | ||||
></dd> | ||||
<dt>TE:</dt> | ||||
<dd>Traffic Engineering <xref target="RFC9522" format="default"/></dd> | ||||
</dl> | ||||
</section> | ||||
<section numbered="true" toc="default"> | ||||
<section title="PCECC for Label Management" anchor="sect-3"> | <name>Use Cases</name> | |||
<t>As per <xref target="RFC8283"/>, in some cases, the PCE-based controller | <t><xref target="RFC8283" format="default"/> describes various use cases f | |||
can take responsibility for | or a PCECC such as: | |||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
use of a PCECC to set up static TE LSPs (the PCEP extension for this u | ||||
se case is in <xref target="RFC9050" format="default"/>) | ||||
</li> | ||||
<li> | ||||
use of a PCECC in Segment Routing <xref target="RFC8402" format="defau | ||||
lt"/> | ||||
</li> | ||||
<li> | ||||
use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs | ||||
</li> | ||||
<li> | ||||
use of a PCECC to set up Service Function Chaining (SFC) <xref target= | ||||
"RFC7665" format="default"/> | ||||
</li> | ||||
<li> | ||||
use of a PCECC in optical networks | ||||
</li> | ||||
</ul> | ||||
<t><xref target="sect-3" format="default"/> describes the general case of | ||||
a PCECC being in charge of | ||||
managing MPLS label space, which is a prerequisite for further use cas | ||||
es. | ||||
Further, various use cases (SR, Multicast, etc.) are described in the | ||||
following sections to showcase scenarios that can benefit from the use of a PCEC | ||||
C. | ||||
</t> | ||||
<t>It is interesting to note that some of the use cases listed can also be | ||||
supported via BGP instead of PCEP. However, within the scope of this document, | ||||
the focus is on the use of PCEP.</t> | ||||
<section anchor="sect-3" numbered="true" toc="default"> | ||||
<name>PCECC for Label Management</name> | ||||
<t>As per <xref target="RFC8283" format="default"/>, in some cases, the | ||||
PCE-based controller can take responsibility for | ||||
managing some part of the MPLS label space for each of the routers | managing some part of the MPLS label space for each of the routers | |||
that it controls, and it may take wider responsibility for | that it controls, and it may take wider responsibility for | |||
partitioning the label space for each router and allocating different | partitioning the label space for each router and allocating different | |||
parts for different uses, communicating the ranges to the router | parts for different uses, communicating the ranges to the router | |||
using PCEP.</t> | using PCEP.</t> | |||
<t><xref target="RFC9050" format="default"/> describes a mode where | ||||
LSPs are provisioned as explicit label instructions at each hop on the | ||||
end-to-end path. Each router along the path must be told what label | ||||
forwarding instructions to program and what resources to reserve. The | ||||
controller uses PCEP to communicate with each router along the path of | ||||
the end-to-end LSP. For this to work, the PCE-based controller will | ||||
take responsibility for managing some part of the MPLS label space for | ||||
each of the routers that it controls. An extension to PCEP could be | ||||
done to allow a PCC to inform the PCE of such a label space to control | ||||
(see <xref target="I-D.ietf-pce-controlled-id-space" | ||||
format="default"/> for a possible PCEP extension to support the | ||||
advertisement of the MPLS label space for the PCE to control).</t> | ||||
<t><xref target="RFC9050"/> describes a mode | <t><xref target="RFC8664" format="default"/> specifies extensions to PCE | |||
where LSPs are provisioned as explicit label instructions at each hop | P that | |||
on the end-to-end path. Each router along the path must be told what | allow a stateful PCE to compute, update, or initiate SR-TE paths. | |||
label forwarding instructions to program and what resources to | <xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default" | |||
reserve. The controller uses PCEP to communicate with each router | /> describes the | |||
along the path of the end-to-end LSP. For this to work, the | mechanism for a PCECC to allocate and provision the node/prefix/ | |||
PCE-based controller will take responsibility for managing some part of | adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an | |||
the MPLS label space for each of the routers that it controls. | allocation, the PCE needs to | |||
An extension to PCEP could be done to allow a PCC to | ||||
inform the PCE of such a label space to control. (See <xref target="I-D.li-pc | ||||
e-controlled-id-space"/> for a possible PCEP extension to support | ||||
the advertisement of the MPLS label space to the PCE to control.)</t> | ||||
<t><xref target="RFC8664"/> specifies extensions to PCEP that | ||||
allow a stateful PCE to compute, update or initiate SR-TE paths. | ||||
<xref target="I-D.ietf-pce-pcep-extension-pce-controller-sr"/> describes the | ||||
mechanism for PCECC to allocate and provision the node/prefix/ | ||||
adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an | ||||
allocation PCE needs to | ||||
be aware of the label space from the Segment Routing Global Block (SRGB) | be aware of the label space from the Segment Routing Global Block (SRGB) | |||
or Segment Routing Local Block (SRLB) | or Segment Routing Local Block (SRLB) | |||
<xref target="RFC8402"/> of the node that it controls. A | <xref target="RFC8402" format="default"/> of the node that it controls. A | |||
mechanism for a PCC to inform the PCE of such a label space to | mechanism for a PCC to inform the PCE of such a label space to | |||
control is needed within the PCEP. The full SRGB/SRLB of a node could be | control is needed within the PCEP. The full SRGB/SRLB of a node could be | |||
learned via existing IGP or BGP-LS <xref target="RFC9552"/> mechanisms.</t> | learned via existing IGP or BGP-LS <xref target="RFC9552" format="default"/> mechanisms.</t> | |||
<t>Further, there have been proposals for a global label range in MPLS, the P | <!--[rfced] FYI - We have updated the text below for clarity. Please | |||
CECC | review and let us know if this has changed the intended meaning. | |||
architecture could be used as a means to learn the label space of nodes, and | ||||
could also be used to | ||||
determine and provision the global label range.</t> | ||||
<!--<t> | Original: | |||
Further, there have been proposals for a global label range in MPLS, | ||||
the PCECC architecture could be used as a means to learn the label | ||||
space of nodes, and could also be used to determine and provision the | ||||
global label range. | ||||
Current: | ||||
Further, there have been proposals for a global label range in MPLS | ||||
as well as PCECC architecture being used as a means to learn the label | ||||
space of nodes and being used to determine and provision the global | ||||
label range. | ||||
--> | ||||
<t>Further, there have been proposals for a global label range in MPLS a | ||||
s well as PCECC | ||||
architecture being used as a means to learn the label space of nodes and bei | ||||
ng used to | ||||
determine and provision the global label range.</t> | ||||
<!-- [auth] <t> | ||||
This use case is based on network configuration illustrated using | This use case is based on network configuration illustrated using | |||
the following figure:</t>--> | the following figure:</t>--> | |||
<figure title="PCECC for MPLS Label Management" anchor="fig_label"><artwo | <figure anchor="fig_label"> | |||
rk><![CDATA[ | <name>PCECC for MPLS Label Management</name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+------------------------------+ +------------------------------+ | +------------------------------+ +------------------------------+ | |||
| PCE DOMAIN 1 | | PCE DOMAIN 2 | | | PCE DOMAIN 1 | | PCE DOMAIN 2 | | |||
| +--------+ | | +--------+ | | | +--------+ | | +--------+ | | |||
| | | | | | | | | | | | | | | | | | |||
| | PCECC1 | ---------PCEP---------- | PCECC2 | | | | | PCECC1 | ---------PCEP---------- | PCECC2 | | | |||
| | | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | |||
| +--------+ | | +--------+ | | | +--------+ | | +--------+ | | |||
| ^ ^ | | ^ ^ | | | ^ ^ | | ^ ^ | | |||
| / \ PCEP | | PCEP / \ | | | / \ PCEP | | PCEP / \ | | |||
| V V | | V V | | | V V | | V V | | |||
| +--------+ +--------+ | | +--------+ +--------+ | | | +--------+ +--------+ | | +--------+ +--------+ | | |||
| |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | |||
| | | ...... | | | | | | ...... | | | | | | | ...... | | | | | | ...... | | | | |||
| | PCECC | | PCECC | | | | PCECC | |PCECC | | | | | PCECC | | PCECC | | | | PCECC | |PCECC | | | |||
| |Enabled | | Enabled| | |Enabled | |Enabled | | | | |Enabled | | Enabled| | | |Enabled | |Enabled | | | |||
| +--------+ +--------+ | | +--------+ +--------+ | | | +--------+ +--------+ | | +--------+ +--------+ | | |||
| | | | | | | | | | |||
+------------------------------+ +------------------------------+ | +------------------------------+ +------------------------------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t><list style="symbols"><t>As shown in <xref target="fig_label"/>, PCC w | ||||
ill advertise the PCECC capability to the PCE central | ||||
controller (PCECC) <xref target="RFC9050"/>.</t> | ||||
<t>The PCECC could also learn the label range set aside by the PCC (via < | <!-- [rfced] Should an introductory sentence be added to the list that appears | |||
xref target="I-D.li-pce-controlled-id-space"/>). </t> | after Figure 1 to provide context for the proceeding text? | |||
<t>Optionally, the PCECC could determine the shared MPLS global label range fo | ||||
r the network. | ||||
<list style="symbols"> | ||||
<t>In the case that the shared global label range needs to be | ||||
negotiated across multiple domains, the central controllers of | ||||
these domains will also need to negotiate a common global | ||||
label range across domains.</t> | ||||
<t>The PCECC will need to set the shared global label | Original: | |||
range to all PCC nodes in the network.</t> | ||||
</list></t> | ||||
</list> | Figure 1: PCECC for MPLS Label Management | |||
</t> | ||||
<t>As per <xref target="RFC9050"/>, PCECC could also rely on the PCC to make l | ||||
abel allocations initially and use PCEP to distribute it to where it is needed.< | ||||
/t> | ||||
</section> | * As shown in Figure 1, PCC will advertise the PCECC capability to | |||
the PCE central controller (PCECC) [RFC9050]. | ||||
<section title="PCECC and Segment Routing" anchor="sect-4"> | * The PCECC could also learn the label range set aside by the PCC | |||
<t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source routin | (via [I-D.li-pce-controlled-id-space]). | |||
g paradigm. Using | ||||
SR, a source node steers a packet through a path without relying on | ||||
hop-by-hop signalling protocols such as LDP <xref target="RFC5036"/> or RSVP- | ||||
TE <xref target="RFC3209"/>. Each path is | ||||
specified as an ordered list of instructions called "segments". Each | ||||
segment is an instruction to route the packet to a specific place in | ||||
the network, or to perform a specific service on the packet. A | ||||
database of segments can be distributed | ||||
through the network using a intra-domain routing protocol (such as IS-IS or | ||||
OSPF) or an inter-domain protocol (BGP), or by any other means. PCEP could a | ||||
lso be one of other protocols.</t> | ||||
<t><xref target="RFC8664"/> specifies the | Perhaps: | |||
SR-specific PCEP extension for SR-MPLS. PCECC may further use PCEP protocol | ||||
for SR SIDs (Segment Identifiers) | ||||
distribution to the SR nodes (PCC) with some benefits. If the | ||||
PCECC allocates and maintains the SIDs in the network for the nodes and adjac | ||||
encies; | ||||
and further distributes them to the SR nodes directly via the | ||||
PCEP session then it is more advantageous over the configurations on | ||||
each SR node and flooding them via IGP, especially in an SDN environment. </t | ||||
> | ||||
<!--<t> | Figure 1: PCECC for MPLS Label Management | |||
As shown in Figure 1: | ||||
* PCC will advertise the PCECC capability to | ||||
the PCE central controller (PCECC) [RFC9050]. | ||||
* The PCECC could also learn the label range set aside by the PCC | ||||
(via [I-D.li-pce-controlled-id-space]). | ||||
--> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>As shown in <xref target="fig_label" format="default"/>, the PCC | ||||
will advertise the PCECC capability to the PCECC <xref target="RFC9 | ||||
050" format="default"/>.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC could also learn the label range set aside by the PCC | ||||
(via <xref target="I-D.ietf-pce-controlled-id-space" | ||||
format="default"/>).</t> | ||||
</li> | ||||
<li> | ||||
<t>Optionally, the PCECC could determine the shared MPLS global | ||||
label range for the network.</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>In the case that the shared global label range needs to be | ||||
negotiated across multiple domains, the central controllers of | ||||
these domains will also need to negotiate a common global | ||||
label range across domains.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will need to set the shared global label range to | ||||
all PCC nodes in the network.</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
</ul> | ||||
<t>As per <xref target="RFC9050" format="default"/>, the PCECC could als | ||||
o | ||||
rely on the PCC to make label allocations initially and use PCEP to | ||||
distribute it to where it is needed.</t> | ||||
</section> | ||||
<section anchor="sect-4" numbered="true" toc="default"> | ||||
<name>PCECC and Segment Routing</name> | ||||
<t>Segment Routing (SR) <xref target="RFC8402" format="default"/> | ||||
leverages the source routing paradigm. Using SR, a source node steers | ||||
a packet through a path without relying on hop-by-hop signalling | ||||
protocols such as LDP <xref target="RFC5036" format="default"/> or | ||||
RSVP-TE <xref target="RFC3209" format="default"/>. Each path is | ||||
specified as an ordered list of instructions called "segments". Each | ||||
segment is an instruction to route the packet to a specific place in | ||||
the network or to perform a specific service on the packet. A | ||||
database of segments can be distributed through the network using an | ||||
intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain | ||||
protocol (such as BGP), or by any other means. PCEP could also be one | ||||
of other protocols.</t> | ||||
<t><xref target="RFC8664" format="default"/> specifies the PCEP | ||||
extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may furth | ||||
er | ||||
use the PCEP protocol for distributing SR Segment Identifiers (SIDs) | ||||
to the SR nodes (PCC) with some benefits. If the PCECC allocates and | ||||
maintains the SIDs in the network for the nodes and adjacencies, and | ||||
further distributes them to the SR nodes directly via the PCEP session, | ||||
then it is more advantageous over the configurations on each SR node | ||||
and flooding them via IGP, especially in an SDN environment. </t> | ||||
<!-- [auth] <t> | ||||
For the centralized network, the performance achieved through | For the centralized network, the performance achieved through | |||
distributed system can not be easy matched if all of the forwarding | distributed system can not be easy matched if all of the forwarding | |||
paths are computed, downloaded and maintained by the centralized | paths are computed, downloaded and maintained by the centralized | |||
controller. The performance can be improved by supporting part of | controller. The performance can be improved by supporting part of | |||
the forwarding path in the PCECC network through the segment routing | the forwarding path in the PCECC network through the segment routing | |||
mechanism except that node segment IDs and adjacency segment IDs for | mechanism except that node segment IDs and adjacency segment IDs for | |||
all the network are allocated dynamically and propagated through the | all the network are allocated dynamically and propagated through the | |||
centralized controller instead of using the IGP extensions.</t>--> | centralized controller instead of using the IGP extensions.</t>--> | |||
<t> | <t> | |||
When the PCECC is used for the distribution of the Node-SID | When the PCECC is used for the distribution of the Node-SID | |||
and Adj-SID for SR-MPLS, the Node-SID is allocated from the | and Adj-SID for SR-MPLS, the Node-SID is allocated from the | |||
SRGB of the node. For the allocation of Adj-SID, the | SRGB of the node and the | |||
allocation is from the SRLB of the node as described in <xref target="I-D.iet | Adj-SID is allocated from the SRLB of the node as described in <xref target=" | |||
f-pce-pcep-extension-pce-controller-sr"/>.</t> | I-D.ietf-pce-pcep-extension-pce-controller-sr" format="default"/>.</t> | |||
<t><xref target="RFC8355" format="default"/> identifies various protecti | ||||
<t><xref target="RFC8355"/> identifies various protection and resiliency | on and resiliency use cases for SR. | |||
usecases for SR. | ||||
Path protection lets the ingress node be in charge of the failure | Path protection lets the ingress node be in charge of the failure | |||
recovery (used for SR-TE <xref target="RFC8664"/>). Also, protection can be | recovery (used for SR-TE <xref target="RFC8664" format="default"/>). Also, pr otection can be | |||
performed by the node adjacent to the failed component, commonly | performed by the node adjacent to the failed component, commonly | |||
referred to as local protection techniques or fast-reroute (FRR) techniques. | referred to as "local protection techniques" or "fast-reroute (FRR) technique | |||
In the case of PCECC, the protection paths can be pre-computed | s". | |||
In the case of the PCECC, the protection paths can be precomputed | ||||
and set up by the PCE.</t> | and set up by the PCE.</t> | |||
<t> | ||||
<t> | <xref target="fig_sr" format="default"/> illustrates the use case where the N | |||
The <xref target="fig_sr"/> illustrates the use case where the Node-SID and A | ode-SID and Adj-SID are allocated by the PCECC for SR-MPLS.</t> | |||
dj-SID are allocated by the PCECC for SR-MPLS.</t> | <figure anchor="fig_sr"> | |||
<name>SR Topology</name> | ||||
<figure title="SR Topology" anchor="fig_sr"><artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
192.0.2.1/32 | 192.0.2.1/32 | |||
+----------+ | +----------+ | |||
| R1(1001) | | | R1(1001) | | |||
+----------+ | +----------+ | |||
| | | | |||
+----------+ | +----------+ | |||
| R2(1002) | 192.0.2.2/32 | | R2(1002) | 192.0.2.2/32 | |||
+----------+ | +----------+ | |||
* | * * | * | * * | |||
* | * * | * | * * | |||
skipping to change at line 553 ¶ | skipping to change at line 539 ¶ | |||
* | * * + | * | * * + | |||
* | * * + | * | * * + | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 | 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | | | |||
+-----------+ | +-----------+ | |||
| R8(1008) | 192.0.2.8/32 | | R8(1008) | 192.0.2.8/32 | |||
+-----------+ | +-----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section title="PCECC SID Allocation for SR-MPLS" anchor="sect-4.1" > | ||||
<t>Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC | <section anchor="sect-4.1" numbered="true" toc="default"> | |||
<name>PCECC SID Allocation for SR-MPLS</name> | ||||
<t>Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC | ||||
needs to update the label mapping of each node to all | needs to update the label mapping of each node to all | |||
the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local | the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local | |||
routing information to determine the nexthop and download the label | routing information to determine the next hop and download the label | |||
forwarding instructions accordingly. The forwarding behaviour and the end res | forwarding instructions accordingly. The forwarding behavior and the end resu | |||
ult | lt | |||
are the same as IGP shortest-path SR forwarding based on Node-SID. Thus, fro | are the same as IGP shortest-path SR forwarding based on Node-SIDs. Thus, fr | |||
m anywhere in the domain, it enforces the | om anywhere in the domain, it enforces the | |||
ECMP-aware shortest-path forwarding of the packet towards the related | ECMP-aware shortest-path forwarding of the packet towards the related | |||
node.</t> | node.</t> | |||
<t>The PCECC can allocate an Adj-SID for each adjacency in the network | ||||
<t>For each adjacency in the network, a PCECC can allocate an Adj-SID. The PC | . The PCECC sends a PCInitiate message to update the label mapping of each adjac | |||
ECC sends a PCInitiate message to update the label mapping of each adjacency to | ency to the | |||
the | ||||
corresponding nodes in the domain. Each node (PCC) downloads the | corresponding nodes in the domain. Each node (PCC) downloads the | |||
label forwarding instructions accordingly. The forwarding behaviour and the e nd result are similar to IGP-based | label forwarding instructions accordingly. The forwarding behavior and the en d result are similar to IGP-based | |||
Adj-SID allocation and usage in SR.</t> | Adj-SID allocation and usage in SR.</t> | |||
<t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-e | ||||
xtension-pce-controller-sr" format="default"/>.</t> | ||||
</section> | ||||
<section anchor="sect-4.2" numbered="true" toc="default"> | ||||
<name>PCECC for SR-MPLS Best Effort (BE) Paths</name> | ||||
<t>These mechanisms are described in <xref target="I-D.ietf-pce-pcep-extensio | <!-- [rfced] Section 3.2.2 begins with the text below; how may we rephrase to | |||
n-pce-controller-sr"/>.</t> | clarify what "this use case" refers to? | |||
</section> | ||||
<section title="PCECC for SR-MPLS Best Effort (BE) Path" anchor="sect-4.2 | ||||
"><t> | ||||
In this use case, the PCECC needs to allocate the | ||||
Node-SID (without calculating the explicit | ||||
path for the SR path). The ingress router of the forwarding path needs | ||||
to encapsulate the destination Node-SID on top of the packet. | ||||
All the intermediate nodes will forward the packet based on the | ||||
destination Node-SID. It is similar to the LDP LSP.</t> | ||||
<t>R1 may send a packet to R8 simply by pushing an SR label with | Original: | |||
segment {1008} (Node-SID for R8). The path will be based on the routing/nexth | ||||
op calculation on the routers.</t> | ||||
</section> | 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path | |||
<section title="PCECC for SR-MPLS TE Path" anchor="sect-4.3"> | In this use case, the PCECC needs to allocate the Node-SID (without | |||
calculating the explicit path for the SR path). | ||||
<t>SR-TE paths may not follow an IGP shortest path tree (SPT). S | Perhaps: | |||
uch paths may be chosen by a | ||||
PCECC and provisioned on the ingress node of the SR-TE path. The SR | ||||
header consists of a list of SIDs (or MPLS labels). The header has | ||||
all necessary information so that the packets can be guided from the | ||||
ingress node to the egress node of the path. Hence, there is no need | ||||
for any signalling protocol. For the case where a strict traffic | ||||
engineering path is needed, all the Adj-SID are stacked, | ||||
otherwise, a combination of node-SID or adj-SID can be used for the | ||||
SR-TE paths.</t> | ||||
<t>As shown in <xref target="fig-sr-te"/>, R1 may send a packet to R8 by pushing | 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path | |||
an SR header with segment | ||||
list {1002, 9001, 1008}. Where 1002 and 1008 are the Node-SID of R2 and R8 re | ||||
spectively. 9001 is the Adj-SID for link1. The path should be: R1-R2-link1-R3-R8 | ||||
.</t> | ||||
<t> | When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to | |||
To achieve this, the PCECC first allocates and distributes SIDs as | allocate the Node-SID (without calculating the explicit path for the SR path | |||
described in <xref target="sect-4.1"/>. <xref target="RFC8664"/> describes t | ). | |||
he | --> | |||
mechanism for a PCE to | ||||
compute, update, or initiate SR-MPLS TE paths. </t> | ||||
<figure title="PCECC TE LSP Setup Example" anchor="fig-sr-te"><artwork><! | <t> | |||
[CDATA[ | In this use case, the PCECC needs to allocate the | |||
Node-SID (without calculating the explicit | ||||
path for the SR path). The ingress router of the forwarding path needs | ||||
to encapsulate the destination Node-SID on top of the packet. | ||||
All the intermediate nodes will forward the packet based on the | ||||
destination Node-SID. It is similar to the LDP LSP.</t> | ||||
<t>R1 may send a packet to R8 simply by pushing an SR label with | ||||
segment {1008} (Node-SID for R8). The path will be based on the routing / nex | ||||
t hop calculation on the routers.</t> | ||||
</section> | ||||
<section anchor="sect-4.3" numbered="true" toc="default"> | ||||
<name>PCECC for SR-MPLS TE Paths</name> | ||||
<t> | ||||
SR-TE paths may not follow an IGP shortest path tree (SPT). Such | ||||
paths may be chosen by a PCECC and provisioned on the ingress node | ||||
of the SR-TE path. The SR header consists of a list of SIDs (or | ||||
MPLS labels). The header has all necessary information so that | ||||
the packets can be guided from the ingress node to the egress node | ||||
of the path. Hence, there is no need for any signalling protocol. | ||||
For the case where a strict traffic engineering path is needed, | ||||
all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs | ||||
or Adj-SIDs can be used for the SR-TE paths.</t> | ||||
<t> | ||||
As shown in <xref target="fig-sr-te" format="default"/>, R1 may | ||||
send a packet to R8 by pushing an SR header with segment list | ||||
{1002, 9001, 1008}, where 1002 and 1008 are the Node-SIDs of R2 and | ||||
R8, respectively. 9001 is the Adj-SID for link1. The path should | ||||
be: R1-R2-link1-R3-R8.</t> | ||||
<t> | ||||
To achieve this, the PCECC first allocates and distributes SIDs as | ||||
described in <xref target="sect-4.1" format="default"/>. <xref | ||||
target="RFC8664" format="default"/> describes the mechanism for a | ||||
PCE to compute, update, or initiate SR-MPLS TE paths. | ||||
</t> | ||||
<figure anchor="fig-sr-te"> | ||||
<name>PCECC TE LSP Setup Example</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
192.0.2.1/32 | 192.0.2.1/32 | |||
+----------+ | +----------+ | |||
| R1 (1001)| | | R1 (1001)| | |||
+----------+ | +----------+ | |||
| | | | | | |||
90011 | |90012 | 90011 | |90012 | |||
link1 | |link2 | link1 | |link2 | |||
+----------+ | +----------+ | |||
| R2 (1002)| 192.0.2.2/32 | | R2 (1002)| 192.0.2.2/32 | |||
+----------+ | +----------+ | |||
skipping to change at line 636 ¶ | skipping to change at line 644 ¶ | |||
* | * + | * | * + | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32 | 192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32 | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | | | | | |||
|link8 | | |link8 | | |||
| |----------|link9 | | |----------|link9 | |||
+-----------+ | +-----------+ | |||
| R8 (1008) | 192.0.2.8/32 | | R8 (1008) | 192.0.2.8/32 | |||
+-----------+ | +-----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Refer to <xref target="fig-sr-te"/> for an example of TE topology, where, 1 | ||||
00x - are Node-SIDs and 900xx - are Adj-SIDs. | ||||
<list style="symbols"> | ||||
<t>The SID allocation and distribution are done by the PCECC with all Node-SIDs | ||||
(100x) and all Adj-SIDs (900xx).</t> | ||||
<t>Based on path computation request/delegation or PCE initiation, the PCECC | ||||
receives a request with constraints and optimization criteria from a PCC. </t> | ||||
<t>PCECC will calculate the optimal path according to the given constraints | <t> | |||
(e.g. bandwidth). </t> | Refer to <xref target="fig-sr-te" format="default"/> for an | |||
example of TE topology, where 100x are Node-SIDs and 900xx are Adj-SI | ||||
Ds. | ||||
</t> | ||||
<t> PCECC will provision SR-MPLS TE LSP (path R1-link1-R2-link6-R3-R8) at the in | <ul spacing="normal"> | |||
gress node: {90011,1002,90026,1003,1008}</t> | <li> | |||
<t>For the end-to-end protection, PCECC can provision the secondary path (R1-lin | <t>The SID allocation and distribution are done by the PCECC with | |||
k2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.</t> | all Node-SIDs (100x) and all Adj-SIDs (900xx).</t> | |||
</li> | ||||
<li> | ||||
<t>Based on path computation request/delegation or PCE | ||||
initiation, the PCECC receives a request with constraints and | ||||
optimization criteria from a PCC.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will calculate the optimal path according to the give | ||||
n | ||||
constraints (e.g., bandwidth).</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will provision the SR-MPLS TE LSP path (R1-link1-R2-l | ||||
ink6-R3-R8) at the ingress node: {90011,1002,90026,1003,1008}</t> | ||||
</li> | ||||
<li> | ||||
<t>For the end-to-end protection, the PCECC can provision the seco | ||||
ndary path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.</t> | ||||
</li> | ||||
</ul> | ||||
</list></t> | <section anchor="sect-4.4" numbered="true" toc="default"> | |||
<name>PCECC for SR Policy</name> | ||||
<section title="PCECC for SR Policy" anchor="sect-4.4"> | <t><xref target="RFC8402" format="default"/> defines Segment | |||
Routing architecture, which uses an SR Policy to steer packets | ||||
from a node through an ordered list of segments. The SR Policy | ||||
could be configured on the headend or instantiated by an SR | ||||
controller. The SR architecture does not restrict how the | ||||
controller programs the network. In this case, the focus is on | ||||
PCEP as the protocol for SR Policy delivery from the PCE to PCC. </t | ||||
> | ||||
<t><xref target="RFC8402"/> defines Segment Routing architecture, which uses an | <t>An SR Policy architecture is described in <xref | |||
SR Policy | target="RFC9256" format="default"/>. An SR Policy is a framework | |||
to steer packets from a node through an ordered list of segments. The SR Poli | that enables the instantiation of an ordered list of segments on a | |||
cy could be | node for implementing a source routing policy for the steering of | |||
configured on the headend or instantiated by an SR controller. | traffic for a specific purpose (e.g., for a specific Service Level A | |||
The SR architecture does not restrict how the controller programs the | greement (SLA)) from that | |||
network. In this case, the focus is on PCEP as the protocol for SR Policy del | node.</t> | |||
ivery from PCE to PCC. </t> | ||||
<t>An SR Policy architecture is described in <xref target="RFC9256"/>. An SR | <t>An SR Policy is identified through the tuple <headend, | |||
Policy is a framework that enables the | color, endpoint>.</t> | |||
instantiation of an ordered list of segments on a node for | ||||
implementing a source routing policy for the steering of traffic for a | ||||
specific purpose (e.g. for a specific SLA) from that node.</t> | ||||
<t>An SR Policy is identified through the tuple <headend, color, | <t><xref target="fig-sr-te" format="default"/> is used as an | |||
endpoint>. </t> | example of PCECC application for SR Policy instantiation for | |||
SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx.</t> | ||||
<t><xref target="fig-sr-te"/> is used as an example of PCECC application for S | <t>Let's assume that R1 needs to have two disjoint SR Policies | |||
R Policy instantiation for SR-MPLS, where, 100x - are Node-SIDs and 900xx - are | towards R8 based on different bandwidths. This means the possible pa | |||
Adj-SIDs.</t> | ths | |||
are:</t> | ||||
<t>Let's assume that R1 needs to have two disjoint SR Policies towards R8 bas | <ul> | |||
ed on different bandwidths, the possible paths are: | <li> | |||
<list> | POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segm | |||
<t>POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1 | ent List 1: {90011,1002,90023,1004,1003,1008}} | |||
: {90011,1002,90023,1004,1003,1008}}</t> | </li> | |||
<t>POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1 | <li> | |||
: {90012,1002,90024,1005,1006,1008}}</t> | POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segm | |||
</list></t> | ent List 1: {90012,1002,90024,1005,1006,1008}} | |||
<t>Each SR Policy (including candidate path and segment list) will be signall | </li> | |||
ed to a headend (R1) via PCEP <xref target="I-D.ietf-pce-segment-routing-policy | </ul> | |||
-cp"/> with the addition of an ASSOCIATION object. | ||||
Binding SID (BSID) <xref target="RFC8402"/> can be used for traffic steering | ||||
of labelled traffic into SR Policy, BSID can be provisioned from PCECC also via | ||||
PCEP <xref target="I-D.ietf-pce-binding-label-sid"/>. | ||||
For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-dest | ||||
ination traffic steering will be used by means of the BGP Color extended communi | ||||
ty <xref target="RFC9012"/> </t> | ||||
<t> The procedure: <list> | <t>Each SR Policy (including the candidate path and segment list) wi | |||
<t> PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in < | ll | |||
xref target="sect-4.1"/> for all nodes and links. </t> | be signalled to a headend (R1) via PCEP <xref | |||
<t> PCECC will calculate disjoint paths for POL1 and POL2 and create Segment | target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> | |||
Lists for them:{90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,100 | with the addition of an ASSOCIATION object. A Binding SID (BSID) | |||
8}.</t> | <xref target="RFC8402" format="default"/> can be used for traffic | |||
<t> PCECC will form both SR Policies POL1 and POL2.</t> | steering of labelled traffic into an SR Policy; a BSID can be | |||
<t> PCECC will send both POL1 and POl2 to R1 via PCEP. </t> | provisioned from the PCECC also via PCEP <xref target="RFC9604" | |||
<t> PCECC optionally can allocate BSIDs for the SR Policies.</t> | format="default"/>. For non-labelled traffic steering into the SR | |||
Policy POL1 or POL2, a per-destination traffic steering will be | ||||
used by means of the BGP Color Extended Community <xref | ||||
target="RFC9012" format="default"/>.</t> | ||||
<t>The traffic from R1 to R8 which fits to color 100 will be steered to POL1 | <t>The procedure is as follows:</t> | |||
and follows the path: R1-link1-R2-link3-R4-R3-R8. The traffic from R1 to R8 whic | <ul> | |||
h fits color 200 | <li> | |||
will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8. Due | The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism d | |||
to the possibility of having many Segment Lists in the same Candidate Path of e | escribed in <xref target="sect-4.1" format="default"/> for all nodes and links. | |||
ach POL1/POL2, | </li> | |||
PCECC could provision more paths towards R8 and traffic will be balanced eith | <li> | |||
er as ECMP or as w/ECMP. This is the advantage of SR Policy architecture. </t> | The PCECC calculates disjoint paths for POL1 and POL2 and create | |||
</list></t> | segment lists for them: {90011,1002,90023,1004,1003,1008};{90012,1002,90024,100 | |||
5,1006,1008}. | ||||
</li> | ||||
<li> | ||||
The PCECC forms both SR Policies POL1 and POL2. | ||||
</li> | ||||
<li> | ||||
The PCECC sends both POL1 and POL2 to R1 via PCEP. | ||||
</li> | ||||
<li> | ||||
The PCECC optionally allocates BSIDs for the SR Policies. | ||||
</li> | ||||
<t>Note that an SR Policy can be associated with multiple candidate paths. A | <!-- [rfced] For clarity, can "w/ECMP" be updated to "with ECMP" in the text | |||
candidate path is selected when it is valid and it is determined to be the best | below? | |||
path of the SR Policy as described in <xref target="RFC9256"/>.</t> | ||||
</section> | Original: | |||
</section> | ||||
<section title="PCECC for SRv6" anchor="sect-8"> | ||||
<t>As per <xref target="RFC8402"/>, with Segment Routing (SR), | ||||
a node steers a packet through an ordered list of instructions, | ||||
called segments. Segment Routing | ||||
can be applied to the IPv6 architecture with the Segment Routing | ||||
Header (SRH) <xref target="RFC8754"/>. A segment is | ||||
encoded as an IPv6 address. An ordered list of segments is encoded | ||||
as an ordered list of IPv6 addresses in the routing header. The | ||||
active segment is indicated by the Destination Address of the packet. | ||||
Upon completion of a segment, a pointer in the new routing header is | ||||
incremented and indicates the next segment.</t> | ||||
<t>As per <xref target="RFC8754"/>, an SRv6 Segment is a | Due to the possibility of having many Segment Lists in the same | |||
128-bit value. "SRv6 SID" or simply "SID" are often used as a | Candidate Path of each POL1/POL2, PCECC could provision more paths | |||
shorter reference for "SRv6 Segment". | towards R8 and traffic will be balanced either as ECMP or as w/ECMP. | |||
<xref target="RFC8986"/> defines the SRv6 SID as consisting of LOC:FUNCT:ARG. | ||||
</t> | ||||
<t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> extends | Perhaps: | |||
<xref target="RFC8664"/> to support SR for the IPv6 data plane. Further, | ||||
Due to the possibility of having many segment lists in the same | ||||
candidate path of each POL1/POL2, the PCECC could provision more paths | ||||
towards R8 and traffic will be balanced either as ECMP or as with ECMP. | ||||
--> | ||||
<li> | ||||
The traffic from R1 to R8, which fits to color 100, will be | ||||
steered to POL1 and follows the path: | ||||
R1-link1-R2-link3-R4-R3-R8. The traffic from R1 to R8, which | ||||
fits color 200, will be steered to POL2 and follows the path: | ||||
R1-link2-R2-link4-R5-R6-R8. Due to the possibility of having | ||||
many segment lists in the same candidate path of each | ||||
POL1/POL2, the PCECC could provision more paths towards R8 and | ||||
traffic will be balanced either as ECMP or as w/ECMP. This is | ||||
the advantage of SR Policy architecture. | ||||
</li> | ||||
</ul> | ||||
<t>Note that an SR Policy can be associated with multiple candidate | ||||
paths. A candidate path is selected when it is valid and it is determined to be | ||||
the best path of the SR Policy as described in <xref target="RFC9256" format="de | ||||
fault"/>.</t> | ||||
</section> | ||||
</section> | ||||
<section anchor="sect-8" numbered="true" toc="default"> | ||||
<name>PCECC for SRv6</name> | ||||
<t>As per <xref target="RFC8402" format="default"/>, with Segment | ||||
Routing (SR), a node steers a packet through an ordered list of | ||||
instructions, called segments. Segment Routing can be applied to | ||||
the IPv6 architecture with the Segment Routing Header (SRH) <xref | ||||
target="RFC8754" format="default"/>. A segment is encoded as an | ||||
IPv6 address. An ordered list of segments is encoded as an ordered | ||||
list of IPv6 addresses in the routing header. The active segment is | ||||
indicated by the destination address of the packet. Upon completion | ||||
of a segment, a pointer in the new routing header is incremented and | ||||
indicates the next segment.</t> | ||||
<t>As per <xref target="RFC8754" format="default"/>, an SR over IPv6 | ||||
(SRv6) Segment is a 128-bit value. "SRv6 SID" or simply "SID" are | ||||
often used as a shorter reference for "SRv6 Segment". <xref | ||||
target="RFC8986" format="default"/> defines the SRv6 SID as | ||||
consisting of LOC:FUNCT:ARG.</t> | ||||
<t><xref target="RFC9603" format="default"/> extends | ||||
<xref target="RFC8664" format="default"/> to support SR for the IPv6 data pla | ||||
ne. Further, | ||||
a PCECC could be extended to support SRv6 SID allocation and distribution. | a PCECC could be extended to support SRv6 SID allocation and distribution. | |||
An example of how PCEP extensions could be | An example of how PCEP extensions could be | |||
extended for SRv6 for PCECC is described in <xref target="I-D.dhody-pce-pcep | extended for SRv6 for a PCECC is described in <xref target="I-D.ietf-pce-pce | |||
-extension-pce-controller-srv6"/>.</t> | p-extension-pce-controller-srv6" format="default"/>.</t> | |||
<figure anchor="fig_srv6"> | ||||
<figure title="PCECC for SRv6" anchor="fig_srv6"><artwork> | <name>PCECC for SRv6</name> | |||
<![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
2001:db8::1 | 2001:db8::1 | |||
+----------+ | +----------+ | |||
| R1 | | | R1 | | |||
+----------+ | +----------+ | |||
| | | | |||
+----------+ | +----------+ | |||
| R2 | 2001:db8::2 | | R2 | 2001:db8::2 | |||
+----------+ | +----------+ | |||
* | * * | * | * * | |||
* | * * | * | * * | |||
skipping to change at line 746 ¶ | skipping to change at line 824 ¶ | |||
* | * * + | * | * * + | |||
* | * * + | * | * * + | |||
* | * * + | * | * * + | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
2001:db8::3 | R3 | |R6 |2001:db8::6 | 2001:db8::3 | R3 | |R6 |2001:db8::6 | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | | | |||
+-----------+ | +-----------+ | |||
| R8 | 2001:db8::8 | | R8 | 2001:db8::8 | |||
+-----------+ | +-----------+ | |||
]]> | ]]></artwork> | |||
</artwork></figure> | </figure> | |||
<t>In this case, as shown in <xref target="fig_srv6"/>, PCECC could assign the | <t>In this case, as shown in <xref target="fig_srv6" | |||
SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. La | format="default"/>, the PCECC could assign the SRv6 SID (in the form o | |||
ter, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingre | f | |||
ss. Some examples - | an IPv6 address) to be used for node and adjacency. Later, the SRv6 | |||
<list style="symbols"> | path in the form of a list of SRv6 SIDs could be used at the | |||
<t>SRv6 SID-List={2001:db8::8} - The best path towards R8</t> | ingress. Some examples: | |||
<t>SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via R5</ | </t> | |||
t> | ||||
</list></t> | ||||
<t>The rest of the procedures and mechanisms remain the same as SR-MPLS.</t> | ||||
</section> | ||||
</section> | ||||
<section title="PCECC for Static TE LSP" anchor="sect-5"> | <ul spacing="normal"> | |||
<li> | ||||
The best path towards R8: SRv6 SID-List={2001:db8::8} | ||||
</li> | ||||
<li> | ||||
The path towards R8 via R5: SRv6 SID-List={2001:db8::5, 2001:db8:: | ||||
8} | ||||
</li> | ||||
</ul> | ||||
<t>As described in Section 3.1.2 of <xref target="RFC8283"/>, PCECC architect | <t>The rest of the procedures and mechanisms remain the same as SR-MPL | |||
ure supports | S.</t> | |||
the provisioning of static TE LSP. To achieve this, the | ||||
</section> | ||||
</section> | ||||
<section anchor="sect-5" numbered="true" toc="default"> | ||||
<name>PCECC for Static TE LSPs</name> | ||||
<t>As described in <xref target="RFC8283" section="3.1.2" sectionFormat= | ||||
"of"/>, the PCECC architecture supports | ||||
the provisioning of static TE LSPs. To achieve this, the | ||||
existing PCEP can be used to communicate between the PCECC and | existing PCEP can be used to communicate between the PCECC and | |||
nodes along the path to provision explicit label instructions at each hop on the | nodes along the path to provision explicit label instructions at each hop on the | |||
end-to-end path. Each router along the path must be told what label-forwardi ng instructions to program and what resources to reserve. | end-to-end path. Each router along the path must be told what label-forwardi ng instructions to program and what resources to reserve. | |||
The PCE-based controller keeps a view of the network and determines | The PCE-based controller keeps a view of the network and determines | |||
the paths of the end-to-end LSPs, and the controller uses PCEP to | the paths of the end-to-end LSPs, and the controller uses PCEP to | |||
communicate with each router along the path of the end-to-end LSP.</t> | communicate with each router along the path of the end-to-end LSP.</t> | |||
<figure anchor="fig-te"> | ||||
<figure title="PCECC TE LSP Setup Example" anchor="fig-te"><artwork><![CD | <name>PCECC TE LSP Setup Example</name> | |||
ATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
192.0.2.1/32 | 192.0.2.1/32 | |||
+----------+ | +----------+ | |||
| R1 | | | R1 | | |||
+----------+ | +----------+ | |||
| | | | | | |||
|link1 | | |link1 | | |||
| |link2 | | |link2 | |||
+----------+ | +----------+ | |||
| R2 | 192.0.2.2/32 | | R2 | 192.0.2.2/32 | |||
+----------+ | +----------+ | |||
skipping to change at line 799 ¶ | skipping to change at line 890 ¶ | |||
* | * * + | * | * * + | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
192.0.2.3/32 | R3 | |R6 |192.0.2.6/32 | 192.0.2.3/32 | R3 | |R6 |192.0.2.6/32 | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | | | | | |||
|link8 | | |link8 | | |||
| |link9 | | |link9 | |||
+-----------+ | +-----------+ | |||
| R8 | 192.0.2.8/32 | | R8 | 192.0.2.8/32 | |||
+-----------+ | +-----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Refer to <xref target="fig-te"/> for an example TE topology. | <t>Refer to <xref target="fig-te" format="default"/> for an example TE t | |||
<list style="symbols"> | opology.</t> | |||
<t>Based on path computation request/delegation or PCE initiation, the PCECC | ||||
receives a request with constraints and optimization criteria. </t> | ||||
<t>PCECC will calculate the optimal path according to the given constraints | ||||
(e.g. bandwidth).</t> | ||||
<t>PCECC will provision each node along the path and assign incoming and outgoin | <ul spacing="normal"> | |||
g labels from R1 to R8 with the | <li> | |||
<t>Based on path computation request/delegation or PCE initiation, t | ||||
he PCECC | ||||
receives a request with constraints and optimization criteria.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will calculate the optimal path according to the given | ||||
constraints | ||||
(e.g., bandwidth).</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will provision each node along the path and assign inco | ||||
ming and outgoing labels from R1 to R8 with the | ||||
path as "R1-link1-R2-link3-R4-link10-R3-link8-R8": | path as "R1-link1-R2-link3-R4-link10-R3-link8-R8": | |||
<list style="symbols"> | </t> | |||
<t>R1: Outgoing label 1001 on link 1</t> | <ul spacing="normal"> | |||
<t>R2: Incoming label 1001 on link 1</t> | <li> | |||
<t>R2: Outgoing label 2003 on link 3</t> | <t>R1: Outgoing label 1001 on link 1</t> | |||
<t>R4: Incoming label 2003 on link 3</t> | </li> | |||
<t>R4: Outgoing label 4010 on link 10</t> | <li> | |||
<t>R3: Incoming label 4010 on link 10</t> | <t>R2: Incoming label 1001 on link 1</t> | |||
<t>R3: Outgoing label 3008 on link 8</t> | </li> | |||
<t>R8: Incoming label 3008 on link 8</t> | <li> | |||
</list></t> | <t>R2: Outgoing label 2003 on link 3</t> | |||
<t>This can also be represented as | </li> | |||
{R1, link1, 1001}, {1001, R2, link3, 2003], {2003, R4, link10, 4010}, {4010, | <li> | |||
R3, link8, 3008}, {3008, R8}.</t> | <t>R4: Incoming label 2003 on link 3</t> | |||
</li> | ||||
<t>For the end-to-end protection, PCECC programs each node along the | <li> | |||
path from R1 to R8 with the secondary path: {R1, link2, 1002}, | <t>R4: Outgoing label 4010 on link 10</t> | |||
{1002, R2, link4, 2004], {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3 | </li> | |||
009, R8}.</t> | <li> | |||
<t>R3: Incoming label 4010 on link 10</t> | ||||
</li> | ||||
<li> | ||||
<t>R3: Outgoing label 3008 on link 8</t> | ||||
</li> | ||||
<li> | ||||
<t>R8: Incoming label 3008 on link 8</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>This can also be represented as: {R1, link1, 1001}, {1001, R2, | ||||
link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008}, | ||||
{3008, R8}.</t> | ||||
</li> | ||||
<li> | ||||
<t>For the end-to-end protection, the PCECC programs each node along | ||||
the path from R1 to R8 with the secondary path: {R1, link2, 1002}, | ||||
{1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3, | ||||
link9, 3009}, {3009, R8}.</t> | ||||
</li> | ||||
<li> | ||||
<t>It is also possible to have a bypass path for the local | ||||
protection set up by the PCECC. For example, use the primary path | ||||
as above, then to protect the node R4 locally, the PCECC can program | ||||
the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing | ||||
this, the node R4 is locally protected at R2.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<t>It is also possible to have a bypass path for the local | <section anchor="sect-lb" numbered="true" toc="default"> | |||
protection set up by the PCECC. For example, the primary path as above, then | <name>PCECC for Load Balancing (LB)</name> | |||
to protect the node | <t> | |||
R4 locally, PCECC can program the bypass path like this: | Very often, many service providers use TE tunnels for solving issues | |||
{R2, link5, 2005}, {2005, R3}. By doing | ||||
this, the node R4 is locally protected at R2.</t> | ||||
</list></t> | ||||
</section> | ||||
<section title="PCECC for Load Balancing (LB)" anchor="sect-lb"> | ||||
<t> | ||||
Very often many service providers use TE tunnels for solving issues | ||||
with non-deterministic paths in their networks. One example of such | with non-deterministic paths in their networks. One example of such | |||
applications is the usage of TEs in the mobile backhaul (MBH). | applications is the usage of TEs in the mobile backhaul (MBH). | |||
Consider the topology as shown in <xref target="fig_lb"/> (AGG1...AGGN are Ag gregation Routers, Core 1...Core N are Core routers) - </t> | Consider the topology as shown in <xref target="fig_lb" format="default"/> (w here AGG 1...AGG N are Aggregation routers, and Core 1...Core N are Core routers ). </t> | |||
<figure title="PCECC Load Balancing (LB) Use Case" anchor="fig_lb"><artwo | <!--[rfced] FYI - We have slightly adjusted the spacing and formatting | |||
rk><![CDATA[ | of the ASCII artwork in Figure 6 as it exceeded the 72-character limit. | |||
TE1 --------------> | Please review and let us know if any further changes are necessary. --> | |||
+---------+ +--------+ +--------+ +--------+ +------+ +---+ | ||||
| Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| | <figure anchor="fig_lb"> | |||
| SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ | <name>PCECC Load Balancing (LB) Use Case</name> | |||
+---------+ +--------+ | | | ^ | | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
| Access | Access | AGG Ring 1 | | | | TE1 -----------> | |||
| SubRing 1 | Ring 1 | | | | | | +--------+ +------+ +-----+ +-------+ +------+ +---+ | |||
+---------+ +--------+ +--------+ | | | | |Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1| | |||
| Access | | Access | | AGG 2 | | | | | |SubNode1| |Node 1| +-----+ +-------+ +------+ +---+ | |||
| SubNode2| | Node 2 | +--------+ | | | | +--------+ +------+ | | | ^ | | |||
+---------+ +--------+ | | | | | | | Access | Access | AGG Ring 1| | | | |||
| | | | | | | | | SubRing 1 | Ring 1 | | | | | | |||
| | | +----TE2----|-+ | | +--------+ +------+ +-----+ | | | | |||
+---------+ +--------+ +--------+ +--------+ +------+ +---+ | |Access | |Access| |AGG 2| | | | | |||
| Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| | |SubNode2| |Node 2| +-----+ | | | | |||
| SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ | +--------+ +------+ | | | | | | |||
+---------+ +--------+ | | | | | | | | | |||
| | | +---TE2---|-+ | | ||||
+--------+ +------+ +-----+ +-------+ +------+ +---+ | ||||
|Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn| | ||||
|SubNodeN|----|Node N| +-----+ +-------+ +------+ +---+ | ||||
+--------+ +------+ | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | --------+ <span class="insert">+------+</span> | |||
<t> | </figure> | |||
<t> | ||||
This MBH architecture uses L2 access rings and sub-rings. L3 starts at | This MBH architecture uses L2 access rings and sub-rings. L3 starts at | |||
the aggregation layer. For the sake of simplicity, the figure shows only one access | the aggregation layer. For the sake of simplicity, the figure shows only one access | |||
sub-ring. The access ring and aggregation ring are connected | sub-ring. The access ring and aggregation ring are connected | |||
by Nx10GE interfaces. The aggregation domain runs its own IGP. There are | by Nx10GE interfaces. The aggregation domain runs its own IGP. There are | |||
two Egress routers (AGG N-1, AGG N) that are connected to the Core | two egress routers (AGG N-1 and AGG N) that are connected to the Core | |||
domain (Core 1...Core N) via L2 interfaces. Core also has connections to serv | domain (Core 1...Core N) via L2 interfaces. The Core also has connections to | |||
ice routers, | service routers; | |||
RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be | RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be | |||
at least 2 tunnels (one way) from each AGG router to egress AGG | at least two tunnels (one way) from each AGG router to egress AGG | |||
routers. There are also many L2 access rings connected to AGG routers.</t> | routers. There are also many L2 access rings connected to AGG routers.</t> | |||
<t> | <!-- [rfced] We have removed the parentheses around "Virtual Private LAN | |||
Service deployment is made by means of Layer 2 Virtual Private Networks (L2VP | Services (VPLS)" in the text below. Please review and let us know if this | |||
Ns) (Virtual Private LAN Services (VPLS)), Layer 3 Virtual Private Networks (L3V | changed the intended meaning of the text. | |||
PNs) or Ethernet VPNs (EVPNs). | ||||
Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers | ||||
. | ||||
TE tunnels could be used as transport towards service routers in | ||||
case of seamless MPLS (<xref target="I-D.ietf-mpls-seamless-mpls"/>) based ar | ||||
chitecture.</t> | ||||
<t>Load balancing between TE tunnels involves distributing network traffic ac ross multiple TE tunnels to optimize the use of available network resources, enh ance performance, and ensure reliability. Some common techniques include Equal-C ost Multi-Path (ECMP) and Unequal-Cost Multi-Path (UCMP) based on the bandwidth of the TE tunnels.</t> | Original: | |||
<t>There is a need to solve the following tasks: | Service deployment is made by means of Layer 2 Virtual Private | |||
<list style="symbols"> | Networks (L2VPNs) (Virtual Private LAN Services (VPLS)), Layer 3 | |||
Virtual Private Networks (L3VPNs) or Ethernet VPNs (EVPNs). | ||||
<t>Perform automatic load-balance amongst TE tunnels according to current | Current: | |||
traffic load.</t> | ||||
<t>TE bandwidth (BW) management: Provide guaranteed BW for specific | ||||
services: High-Speed Data Service (HSI)), IPTV, etc., and provide time-ba | ||||
sed BW reservation (BW on demand (BoD)) for other services.</t> | ||||
<t>Simplify the development of TE tunnels by automation without any manual int | ||||
ervention.</t> | ||||
<t>Provide flexibility for Service Router placement (anywhere | Service deployment is made by means of Layer 2 Virtual Private | |||
in the network by the creation of transport LSPs to them).</t> | Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 | |||
</list></t> | Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). | |||
<t>In this section, the focus is on load balancing (LB) tasks. LB task | --> | |||
could be solved by means of PCECC in the following way: | ||||
<list style="symbols"> | ||||
<t>Application or network service or operator can ask the SDN | ||||
controller (PCECC) for LSP-based load balancing between AGG X and AGG N/A | ||||
GG N-1 | ||||
(egress AGG routers that have connections to the core). | ||||
Each of these will have associated constraints (i.e. bandwidth, inclus | ||||
ion or exclusion specific links | ||||
or nodes, number of paths, objective function (OF), need for disjoint LSP | ||||
paths etc.);</t> | ||||
<t>PCECC could calculate multiple (say N) LSPs according to given constra | <t> | |||
ints, | Service deployment is made by means of Layer 2 Virtual Private Networks | |||
the calculation is based on results of Objective Function (OF) <xref targ | (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private | |||
et="RFC5541"/>, constraints, endpoints, same or different | Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE | |||
bandwidth (BW), different links (in case of disjoint paths) and other | (or SR-TE) as transport towards egress AGG routers. TE tunnels could be | |||
constraints.</t> | used as transport towards service routers in case of architecture based on | |||
seamless MPLS <xref target="I-D.ietf-mpls-seamless-mpls" | ||||
format="default"/>. | ||||
</t> | ||||
<t>Load balancing between TE tunnels involves distributing network | ||||
traffic across multiple TE tunnels to optimize the use of available | ||||
network resources, enhance performance, and ensure reliability. Some | ||||
common techniques include Equal-Cost Multipath (ECMP) and | ||||
Unequal-Cost Multipath (UCMP) based on the bandwidth of the TE | ||||
tunnels.</t> | ||||
<t>Depending on the given LSP Path setup type (PST), PCECC will download | <!-- [rfced] To improve readability, may we update this this text | |||
instructions to the PCC. At this stage, it is assumed the PCECC is aware | as follows? Additionally, should "HSI" be listed as an example | |||
of the label space it controls and SID allocation and | of high-speed data services? | |||
distribution is already done in the case of SR.</t> | ||||
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards in | Original: | |||
gress AGG X router(PCC) for each of N LSPs | ||||
and receive PCRpt message <xref target="RFC8231"/> back from | ||||
PCCs. If PST is PCECC-SR, the PCECC will include a SID stack as per <xref | ||||
target="RFC8664"/>. | ||||
If PST is PCECC (basic), then the PCECC will assign labels along the calc | ||||
ulated path and set up the | ||||
path by sending central controller instructions in a PCEP message to each nod | ||||
e along the path of the | ||||
LSP as per <xref target="RFC9050"/> and then | ||||
send PCUpd message to the ingress AGG X router with | ||||
information about new LSP. AGG X(PCC) will respond with PCRpt | ||||
with LSP status.</t> | ||||
<t>AGG X as an ingress router now has N LSPs towards AGG N and AG | * TE bandwidth (BW) management: Provide guaranteed BW for specific | |||
G N-1 | services: High-Speed Data Service (HSI)), IPTV, etc., and provide | |||
which are available for installation to the router's forwarding table and | time-based BW reservation (BW on demand (BoD)) for other services. | |||
load-balance traffic | ||||
between them. Traffic distribution between those LSPs depends on | ||||
the particular realization of the hash-function on that router.</t> | ||||
<t>Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage and | Perhaps: | |||
prevent possible over-subscriptions and limit the number of available loa | ||||
d-balance | ||||
states. Via PCECC mechanism the control can take quick actions into the n | ||||
etwork by directly provisioning the central control instructions.</t> | ||||
</list> | * Manage TE bandwidth (BW) and provide guaranteed BW for specific | |||
</t> | services (such as high-speed data services like High-Speed Internet | |||
(HSI), IPTV, etc.) and provide time-based BW reservation (such as | ||||
Bandwidth on Demand (BoD)) for other services. | ||||
--> | ||||
</section> | <t>There is a need to solve the following tasks: | |||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>Perform automatic load balancing amongst TE tunnels according to | ||||
current traffic loads.</t> | ||||
</li> | ||||
<li> | ||||
<t>TE bandwidth (BW) management: Provide guaranteed BW for specific | ||||
services: High-Speed Data Service (HSI)), IPTV, etc., and provide | ||||
time-based BW reservation (BW on demand (BoD)) for other services.</t> | ||||
</li> | ||||
<li> | ||||
<t>Simplify the development of TE tunnels by automation without any | ||||
manual intervention.</t> | ||||
</li> | ||||
<li> | ||||
<t>Provide flexibility for service router placement | ||||
(anywhere in the network by the creation of transport LSPs to | ||||
them).</t> | ||||
</li> | ||||
</ul> | ||||
<t>In this section, the focus is on load balancing (LB) tasks. LB tasks | ||||
could be solved by means of the PCECC in the following ways: | ||||
</t> | ||||
<section title="PCECC and Inter-AS TE" anchor="sect-5.1"> | <ul spacing="normal"> | |||
<t> | <li> | |||
There are various signalling options for establishing Inter-AS TE LSP: | <t>Applications, network services, or operators can ask the SDN | |||
contiguous TE LSP <xref target="RFC5151"/>, stitched TE LSP <xref target="RFC | controller (PCECC) for LSP-based load balancing between AGG X and | |||
5150"/>, | AGG N/AGG N-1 (egress AGG routers that have connections to the | |||
and nested TE LSP <xref target="RFC4206"/>.</t> | core). Each of these will have associated constraints | |||
(such as bandwidth, inclusion or exclusion of specific links or node | ||||
s, | ||||
number of paths, Objective Function (OF), need for disjoint LSP | ||||
paths, etc.).</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC could calculate multiple (say N) LSPs according to give | ||||
n | ||||
constraints. The calculation is based on the results of Objective Fu | ||||
nction (OF) <xref target="RFC5541" format="default"/>, | ||||
constraints, endpoints, same or different bandwidth (BW), | ||||
different links (in case of disjoint paths), and other | ||||
constraints.</t> | ||||
</li> | ||||
<li> | ||||
<t>Depending on the given LSP Path Setup Type (PST), the PCECC will | ||||
download instructions to the PCC. At this stage, it is assumed the | ||||
PCECC is aware of the label space it controls and SID allocation | ||||
and distribution is already done in the case of SR.</t> | ||||
</li> | ||||
<t> | <!-- [rfced] FYI - We have broken up the sentence below to improve readability. | |||
Requirements for PCE-based Inter-AS setup <xref target="RFC5376"/> describe t | Please review and let us know if any further updates are necessary. | |||
he approach | ||||
and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t> | ||||
<t> | Original: | |||
<xref target="RFC5376"/> also gives Inter- and Intra-AS PCE Reference Model ( | ||||
as shown in <xref target="fig_short"/>) that is | ||||
provided below in shortened form for the sake of simplicity.</t> | ||||
<figure title="Shortened form of Inter- and Intra-AS PCE Reference Model" | If PST is PCECC (basic), then the PCECC | |||
anchor="fig_short"><artwork><![CDATA[ | will assign labels along the calculated path and set up the path | |||
by sending central controller instructions in a PCEP message to | ||||
each node along the path of the LSP as per [RFC9050] and then send | ||||
PCUpd message to the ingress AGG X router with information about | ||||
new LSP. | ||||
Current: | ||||
If the PST is a PCECC (basic), then the PCECC | ||||
will assign labels along the calculated path and set up the path | ||||
by sending central controller instructions in a PCEP message to | ||||
each node along the path of the LSP as per [RFC9050]. Then, the | ||||
PCECC will send a PCUpd message to the ingress AGG X router with | ||||
information about the new LSP. | ||||
--> | ||||
<li> | ||||
<t>The PCECC will send a PCInitiate message <xref target="RFC8281" | ||||
format="default"/> towards the ingress AGG X router (PCC) for each o | ||||
f | ||||
N LSPs and receive a PCRpt message <xref target="RFC8231" | ||||
format="default"/> back from PCCs. If the PST is a PCECC-SR, the PCE | ||||
CC | ||||
will include a SID stack as per <xref target="RFC8664" | ||||
format="default"/>. If the PST is a PCECC (basic), then the PCECC w | ||||
ill | ||||
assign labels along the calculated path and set up the path by | ||||
sending central controller instructions in a PCEP message to each | ||||
node along the path of the LSP as per <xref target="RFC9050" | ||||
format="default"/>. Then, the PCECC will send a PCUpd message to the | ||||
ingress AGG | ||||
X router with information about the new LSP. AGG X (PCC) will respon | ||||
d | ||||
with a PCRpt with LSP status.</t> | ||||
</li> | ||||
<li> | ||||
<t>AGG X as an ingress router now has N LSPs towards AGG N and AGG N | ||||
-1, | ||||
which are available for installation to the router's forwarding table and | ||||
for load balancing traffic | ||||
between them. Traffic distribution between those LSPs depends on | ||||
the particular realization of the hash function on that router.</t> | ||||
</li> | ||||
<li> | ||||
<t>Since the PCECC is aware of the TEDB (TE state) and the LSP Datab | ||||
ase (LSP-DB), it can manage and | ||||
prevent possible over-subscriptions and limit the number of available loa | ||||
d-balance | ||||
states. Via a PCECC mechanism, the control can take quick actions into th | ||||
e network by directly provisioning the central control instructions.</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section anchor="sect-5.1" numbered="true" toc="default"> | ||||
<name>PCECC and Inter-AS TE</name> | ||||
<t> | ||||
There are various signalling options for establishing Inter-AS TE | ||||
LSPs: contiguous TE LSPs <xref target="RFC5151" format="default"/>, | ||||
stitched TE LSPs <xref target="RFC5150" format="default"/>, and | ||||
nested TE LSPs <xref target="RFC4206" format="default"/>.</t> | ||||
<t> | ||||
The requirements for PCE-based Inter-AS setup <xref target="RFC5376" format=" | ||||
default"/> describe the approach | ||||
and PCEP functionality that is needed for establishing Inter-AS TE LSPs.</t> | ||||
<t> | ||||
<xref target="RFC5376" format="default"/> also gives an Inter-AS and | ||||
Intra-AS PCE Reference Model (as shown in <xref target="fig_short" | ||||
format="default"/>) that is provided below in shortened form for the sake | ||||
of simplicity.</t> | ||||
<figure anchor="fig_short"> | ||||
<name>Shortened Form of the Inter-AS and Intra-AS PCE Reference Model< | ||||
/name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
Inter-AS Inter-AS | Inter-AS Inter-AS | |||
PCC <-->PCE1<--------->PCE2 | PCC <-->PCE1<--------->PCE2 | |||
:: :: :: | :: :: :: | |||
:: :: :: | :: :: :: | |||
R1----ASBR1====ASBR3---R3---ASBR5 | R1----ASBR1====ASBR3---R3---ASBR5 | |||
| AS1 | | PCC | | | AS1 | | PCC | | |||
| | | AS2 | | | | | AS2 | | |||
R2----ASBR2====ASBR4---R4---ASBR6 | R2----ASBR2====ASBR4---R4---ASBR6 | |||
:: :: | :: :: | |||
:: :: | :: :: | |||
skipping to change at line 964 ¶ | skipping to change at line 1178 ¶ | |||
:: :: :: | :: :: :: | |||
:: :: :: | :: :: :: | |||
R1----ASBR1====ASBR3---R3---ASBR5 | R1----ASBR1====ASBR3---R3---ASBR5 | |||
| AS1 | | PCC | | | AS1 | | PCC | | |||
| | | AS2 | | | | | AS2 | | |||
R2----ASBR2====ASBR4---R4---ASBR6 | R2----ASBR2====ASBR4---R4---ASBR6 | |||
:: :: | :: :: | |||
:: :: | :: :: | |||
Intra-AS Intra-AS | Intra-AS Intra-AS | |||
PCE3 PCE4 | PCE3 PCE4 | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>The PCECC belonging to the different domains can cooperate to set | ||||
<t>The PCECC belonging to the different domains can cooperate to set up inter- | up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism <xr | |||
AS TE LSP. The stateful H-PCE <xref target="RFC8751"/> mechanism could also be u | ef | |||
sed to establish a per-domain PCECC | target="RFC8751" format="default"/> could also be used to establish a | |||
LSP first. These could be stitched together to form inter-AS TE LSP as descr | per-domain PCECC LSP first. These could be stitched together to form | |||
ibed in <xref target="I-D.ietf-pce-stateful-interdomain"/>.</t> | an Inter-AS TE LSP as described in <xref | |||
<t> | target="I-D.ietf-pce-stateful-interdomain" format="default"/>.</t> | |||
For the sake of simplicity, here the focus is on a simplified Inter-AS case w | <t> | |||
hen both AS1 and | For the sake of simplicity, here the focus is on a simplified | |||
AS2 belong to the same service provider administration. In that case, Inter | Inter-AS case when both AS1 and AS2 belong to the same service | |||
and Intra-AS PCEs could be combined in one single PCE if such combined PCE | provider administration. In that case, Inter-AS and Intra-AS PCEs could | |||
performance is enough to handle the load. The PCE will require | be combined in one single PCE if such combined PCE performance is | |||
interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy | enough to handle the load. The PCE will require interfaces (PCEP | |||
mechanisms are described in <xref target="RFC8283"/>. Thus routers (PCCs) in | and BGP-LS) to both domains. PCECC redundancy mechanisms are | |||
AS1 and AS2 | described in <xref target="RFC8283" format="default"/>. Thus, routers | |||
can send PCEP messages towards the same PCECC. In <xref target="fig_inter_as_ | (PCCs) in AS1 and AS2 can send PCEP messages towards the same | |||
pce"/>, PCECC maintains a BGP-LS session with route reflectors (RRs) in each AS. | PCECC. In <xref target="fig_inter_as_pce" format="default"/>, the PCECC | |||
This allows the RRs to redistribute routes to other BGP routers (clients) witho | maintains a BGP-LS session with Route Reflectors (RRs) in each | |||
ut requiring a full mesh. The RRs act as BGP-LS Propagator and PCECC act as a BG | AS. This allows the RRs to redistribute routes to other BGP routers | |||
P-LS Consumer <xref target="RFC9552"/>.</t> | (clients) without requiring a full mesh. The RRs act as a BGP-LS | |||
Propagator, and the PCECC acts as a BGP-LS Consumer <xref target="RFC95 | ||||
<figure title="Particular case of Inter-AS PCE" anchor="fig_inter_as_pce" | 52" | |||
><artwork><![CDATA[ | format="default"/>.</t> | |||
<figure anchor="fig_inter_as_pce"> | ||||
<name>Particular Case of Inter-AS PCE</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+----BGP-LS------+ +------BGP-LS-----+ | +----BGP-LS------+ +------BGP-LS-----+ | |||
| | | | | | | | | | |||
+-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ | +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ | |||
+-:------|----::-:-+ +--::-:-|-------:---+ | +-:------|----::-:-+ +--::-:-|-------:---+ | |||
| : | :: : | | :: : | : | | | : | :: : | | :: : | : | | |||
| : RR1 :: : | | :: : RR2 : | | | : RR1 :: : | | :: : RR2 : | | |||
| v v: : | LSP1 | :: v v | | | v v: : | LSP1 | :: v v | | |||
| R1---------ASBR1=======================ASBR3--------R3 | | | R1---------ASBR1=======================ASBR3--------R3 | | |||
| | v : | | :v | | | | | v : | | :v | | | |||
| +----------ASBR2=======================ASBR4---------+ | | | +----------ASBR2=======================ASBR4---------+ | | |||
skipping to change at line 998 ¶ | skipping to change at line 1222 ¶ | |||
| | v : | | :v | | | | | v : | | :v | | | |||
| +----------ASBR2=======================ASBR4---------+ | | | +----------ASBR2=======================ASBR4---------+ | | |||
| | Region 1 : | | : Region 1 | | | | | Region 1 : | | : Region 1 | | | |||
|----------------:-| |--:-------------|--| | |----------------:-| |--:-------------|--| | |||
| | v | LSP2 | v | | | | | v | LSP2 | v | | | |||
| +----------ASBR5=======================ASBR6---------+ | | | +----------ASBR5=======================ASBR6---------+ | | |||
| Region 2 | | Region 2 | | | Region 2 | | Region 2 | | |||
+------------------+ <--------------> +-------------------+ | +------------------+ <--------------> +-------------------+ | |||
MPLS Domain 1 Inter-AS MPLS Domain 2 | MPLS Domain 1 Inter-AS MPLS Domain 2 | |||
<=======AS1=======> <========AS2=======> | <=======AS1=======> <========AS2=======> | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
In the case of the PCECC Inter-AS TE scenario (as shown in <xref target="fig_ | In the case of the PCECC Inter-AS TE scenario (as shown in <xref target="fig_ | |||
inter_as_pce"/>) where the service provider | inter_as_pce" format="default"/>), where the service provider | |||
controls both domains (AS1 and AS2), each of them has its own IGP and MPLS | controls both domains (AS1 and AS2), each of them has its own IGP and MPLS | |||
transport. There is a need to set up Inter-AS LSPs for transporting different | transport. There is a need to set up Inter-AS LSPs for transporting different | |||
services on top of them (Voice, L3VPN etc.). Inter-AS links with different | services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with dif ferent | |||
capacities exist in several regions. The task is not only to provision | capacities exist in several regions. The task is not only to provision | |||
those Inter-AS LSPs with given constraints but also to calculate the path | those Inter-AS LSPs with given constraints but also to calculate the path | |||
and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP f ails.</t> | and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP f ails.</t> | |||
<t> | <!-- [rfced] To parallel the preceding sentence, may we update "R1-R3 LSP2" | |||
As per <xref target="fig_inter_as_pce"/>, LSP1 from R1 to R3 goes via ASBR1 | to be "LSP2 from R1 to R3"? | |||
and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via | ||||
ASBR5 and ASBR6 are the backup ones. In addition, there could also be a bypas | ||||
s LSP | ||||
setup to protect against ASBR or inter-AS link failures.</t> | ||||
<t> | Original: | |||
After the addition of PCECC functionality to PCE (SDN controller), the PCECC- | ||||
based Inter-AS TE model should follow the PCECC use case for TE LSP | ||||
including requirements of <xref target="RFC5376"/> with the following details | ||||
: | ||||
<list style="symbols"> | As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it | |||
<t>Since PCECC needs to know the topology of both domains AS1 and AS2, PC | is the primary Inter-AS LSP. R1-R3 LSP2 that goes via ASBR5 and | |||
ECC | ASBR6 are the backup ones. | |||
Perhaps: | ||||
As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it | ||||
is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and | ||||
ASBR6 is the backup one. | ||||
--> | ||||
<t> | ||||
As per <xref target="fig_inter_as_pce" format="default"/>, LSP1 from R1 to R | ||||
3 goes via ASBR1 | ||||
and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via | ||||
ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass | ||||
LSP | ||||
setup to protect against ASBR or Inter-AS link failures.</t> | ||||
<t> | ||||
After the addition of PCECC functionality to the PCE (SDN controller), | ||||
the PCECC-based Inter-AS TE model should follow the PCECC use case | ||||
for TE LSP including the requirements described in <xref target="RFC537 | ||||
6" | ||||
format="default"/> with the following details: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>Since the PCECC needs to know the topology of both domains AS1 an | ||||
d AS2, the PCECC | ||||
can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. </t> | can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. </t> | |||
</li> | ||||
<li> | ||||
<t>The PCECC needs to establish PCEP connectivity with all routers i | ||||
n both | ||||
domains (see also <xref target="RFC5376" section="4" sectionFormat="of"/> | ||||
).</t> | ||||
</li> | ||||
<t>PCECC needs to establish PCEP connectivity with all routers in both | <!-- [rfced] We have broken up the sentence below to improve readability. | |||
domains (see also section 4 in <xref target="RFC5376"/>).</t> | Please review and let us know if any further updates are necessary. | |||
<t>After the operator's application or service orchestrator creates a req | Original: | |||
uest | ||||
for tunnel creation of a specific service, PCECC will receive that reques | ||||
t via NBI | ||||
(NBI type is implementation dependent, it could be NETCONF/Yang, REST etc | ||||
.). Then | ||||
PCECC will calculate the optimal path based on Objective Function (OF) an | ||||
d given | ||||
constraints (i.e. path setup type, bandwidth etc.), including those from | ||||
<xref target="RFC5376"/>: | ||||
priority, AS sequence, preferred ASBR, disjoint paths, and protection typ | ||||
e. In this | ||||
step, we will have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3</t> | ||||
<t>PCECC will use central control download | Then PCECC will calculate the optimal path based on Objective Function | |||
instructions to the PCC based on the PST. At this stage, it is assumed the P | (OF) and given constraints (i.e. path setup type, bandwidth etc.), | |||
CECC is aware | including those from [RFC5376]: priority, AS sequence, preferred ASBR, | |||
of the label space it controls and in the case of SR the SID allocation and | disjoint paths, and protection type. | |||
distribution is already done.</t> | ||||
<t>PCECC will send PCInitiate message <xref target="RFC8281"/> towards the ing | Current: | |||
ress router R1 (PCC) in AS1 | ||||
and receive the PCRpt message <xref target="RFC8231"/> back from it. | ||||
<list style="symbols"> | ||||
<t>If the PST is SR-MPLS, the PCECC will include the SID stack as per | ||||
<xref target="RFC8664"/>. | ||||
Optionally, a binding SID or BGP Peering-SID <xref target="RFC9087"/> can | ||||
also be included on the AS boundary. The backup SID stack can be installed at i | ||||
ngress R1 but more importantly, | ||||
each node along the SR path could also do the local protection just based | ||||
on the top segment.</t> | ||||
<t>If the PST is PCECC, the PCECC will assign labels along the calculated | ||||
paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and sets up the | ||||
path by sending central controller instructions in PCEP message to each node | ||||
along the path of the | ||||
LSPs as per <xref target="RFC9050"/>. After these steps, the PCECC will send | ||||
a PCUpd message to the ingress R1 router with information about new LSPs and R1 | ||||
will respond by PCRpt with LSP(s) status.</t></list></t> | ||||
<!--<t>AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 | Then, the PCECC will calculate the optimal path based on Objective Functio | |||
n | ||||
(OF) and given constraints (i.e., path setup type, bandwidth, etc.). | ||||
These constraints include those from [RFC5376], such as priority, | ||||
AS sequence, preferred ASBR, disjoint paths, and protection type. | ||||
--> | ||||
<li> | ||||
<t>After the operator's application or service orchestrator | ||||
creates a request for tunnel creation of a specific service, the PCE | ||||
CC | ||||
will receive that request via NBI (note that the NBI type is | ||||
implementation-dependent; it could be NETCONF/YANG, REST, | ||||
etc.). Then, the PCECC will calculate the optimal path based on Obje | ||||
ctive Function (OF) and | ||||
given constraints (i.e., path setup type, bandwidth, etc.). These co | ||||
nstraints include | ||||
those from <xref target="RFC5376" format="default"/>, such as | ||||
priority, AS sequence, preferred ASBR, disjoint paths, and | ||||
protection type. In this step, we will have two paths: | ||||
R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will use central control download instructions to the P | ||||
CC | ||||
based on the PST. At this stage, it is assumed the PCECC is aware | ||||
of the label space it controls, and in the case of SR, the SID | ||||
allocation and distribution is already done.</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will send a PCInitiate message <xref target="RFC8281" | ||||
format="default"/> towards the ingress router R1 (PCC) in AS1 and | ||||
receive the PCRpt message <xref target="RFC8231" | ||||
format="default"/> back from it. | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>If the PST is SR-MPLS, the PCECC will include the SID stack | ||||
as per <xref target="RFC8664" format="default"/>. Optionally, | ||||
a BSID or BGP Peering-SID <xref target="RFC9087" | ||||
format="default"/> can also be included on the AS | ||||
boundary. The backup SID stack can be installed at ingress R1, | ||||
but more importantly, each node along the SR path could also | ||||
do the local protection just based on the top segment.</t> | ||||
</li> | ||||
<li> | ||||
<t>If the PST is a PCECC, the PCECC will assign labels along the | ||||
calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and | ||||
sets up the path by sending central controller instructions in a | ||||
PCEP message to each node along the path of the LSPs as per | ||||
<xref target="RFC9050" format="default"/>. After these steps, | ||||
the PCECC will send a PCUpd message to the ingress R1 router | ||||
with information about new LSPs and R1 will respond by a PCRpt | ||||
with LSP(s) status.</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<!-- [auth] <t>AGG X as ingress router now have N LSPs towards AGG N a | ||||
nd AGG N-1 | ||||
which are available for installing to router's forwarding table and load- balance a traffic | which are available for installing to router's forwarding table and load- balance a traffic | |||
between them. Traffic distribution between those LSPs depends on | between them. Traffic distribution between those LSPs depends on | |||
particular realization of hash-function on that router.</t>--> | particular realization of hash-function on that router.</t>--> | |||
<t>After that step, R1 now have primary and backup TEs (LSP1 and LSP2) to | <li> | |||
wards | <t>After that step, R1 now has primary and backup TEs (LSP1 and LSP2 | |||
R3. It is up to router implementation how to make switchover to backup LS | ) towards | |||
P2 if LSP1 fails.</t> | R3. It is up to the router implementation for how to switchover to backup | |||
LSP2 if LSP1 fails.</t> | ||||
</list></t> | </li> | |||
</section> | </ul> | |||
</section> | ||||
<section title="PCECC for Multicast LSPs" anchor="sect-6"><t> | <section anchor="sect-6" numbered="true" toc="default"> | |||
<name>PCECC for Multicast LSPs</name> | ||||
<t> | ||||
The multicast LSPs can be set up via the RSVP-TE P2MP or | The multicast LSPs can be set up via the RSVP-TE P2MP or | |||
Multipoint LDP (mLDP) protocols. The setup of these LSPs may require | Multipoint LDP (mLDP) protocols. The setup of these LSPs may require | |||
manual configurations and complex signalling when the | manual configurations and complex signalling when the | |||
protection is considered. By using the PCECC solution, the multicast | protection is considered. By using the PCECC solution, the multicast | |||
LSP can be computed and set up through a centralized controller which | LSP can be computed and set up through a centralized controller that | |||
has the full picture of the topology and bandwidth usage for each | has the full picture of the topology and bandwidth usage for each | |||
link. It not only reduces the complex configurations comparing the | link. It not only reduces the complex configurations comparing the | |||
distributed RSVP-TE P2MP or mLDP signalling, but also it can | distributed RSVP-TE P2MP or mLDP signalling, but also it can | |||
compute the disjoint primary path and secondary P2MP path efficiently.</t> | compute the disjoint primary path and secondary P2MP path efficiently.</t> | |||
<section title="PCECC for P2MP/MP2MP LSPs' Setup" anchor="sect-6.1"> | <section anchor="sect-6.1" numbered="true" toc="default"> | |||
<!--<t> | <name>PCECC for the Setup of P2MP/MP2MP LSPs</name> | |||
<!-- [auth] <t> | ||||
With the capability of global label and local label existing at the | With the capability of global label and local label existing at the | |||
same time in the PCECC network, PCECC will use compute, setup and | same time in the PCECC network, PCECC will use compute, setup and | |||
maintain the P2MP and MP2MP lsp using the local label range for each | maintain the P2MP and MP2MP lsp using the local label range for each | |||
network nodes.</t>--> | network nodes.</t>--> | |||
<t>It is assumed the PCECC is aware of the label space it controls for | <t>It is assumed the PCECC is aware of the label space it controls for | |||
all nodes and makes allocations accordingly.</t> | all nodes and makes allocations accordingly.</t> | |||
<figure title="Using PCECC for P2MP/MP2MP LSPs' Setup" anchor="fig_p2mp"> | <!--[rfced] We note that Figure 9 abbreviates links as "L1", "L2", etc., while | |||
<artwork><![CDATA[ | Figures 2, 3, 4, and 5 use "link1", "link2", etc. Should Figure 9 be updated | |||
to also use "link1", "link2", etc. to reflect the other figures in this document | ||||
? | ||||
--> | ||||
<figure anchor="fig_p2mp"> | ||||
<name>Using a PCECC for the Setup of P2MP/MP2MP LSPs</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+----------+ | +----------+ | |||
| R1 | Root node of the multicast LSP | | R1 | Root Node of the multicast LSP | |||
+----------+ | +----------+ | |||
|9000 (L0) | |9000 (L0) | |||
+----------+ | +----------+ | |||
Transit Node | R2 | | Transit Node | R2 | | |||
branch +----------+ | branch +----------+ | |||
* | * * | * | * * | |||
9001* | * *9002 | 9001* | * *9002 | |||
L1 * | * *L2 | L1 * | * *L2 | |||
+-----------+ | * +-----------+ | +-----------+ | * +-----------+ | |||
| R4 | | * | R5 | Transit Nodes | | R4 | | * | R5 | Transit Nodes | |||
skipping to change at line 1105 ¶ | skipping to change at line 1399 ¶ | |||
* | * * + | * | * * + | |||
9003* | * * +9004 | 9003* | * * +9004 | |||
L3 * | * * +L4 | L3 * | * * +L4 | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
| R3 | | R6 | Leaf Node | | R3 | | R6 | Leaf Node | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
9005| L5 | 9005| L5 | |||
+-----------+ | +-----------+ | |||
| R8 | Leaf Node | | R8 | Leaf Node | |||
+-----------+ | +-----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>The P2MP examples (based on <xref target="fig_p2mp"/>) are explained here, | <t>The P2MP examples (based on <xref target="fig_p2mp" format="default | |||
where R1 is the root and the router R8 and R6 are the leaves. | "/>) are explained here, where R1 is the root and the routers R8 and R6 are the | |||
<list style="symbols"> | leaves. | |||
<t>Based on the P2MP path computation request/delegation or PCE initiation, the | </t> | |||
PCECC | <ul spacing="normal"> | |||
<li> | ||||
<t>Based on the P2MP path computation request/delegation or PCE in | ||||
itiation, the PCECC | ||||
receives the request with constraints and optimization criteria. </t> | receives the request with constraints and optimization criteria. </t> | |||
</li> | ||||
<li> | ||||
<t>The PCECC will calculate the optimal P2MP path according to giv | ||||
en constraints | ||||
(i.e., bandwidth).</t> | ||||
</li> | ||||
<li> | ||||
<t>The PCECC will provision each node along the path and assign in | ||||
coming and outgoing labels from R1 to {R6, R8} with the | ||||
path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8": | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>R1: Outgoing label 9000 on link L0</t> | ||||
</li> | ||||
<li> | ||||
<t>R2: Incoming label 9000 on link L0</t> | ||||
</li> | ||||
<li> | ||||
<t>R2: Outgoing label 9001 on link L1 (*)</t> | ||||
</li> | ||||
<li> | ||||
<t>R2: Outgoing label 9002 on link L2 (*)</t> | ||||
</li> | ||||
<li> | ||||
<t>R5: Incoming label 9002 on link L2</t> | ||||
</li> | ||||
<li> | ||||
<t>R5: Outgoing label 9004 on link L4</t> | ||||
</li> | ||||
<li> | ||||
<t>R6: Incoming label 9004 on link L4</t> | ||||
</li> | ||||
<li> | ||||
<t>R4: Incoming label 9001 on link L1</t> | ||||
</li> | ||||
<li> | ||||
<t>R4: Outgoing label 9003 on link L3</t> | ||||
</li> | ||||
<li> | ||||
<t>R3: Incoming label 9003 on link L3</t> | ||||
</li> | ||||
<li> | ||||
<t>R3: Outgoing label 9005 on link L5</t> | ||||
</li> | ||||
<li> | ||||
<t>R8: Incoming label 9005 on link L5</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>This can also be represented as: {R1, 6000}, {6000, R2, | ||||
{9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, | ||||
9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the | ||||
branch node instruction at R2, where two copies of a packet are | ||||
sent towards R4 and R5 with 9001 and 9002 labels, respectively.</t | ||||
> | ||||
</li> | ||||
</ul> | ||||
<t>The packet forwarding involves the following:</t> | ||||
<ol type="Step %d."> | ||||
<li>R1 sends a packet to R2 simply by pushing the label of 9000 to | ||||
the packet.</li> | ||||
<li>When R2 receives the packet with label 9000, it will forward | ||||
it to R4 by swapping label 9000 to 9001. At the same time, it will | ||||
replicate the packet and swap the label 9000 to 9002 and forward | ||||
it to R5.</li> | ||||
<li>When R4 receives the packet with label 9001, it will forward | ||||
it to R3 by swapping 9001 to 9003. When R5 receives the packet | ||||
with the label 9002, it will forward it to R6 by swapping 9002 to | ||||
9004.</li> | ||||
<li>When R3 receives the packet with label 9003, it will forward | ||||
it to R8 by swapping it to 9005. When R5 receives the packet with | ||||
label 9002, it will be swapped to 9004 and sent to R6.</li> | ||||
<li>When R8 receives the packet with label 9005, it will pop the | ||||
label. When R6 receives the packet with label 9004, it will pop | ||||
the label.</li> | ||||
</ol> | ||||
</section> | ||||
<section anchor="sect-6.2" numbered="true" toc="default"> | ||||
<t>PCECC will calculate the optimal P2MP path according to given constraints | <!-- [rfced] We have updated the following text to make them complete | |||
(i.e.bandwidth).</t> | sentences. Please review and let us know if further updates are necessary. | |||
<t>PCECC will provision each node along the path and assign incoming and outgoin | a) Section 3.6.2: | |||
g labels from R1 to {R6, R8} with the | Original: | |||
path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8": | ||||
<list style="symbols"> | ||||
<t>R1: Outgoing label 9000 on link L0</t> | ||||
<t>R2: Incoming label 9000 on link L0</t> | ||||
<t>R2: Outgoing label 9001 on link L1 (*)</t> | ||||
<t>R2: Outgoing label 9002 on link L2 (*)</t> | ||||
<t>R5: Incoming label 9002 on link L2</t> | ||||
<t>R5: Outgoing label 9004 on link L4</t> | ||||
<t>R6: Incoming label 9004 on link L4</t> | ||||
<t>R4: Incoming label 9001 on link L1</t> | ||||
<t>R4: Outgoing label 9003 on link L3</t> | ||||
<t>R3: Incoming label 9003 on link L3</t> | ||||
<t>R3: Outgoing label 9005 on link L5</t> | ||||
<t>R8: Incoming label 9005 on link L5</t> | ||||
</list></t> | ||||
<t>This can also be represented as | In this section, the end-to-end managed path protection service as | |||
: {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {90 | well as the local protection with the operation management in the | |||
03, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) | PCECC network for the P2MP/MP2MP LSP. | |||
is in the branch node instruction at R2 where two copies of a packet are sent | ||||
towards R4 and R5 with 9001 and 9002 labels respectively.</t> | ||||
</list></t> | Current: | |||
<t>The packet forwarding involves - | ||||
<list> | ||||
<t> | ||||
Step 1: R1 sends a packet to R2 simply by pushing the label of | ||||
9000 to the packet.</t> | ||||
<t> | This section describes the end-to-end managed path protection service as | |||
Step 2: When R2 receives the packet with label 9000, it will | well as the local protection with operation management in the | |||
forward it to R4 by swapping label 9000 to 9001 and at the same time, | PCECC network for the P2MP/MP2MP LSP. | |||
it will replicate the packet and swap the label 9000 to 9002 and forward it t | ||||
o R5.</t> | ||||
<t> | b) Appendix A.4: | |||
Step 3: When R4 receives the packet with label 9001, it will | Original: | |||
forward it to R3 by swapping 9001 to 9003. When R5 receives the | ||||
packet with the label 9002, it will forward it to R6 by swapping 9002 to | ||||
9004.</t> | ||||
<t> | In Hadoop (https://hadoop.apache.org/) 1.0 | |||
Step 4: When R3 receives the packet with label 9003, it will | architecture MapReduce operations on big data in the Hadoop | |||
forward it to R8 by swapping it to 9005 and when R5 receives the | Distributed File System (HDFS), where NameNode knows about resources | |||
packet with label 9002, it will be swapped to 9004 and sent to R6.</t> | of the cluster and where actual data (chunks) for a particular task | |||
are located (which DataNode). | ||||
<t>Step 5: When R8 receives the packet with label 9005, it will pop the label | Current: | |||
; when R6 receives the packet with label 9004, it will pop the label.</t> | ||||
</list></t> | ||||
</section> | ||||
<section title="PCECC for the End-to-End Protection of P2MP/MP2MP LSPs" | In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce | |||
anchor="sect-6.2"><t> | operations occur on big data in the Hadoop Distributed File System (HDFS), wh | |||
In this section, the end-to-end managed path protection | ere | |||
NameNode knows about resources of the cluster and where actual data | ||||
(chunks) for a particular task are located (which DataNode). | ||||
--> | ||||
<name>PCECC for the End-to-End Protection of P2MP/MP2MP LSPs</name> | ||||
<t> | ||||
This section describes the end-to-end managed path protection | ||||
service as well as the local protection with the operation management in the | service as well as the local protection with the operation management in the | |||
PCECC network for the P2MP/MP2MP LSP.</t> | PCECC network for the P2MP/MP2MP LSP.</t> | |||
<t> | ||||
<t> | ||||
An end-to-end protection principle can be | An end-to-end protection principle can be | |||
applied for computing backup P2MP or MP2MP LSPs. During the computation | applied for computing backup P2MP or MP2MP LSPs. During the computation | |||
of the primary multicast trees, PCECC could also take the computation of a se condary tree into | of the primary multicast trees, the PCECC could also take the computation of a secondary tree into | |||
consideration. A PCECC could compute the | consideration. A PCECC could compute the | |||
primary and backup P2MP (or MP2MP) LSPs together or sequentially.</t> | primary and backup P2MP (or MP2MP) LSPs together or sequentially.</t> | |||
<figure anchor="fig_p2mp-res"> | ||||
<figure title="PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs | <name>PCECC for the End-to-End Protection of P2MP/MP2MP LSPs</name> | |||
" anchor="fig_p2mp-res"><artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
+----+ +----+ | +----+ +----+ | |||
Root node of LSP | R1 |--| R11| | Root Node of LSP | R1 |--| R11| | |||
+----+ +----+ | +----+ +----+ | |||
/ + | / + | |||
10/ +20 | 10/ +20 | |||
/ + | / + | |||
+----------+ +-----------+ | +----------+ +-----------+ | |||
Transit Node | R2 | | R3 | | Transit Node | R2 | | R3 | | |||
+----------+ +-----------+ | +----------+ +-----------+ | |||
| \ + + | | \ + + | |||
| \ + + | | \ + + | |||
10| 10\ +20 20+ | 10| 10\ +20 20+ | |||
| \ + + | | \ + + | |||
| \ + | | \ + | |||
| + \ + | | + \ + | |||
+-----------+ +-----------+ Leaf Nodes | +-----------+ +-----------+ Leaf Nodes | |||
| R4 | | R5 | (Downstream LSR) | | R4 | | R5 | (Downstream LSR) | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
In <xref target="fig_p2mp-res"/>, when the PCECC setups the primary multicast | In <xref target="fig_p2mp-res" format="default"/>, when the PCECC sets up the | |||
tree | primary multicast tree | |||
from the root node R1 to the leaves, which is R1->R2->{R4, R5}, at the | from the root node R1 to the leaves, which is R1->R2->{R4, R5}, it can | |||
same time, it can setup the backup tree, which is R1->R11->R3->{R4, | set up the backup tree at the same time, which is R1->R11->R3->{R4, R5} | |||
R5}. | . | |||
Both of them (primary forwarding tree and secondary forwarding | Both of them (the primary forwarding tree and secondary forwarding | |||
tree) will be downloaded to each router along the primary path and | tree) will be downloaded to each router along the primary path and | |||
the secondary path. The traffic will be forwarded through the | the secondary path. The traffic will be forwarded through the | |||
R1->R2->{R4, R5} path normally, but when a node in the | R1->R2->{R4, R5} path normally, but when a node in the | |||
primary tree fails (say R2) the root node R1 will switch the flow to the | primary tree fails (say R2), the root node R1 will switch the flow to the | |||
backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC a | backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC, | |||
path computation, label downloading and finally forwarding can be done | path computation, label downloading, and finally forwarding can be done | |||
without complex signalling used in the P2MP RSVP-TE or mLDP.</t> | without the complex signalling used in the P2MP RSVP-TE or mLDP.</t> | |||
</section> | ||||
</section> | <section anchor="sect-6.3" numbered="true" toc="default"> | |||
<name>PCECC for the Local Protection of P2MP/MP2MP LSPs</name> | ||||
<section title="PCECC for the Local Protection of the P2MP/MP2MP LSPs" an | <t> | |||
chor="sect-6.3"><t> | ||||
In this section, we describe the local protection service in the PCECC | In this section, we describe the local protection service in the PCECC | |||
network for the P2MP/MP2MP LSP.</t> | network for the P2MP/MP2MP LSP.</t> | |||
<t> | ||||
<t> | ||||
While the PCECC sets up the primary multicast tree, it can also build | While the PCECC sets up the primary multicast tree, it can also build | |||
the backup LSP between the Point of Local Repair (PLR), the protected node an d Merge Points (MPs) (the downstream | the backup LSP between the Point of Local Repair (PLR), protected node, and M erge Points (MPs) (the downstream | |||
nodes of the protected node). In the cases where the amount of | nodes of the protected node). In the cases where the amount of | |||
downstream nodes is huge, this mechanism can avoid unnecessary | downstream nodes is huge, this mechanism can avoid unnecessary | |||
packet duplication on PLR and protect the network from traffic | packet duplication on the PLR and protect the network from traffic | |||
congestion risk.</t> | congestion risks.</t> | |||
<figure anchor="fig_p2mp-loc"> | ||||
<figure title="PCECC for the Local Protection of the P2MP/MP2MP LSPs" anc | <name>PCECC for the Local Protection of P2MP/MP2MP LSPs</name> | |||
hor="fig_p2mp-loc"><artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
+------------+ | +------------+ | |||
| R1 | Root Node | | R1 | Root Node | |||
+------------+ | +------------+ | |||
. | . | |||
. | . | |||
. | . | |||
+------------+ Point of Local Repair/ | +------------+ Point of Local Repair / | |||
| R10 | Switchover Point | | R10 | Switchover Point | |||
+------------+ (Upstream LSR) | +------------+ (Upstream LSR) | |||
/ + | / + | |||
10/ +20 | 10/ +20 | |||
/ + | / + | |||
+----------+ +-----------+ | +----------+ +-----------+ | |||
Protected Node | R20 | | R30 | | Protected Node | R20 | | R30 | | |||
+----------+ +-----------+ | +----------+ +-----------+ | |||
| \ + + | | \ + + | |||
| \ + + | | \ + + | |||
10| 10\ +20 20+ | 10| 10\ +20 20+ | |||
| \ + + | | \ + + | |||
| \ + | | \ + | |||
| + \ + | | + \ + | |||
+-----------+ +-----------+ Merge Point | +-----------+ +-----------+ Merge Point | |||
| R40 | | R50 | (Downstream LSR) | | R40 | | R50 | (Downstream LSR) | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
. . | . . | |||
. . | . . | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
In <xref target="fig_p2mp-loc"/>, when the PCECC setups the primary multicast | In <xref target="fig_p2mp-loc" format="default"/>, when the PCECC sets up the | |||
path | primary multicast path | |||
around the PLR node R10 to protect node R20, which is R10->R20->{R40, | around the PLR node R10 to protect node R20, which is R10->R20->{R40, | |||
R50}, at the same time, it can set up the backup path R10->R30->{R40, | R50}, it can set up the backup path R10->R30->{R40, | |||
R50}. Both the primary forwarding path and secondary bypass | R50} at the same time. Both the primary forwarding path and the secondary by | |||
pass | ||||
forwarding path will be downloaded to each router along the primary | forwarding path will be downloaded to each router along the primary | |||
path and the secondary bypass path. The traffic will be forwarded through | path and the secondary bypass path. The traffic will be forwarded through | |||
the R10->R20->{R40, R50} path normally and when there is a node | the R10->R20->{R40, R50} path normally, and when there is a node | |||
failure for node R20, the PLR node R10 will switch the flow to | failure for node R20, the PLR node R10 will switch the flow to | |||
the backup path, which is R10->R30->{R40, R50}. By using the PCECC, | the backup path, which is R10->R30->{R40, R50}. By using the PCECC, | |||
path computation, label downloading and finally forwarding can be done | path computation, label downloading, and finally forwarding can be done | |||
without complex signalling used in the P2MP RSVP-TE or mLDP.</t> | without the complex signalling used in the P2MP RSVP-TE or mLDP.</t> | |||
</section> | ||||
</section> | </section> | |||
<section anchor="sect-7" numbered="true" toc="default"> | ||||
</section> | <name>PCECC for Traffic Classification</name> | |||
<t>As described in <xref target="RFC8283" format="default"/>, traffic cl | ||||
<section title="PCECC for Traffic Classification" anchor="sect-7"> | assification is an important part of traffic engineering. | |||
<t>As described in <xref target="RFC8283"/>, traffic classification is an imp | ||||
ortant part of traffic engineering. | ||||
It is the process of looking into a packet to determine how it should | It is the process of looking into a packet to determine how it should | |||
be treated while it is forwarded through the network. It applies in | be treated while it is forwarded through the network. It applies in | |||
many scenarios including the following: | many scenarios, including the following: | |||
<list><t>MPLS traffic engineering (where it | </t> | |||
determines what traffic is forwarded into which LSPs),</t> | <ul> | |||
<t>Segment Routing (where it is used to select which set of forwarding | <li> | |||
instructions (SIDs) to add to a packet),</t> | MPLS traffic engineering (where it determines what traffic is | |||
<t>SFC (where it indicates how a packet should be forwarded across | forwarded into which LSPs), | |||
which service function path ).</t></list></t> | </li> | |||
<t>In conjunction with traffic engineering, traffic classification is an | <li> | |||
Segment Routing (where it is used to select which set of | ||||
forwarding instructions (SIDs) to add to a packet), and | ||||
</li> | ||||
<li> | ||||
SFC (where it indicates how a packet should be forwarded across | ||||
which service function path). | ||||
</li> | ||||
</ul> | ||||
<t>In conjunction with traffic engineering, traffic classification is an | ||||
important enabler for load balancing. Traffic classification is closely linke d to the computational | important enabler for load balancing. Traffic classification is closely linke d to the computational | |||
elements of planning for the network functions because it | elements of planning for the network functions because it | |||
determines how traffic is balanced and distributed through the | determines how traffic is balanced and distributed through the | |||
network. Therefore, selecting what traffic classification mechanism should b e | network. Therefore, selecting what traffic classification mechanism should b e | |||
performed by a router is an important part of the work done by a | performed by a router is an important part of the work done by a | |||
PCECC.</t> | PCECC.</t> | |||
<t>The description of traffic flows by the combination of multiple Flow Speci | <!-- [rfced] We note that "Flow Specification" occurs three times in the | |||
fication components and their dissemination as traffic flow specifications (Flow | sentence below. For concision and clarity, may we update the sentence as | |||
Specifications) is described for BGP in <xref target="RFC8955"/>. When a PCECC | follows? | |||
is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is impo | ||||
rtant that the head end of the tunnels understands what traffic to place on each | ||||
tunnel. <xref target="RFC9168"/> specifies a set of extensions to PCEP to suppo | ||||
rt the dissemination of Flow Specification components where the instructions are | ||||
passed from the PCECC to the routers using PCEP.</t> | ||||
<t> | Original: | |||
Along with traffic classification, there are a few more questions that need t | ||||
o be considered after path setup: | ||||
<list style="symbols"><t>how to use it</t> | The description of traffic flows by the combination of multiple Flow | |||
Specification components and their dissemination as traffic flow | ||||
specifications (Flow Specifications) is described for BGP in [RFC8955]. | ||||
<t>Whether it is a virtual link</t> | Perhaps: | |||
<t>Whether to advertise it in the IGP as a virtual link</t> | The description of traffic flows by the combination of multiple Flow | |||
Specification components and their dissemination as traffic Flow | ||||
Specifications is described for BGP in [RFC8955]. | ||||
--> | ||||
<t>What bits of this information to signal to the tail end</t> | <t>The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in <xref target="RFC8955" format="def ault"/>. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what tr affic to place on each tunnel. <xref target="RFC9168" format="default"/> specifi es a set of extensions to PCEP to support the dissemination of Flow Specificatio n components where the instructions are passed from the PCECC to the routers usi ng PCEP.</t> | |||
</list> | <!-- [rfced] For clarity, what does "it" refer to in the bullets below? Is | |||
</t> | it the PCECC? | |||
<t>These are out of the scope of this document.</t> | ||||
</section> | Original (Section 3.7): | |||
<section title="PCECC for SFC" anchor="sect-9" > | Along with traffic classification, there are a few more questions | |||
<t>Service Function Chaining (SFC) is described in <xref target="RFC7665"/>. | that need to be considered after path setup: | |||
It is the process of directing | ||||
* how to use it | ||||
* Whether it is a virtual link | ||||
* Whether to advertise it in the IGP as a virtual link | ||||
* What bits of this information to signal to the tail end | ||||
Perhaps: | ||||
Along with traffic classification, there are a few more questions | ||||
about the PCECC that need to be considered after path setup: | ||||
* how to use it, | ||||
* whether it is a virtual link, | ||||
* whether to advertise it in the IGP as a virtual link, and | ||||
* what bits of this information to signal to the tail end. | ||||
--> | ||||
<t> | ||||
Along with traffic classification, there are a few more considerations after | ||||
path setup: | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>how to use it,</t> | ||||
</li> | ||||
<li> | ||||
<t>whether it is a virtual link,</t> | ||||
</li> | ||||
<li> | ||||
<t>whether to advertise it in the IGP as a virtual link, and</t> | ||||
</li> | ||||
<li> | ||||
<t>what bits of this information to signal to the tail end.</t> | ||||
</li> | ||||
</ul> | ||||
<t>These are out of the scope of this document.</t> | ||||
</section> | ||||
<section anchor="sect-9" numbered="true" toc="default"> | ||||
<name>PCECC for SFC</name> | ||||
<t>Service Function Chaining (SFC) is described in <xref target="RFC7665 | ||||
" format="default"/>. It is the process of directing | ||||
traffic in a network such that it passes through specific hardware | traffic in a network such that it passes through specific hardware | |||
devices or virtual machines (known as service function nodes) that | devices or virtual machines (known as service function nodes) that | |||
can perform particular desired functions on the traffic. The set of | can perform particular desired functions on the traffic. The set of | |||
functions to be performed and the order in which they are to be | functions to be performed and the order in which they are to be | |||
performed is known as a service function chain. The chain is | performed is known as a service function chain. The chain is | |||
enhanced with the locations at which the service functions are to be | enhanced with the locations at which the service functions are to be | |||
performed to derive a Service Function Path (SFP). Each packet is | performed to derive a Service Function Path (SFP). Each packet is | |||
marked as belonging to a specific SFP, and that marking lets each | marked as belonging to a specific SFP, and that marking lets each | |||
successive service function node know which functions to perform and | successive service function node know which functions to perform and | |||
to which service function node to send the packet next. To operate an SFC net work, the service function nodes must be | to which service function node to send the packet next. To operate an SFC net work, the service function nodes must be | |||
configured to understand the packet markings, and the edge nodes must | configured to understand the packet markings, and the edge nodes must | |||
be told how to mark packets entering the network. Additionally, it | be told how to mark packets entering the network. Additionally, it | |||
may be necessary to establish tunnels between service function nodes | may be necessary to establish tunnels between service function nodes | |||
to carry the traffic. Planning an SFC network requires load balancing between service | to carry the traffic. Planning an SFC network requires load balancing between service | |||
function nodes and traffic engineering across the network that | function nodes and traffic engineering across the network that | |||
connects them. As per <xref target="RFC8283"/>, these are operations that ca n be performed by a | connects them. As per <xref target="RFC8283" format="default"/>, these are o perations that can be performed by a | |||
PCE-based controller, and that controller can use PCEP to program the | PCE-based controller, and that controller can use PCEP to program the | |||
network and install the service function chains and any required | network and install the service function chains and any required | |||
tunnels.</t> | tunnels.</t> | |||
<t>A possible mechanism could add support for SFC-based central control instr | <t>A possible mechanism could add support for SFC-based central control | |||
uctions. PCECC will be able to instruct each SFF along the SFP. | instructions. The PCECC will be able to instruct each Service Function Forwarder | |||
<list style="symbols"> | (SFF) along the SFP.</t> | |||
<t>Service Path Identifier (SPI): Uniquely identifies an SFP. </t> | ||||
<t>Service Index (SI): Provides location within the SFP.</t> | ||||
<t>SFC Proxy handling</t> | ||||
</list> | ||||
</t> | ||||
<t>PCECC can play the role of setting the traffic classification rules (as pe | ||||
r <xref target="sect-7"/>) at the classifier to impose the Network Service Heade | ||||
r (NSH) <xref target="RFC8300"/> as well as downloading the forwarding instructi | ||||
ons to each SFF along the way so that they could process the NSH and forward acc | ||||
ordingly. Including instructions for the service classifier that handles the con | ||||
text header, metadata etc. This metadata/context is shared amongst SFs and class | ||||
ifiers, between SFs, and between external systems (such as PCECC) and SFs. As de | ||||
scribed in <xref target="RFC7665"/>, the SFC encapsulation enables the sharing o | ||||
f metadata/context information along the SFP.</t> | ||||
<t>It is also possible to support SFC with SR in conjunction with or without | <!-- [rfced] Would you like to add any additional text or a definition to "SFC | |||
NSH such as <xref target="RFC9491"/> and <xref target="I-D.ietf-spring-sr-servic | Proxy handling" below, for consistency with the other bulleted items in this lis | |||
e-programming"/>. PCECC technique can also be used for service function-related | t? | |||
segments and SR service policies. </t> | ||||
</section> | Original: | |||
<section title="PCECC for Native IP" anchor="sect-10" > | ||||
<t><xref target="RFC8735"/> describes the scenarios and simulation results f | ||||
or | ||||
the "Centrally Control Dynamic Routing (CCDR)" solution, which | ||||
integrates the advantage of using distributed protocols (IGP/BGP) and the pow | ||||
er of a centralized control technology (PCE/SDN), providing traffic engineering | ||||
for native IP networks. <xref target="RFC8821"/> defines the framework for CCDR | ||||
traffic engineering | ||||
within a Native IP network, using multiple BGP sessions and a PCE as the cent | ||||
ralized controller. It requires the PCECC to send the instructions to the | ||||
PCCs, to build multiple BGP sessions, distribute different prefixes | ||||
on the established BGP sessions and assign the different paths to the | ||||
BGP next hops. PCEP protocol is used to transfer | ||||
the key parameters between PCE and the underlying network | ||||
devices (PCC) using the PCECC technique. The central control instructions fro | ||||
m PCECC to PCC will identify which prefix should be advertised on which BGP sess | ||||
ion. There are PCEP extensions defined in <xref target="I-D.ietf-pce-pcep-extens | ||||
ion-native-ip"/> for it.</t> | ||||
<figure title="PCECC for Native IP" anchor="fig_native_ip"><artwork> | A possible mechanism could add support for SFC-based central control | |||
<![CDATA[ | instructions. PCECC will be able to instruct each SFF along the SFP. | |||
+------+ | ||||
+----------+ PCECC+-------+ | ||||
| +------+ | | ||||
| | | ||||
PCEP | BGP Session 1(lo11/lo21)| PCEP | ||||
+-------------------------+ | ||||
| | | ||||
| BGP Session 2(lo12/lo22)| | ||||
+-------------------------+ | ||||
PF12 | | PF22 | ||||
PF11 | | PF21 | ||||
+---+ +-----+-----+ +-----+-----+ +---+ | ||||
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2| | ||||
+---+ | R1 +-------------+ R2 | +---+ | ||||
+-----------+ +-----------+ | ||||
]]> | * Service Path Identifier (SPI): Uniquely identifies an SFP. | |||
</artwork></figure> | ||||
<t>In the case, as shown in <xref target="fig_native_ip"/>, PCECC will instruct | * Service Index (SI): Provides location within the SFP. | |||
both R1 and R2 via PCEP how to form BGP sessions with each other and which IP pr | ||||
efixes | ||||
need to be advertised via which BGP session.</t> | ||||
</section> | * SFC Proxy handling | |||
--> | ||||
<section title="PCECC for BIER" anchor="sect-11"> | <ul> | |||
<t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> defines an | <li>Service Path Identifier (SPI): Uniquely identifies an SFP.</li> | |||
architecture where all intended multicast receivers are encoded as a | <li>Service Index (SI): Provides location within the SFP.</li> | |||
bitmask in the multicast packet header within different | <li>SFC Proxy handling</li> | |||
encapsulations. A router that | </ul> | |||
receives such a packet will forward that packet based on the bit | <t>The PCECC can play the role of setting the traffic classification rul | |||
position in the packet header towards the receiver(s) following a | es (as per <xref target="sect-7" format="default"/>) at the classifier to impose | |||
precomputed tree for each of the bits in the packet. Each receiver | the Network Service Header (NSH) <xref target="RFC8300" format="default"/>. It | |||
is represented by a unique bit in the bitmask.</t> | can also download the forwarding instructions to each SFF along the way so that | |||
they could process the NSH and forward accordingly. This includes instructions f | ||||
or the service classifier that handles the context header, metadata, etc. This m | ||||
etadata/context is shared amongst SFs and classifiers, between SFs, and between | ||||
external systems (such as a PCECC) and SFs. As described in <xref target="RFC766 | ||||
5" format="default"/>, the SFC encapsulation enables the sharing of metadata/con | ||||
text information along the SFP.</t> | ||||
<t>It is also possible to support SFC with SR in conjunction with or wit | ||||
hout an NSH such as described in <xref target="RFC9491" format="default"/> and < | ||||
xref target="I-D.ietf-spring-sr-service-programming" format="default"/>. PCECC t | ||||
echniques can also be used for service-function-related segments and SR service | ||||
policies. </t> | ||||
</section> | ||||
<section anchor="sect-10" numbered="true" toc="default"> | ||||
<name>PCECC for Native IP</name> | ||||
<t>BIER-TE <xref target="RFC9262"/> shares architecture and | <t> | |||
packet formats with BIER. BIER-TE forwards | <xref target="RFC8735" format="default"/> describes the scenarios | |||
and replicates packets based on a BitString in the packet header, but | and simulation results for the "Centralized Control Dynamic Routing | |||
every BitPosition of the BitString of a BIER-TE packet indicates one | (CCDR)" solution, which integrates the advantage of using | |||
or more adjacencies. BIER-TE paths can be derived from a PCE and used at the | distributed protocols (IGP/BGP) and the power of a centralized | |||
ingress ( a possible mechanism is described in <xref target="I-D.chen-pce-bier"/ | control technology (PCE/SDN), providing traffic engineering for | |||
>).</t> | native IP networks. <xref target="RFC8821" format="default"/> | |||
defines the framework for CCDR traffic engineering within a native | ||||
IP network, using multiple BGP sessions and a PCE as the centralized | ||||
controller. It requires the PCECC to send the instructions to the | ||||
PCCs to build multiple BGP sessions, distribute different prefixes | ||||
on the established BGP sessions, and assign the different paths to | ||||
the BGP next hops. The PCEP protocol is used to transfer the key | ||||
parameters between the PCE and the underlying network devices (PCC) | ||||
using the PCECC technique. The central control instructions from | ||||
the PCECC to PCC will identify which prefix should be advertised on | ||||
which BGP session. There are PCEP extensions defined in <xref | ||||
target="I-D.ietf-pce-pcep-extension-native-ip" format="default"/> | ||||
for it. | ||||
</t> | ||||
<figure anchor="fig_native_ip"> | ||||
<name>PCECC for Native IP</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+------+ | ||||
+----------+ PCECC+-------+ | ||||
| +------+ | | ||||
| | | ||||
PCEP | BGP Session 1(lo11/lo21)| PCEP | ||||
+-------------------------+ | ||||
| | | ||||
| BGP Session 2(lo12/lo22)| | ||||
+-------------------------+ | ||||
PF12 | | PF22 | ||||
PF11 | | PF21 | ||||
+---+ +-----+-----+ +-----+-----+ +---+ | ||||
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2| | ||||
+---+ | R1 +-------------+ R2 | +---+ | ||||
+-----------+ +-----------+ | ||||
]]></artwork> | ||||
</figure> | ||||
<t>In the case as shown in <xref target="fig_native_ip" | ||||
format="default"/>, the PCECC will instruct both R1 and R2 how to form B | ||||
GP | ||||
sessions with each other via PCEP and which IP prefixes need to be | ||||
advertised via which BGP session.</t> | ||||
</section> | ||||
<t>PCECC mechanism could be used for the allocation of bits for the BIER rout | <section anchor="sect-11" numbered="true" toc="default"> | |||
er for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers | <name>PCECC for BIER</name> | |||
can use PCEP to instruct the BIER-capable routers on the meaning of the b | <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279" | |||
its as well as other fields needed for BIER encapsulation. The PCECC could be us | format="default"/> defines an architecture where all intended | |||
ed to program the BIER router with various parameters used in the BIER encapsula | multicast receivers are encoded as a BitMask in the multicast packet | |||
tion such as BIER subdomain-ID, BFR-ID, BIER Encapsulation etc. for both node an | header within different encapsulations. A router that receives such a | |||
d adjacency.</t> | packet will forward that packet based on the bit position in the | |||
<t> A possible way for the PCECC usage and PCEP extension is described in <xref | packet header towards the receiver(s) following a precomputed tree for | |||
target="I-D.chen-pce-pcep-extension-pce-controller-bier"/>.</t> | each of the bits in the packet. Each receiver is represented by a | |||
unique bit in the BitMask.</t> | ||||
<t>BIER-TE <xref target="RFC9262" format="default"/> shares | ||||
architecture and packet formats with BIER. BIER-TE forwards and | ||||
replicates packets based on a BitString in the packet header, but | ||||
every BitPosition of the BitString of a BIER-TE packet indicates one | ||||
or more adjacencies. BIER-TE paths can be derived from a PCE and used | ||||
at the ingress (a possible mechanism is described in <xref | ||||
target="I-D.ietf-pce-bier-te" format="default"/>).</t> | ||||
</section> | <!-- [rfced] FYI - Since "BIER encapsulation" appeared twice in the sentence | |||
below, we removed the second instance and updated for conciseness. Please | ||||
review and let us know of any objections. | ||||
</section> | Original: | |||
<section title="IANA Considerations" anchor="sect-12"><t> | The PCECC could be used to program the BIER router with various parameters | |||
This document does not require any action from IANA.</t> | used in the BIER encapsulation such as BIER subdomain-ID, BFR-ID, BIER | |||
Encapsulation etc. for both node and adjacency. | ||||
</section> | Current: | |||
<section title="Security Considerations" anchor="sect-13"> | The PCECC could be used to program the BIER router with various parameters | |||
<t><xref target="RFC8283"/> describes how the security considerations for a | used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.) | |||
PCE-based controller are a little different from those for any other PCE system. | for both node and adjacency. | |||
PCECC operations rely heavily on the use and security of PCEP, so | --> | |||
due consideration should be given to the security features discussed in | ||||
<xref target="RFC5440"/> and the additional mechanisms described in <xref tar | ||||
get="RFC8253"/>. It further lists the vulnerability of a | ||||
central controller architecture, such as a central point of failure, | ||||
denial of service, and a focus on interception and modification of | ||||
messages sent to individual Network Elements (NEs).</t> | ||||
<t>As per <xref target="RFC9050"/>, the use of | ||||
Transport Layer Security (TLS) in PCEP is recommended, as it provides support | ||||
for | ||||
peer authentication, message encryption, and integrity. It further | ||||
provides mechanisms for associating peer identities with different | ||||
levels of access and/or authoritativeness via an attribute in X.509 | ||||
certificates or a local policy with a specific accept-list of X.509 | ||||
certificates. This can be used to check the authority for the PCECC | ||||
operations.</t> | ||||
<t>It is expected that each new document that is produced for a specific | ||||
use case will also include considerations of the security impacts of | ||||
the use of a PCE-based central controller on the network type and | ||||
services being managed.</t> | ||||
</section> | <t>The PCECC mechanism could be used for the allocation of bits for the | |||
BIER router for BIER as well as for the adjacencies for | ||||
BIER-TE. PCECC-based controllers can use PCEP to instruct the | ||||
BIER-capable routers on the meaning of the bits as well as other | ||||
fields needed for BIER encapsulation. The PCECC could be used to | ||||
program the BIER router with various parameters used in the BIER | ||||
encapsulation (such as BIER sub-domain-id, BFR-id, | ||||
etc.) for both node and adjacency.</t> | ||||
<section title="Acknowledgments" anchor="sect-14"><t> | <t>A possible way to use the PCECC and PCEP extension is described in | |||
Thanks to Adrian Farrel, Aijun Wang, Robert Tao, | <xref target="I-D.chen-pce-pcep-extension-pce-controller-bier" | |||
Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin | format="default"/>.</t> | |||
and Evgeniy Brodskiy for their useful comments and suggestions.</t> | </section> | |||
<t>Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to | ||||
Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review.</t> | ||||
<t>Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guic | ||||
hard for being the responsible AD.</t> | ||||
<t>Thanks to Roman Danyliw for the IESG review comments.</t> | ||||
</section> | </section> | |||
</middle> | <section anchor="sect-12" numbered="true" toc="default"> | |||
<name>IANA Considerations</name> | ||||
<t>This document has no IANA actions.</t> | ||||
</section> | ||||
<back> | <section anchor="sect-13" numbered="true" toc="default"> | |||
<name>Security Considerations</name> | ||||
<t><xref target="RFC8283" format="default"/> describes how the security | ||||
considerations for a PCE-based controller are a little different from | ||||
those for any other PCE system. PCECC operations rely heavily on the | ||||
use and security of PCEP, so due consideration should be given to the | ||||
security features discussed in <xref target="RFC5440" format="default"/> | ||||
and the additional mechanisms described in <xref target="RFC8253" | ||||
format="default"/>. It further lists the vulnerability of a central | ||||
controller architecture, such as a central point of failure, denial of | ||||
service, and a focus on interception and modification of messages sent | ||||
to individual Network Elements (NEs).</t> | ||||
<t>As per <xref target="RFC9050" format="default"/>, the use of | ||||
Transport Layer Security (TLS) in PCEP is recommended, as it provides | ||||
support for peer authentication, message encryption, and integrity. It | ||||
further provides mechanisms for associating peer identities with | ||||
different levels of access and/or authoritativeness via an attribute in | ||||
X.509 certificates or a local policy with a specific accept-list of | ||||
X.509 certificates. This can be used to check the authority for the | ||||
PCECC operations.</t> | ||||
<t>It is expected that each new document that is produced for a specific | ||||
use case will also include considerations of the security impacts of the | ||||
use of a PCE-based central controller on the network type and services | ||||
being managed.</t> | ||||
</section> | ||||
<references title="Normative References"> | </middle> | |||
<!--&RFC2119;--> | ||||
&RFC5440; | ||||
<!--&RFC8174;--> | ||||
&RFC7665; | ||||
&RFC8231; | ||||
&RFC8281; | ||||
&RFC8283; | ||||
&RFC8253; | ||||
&RFC8402; | <back> | |||
</references> | <displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-sr" to= | |||
<references title="Informative References"> | "PCECC-SR"/> | |||
&RFC1195; | <displayreference target="I-D.ietf-pce-controlled-id-space" to="PCE-ID"/> | |||
<displayreference target="I-D.ietf-pce-stateful-interdomain" to="PCE-INTERDO | ||||
MAIN"/> | ||||
<displayreference target="I-D.cbrt-pce-stateful-local-protection" to="PCE-PR | ||||
OTECTION"/> | ||||
<displayreference target="I-D.ietf-mpls-seamless-mpls" to="MPLS-SEAMLESS"/> | ||||
<displayreference target="I-D.ietf-pce-bier-te" to="PCEP-BIER"/> | ||||
<displayreference target="I-D.ietf-spring-sr-service-programming" to="SR-SER | ||||
VICE"/> | ||||
<displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-P | ||||
OLICY"/> | ||||
<displayreference target="I-D.chen-pce-pcep-extension-pce-controller-bier" t | ||||
o="PCECC-BIER"/> | ||||
<displayreference target="I-D.ietf-pce-pcep-extension-native-ip" to="PCEP-NA | ||||
TIVE"/> | ||||
<displayreference target="I-D.ietf-pce-pcep-extension-pce-controller-srv6" t | ||||
o="PCECC-SRv6"/> | ||||
&RFC2328; | <references> | |||
&RFC5340; | <name>References</name> | |||
&RFC3209; | <references> | |||
&RFC5036; | <name>Normative References</name> | |||
<!-- [auth] &RFC2119;--> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54 | ||||
40.xml"/> | ||||
<!-- [auth] &RFC8174;--> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76 | ||||
65.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
231.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
281.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
283.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
253.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
402.xml"/> | ||||
</references> | ||||
<references> | ||||
<name>Informative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1 | ||||
195.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
328.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
340.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 | ||||
209.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
036.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 | ||||
985.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | ||||
206.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | ||||
364.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | ||||
456.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | ||||
655.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
150.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
151.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
541.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
376.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
025.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
399.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
432.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
491.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
279.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
300.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
355.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
408.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
664.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
735.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
751.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
754.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
821.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
955.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
986.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
050.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
168.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
256.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
012.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
087.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
262.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
491.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
522.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
552.xml"/> | ||||
&RFC3985; | <!-- [I-D.ietf-pce-pcep-extension-pce-controller-sr] IESG state: I-D Exists as o | |||
&RFC4206; | f 06/06/24--> | |||
&RFC4364; | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | |||
&RFC4456; | e-pcep-extension-pce-controller-sr.xml"/> | |||
&RFC4655; | ||||
&RFC5150; | ||||
&RFC5151; | ||||
&RFC5541; | ||||
&RFC5376; | ||||
&RFC7025; | ||||
&RFC7399; | ||||
&RFC7432; | ||||
&RFC7491; | ||||
&RFC8279; | <!-- [I-D.li-pce-controlled-id-space] IESG state: Replaced by draft-ietf-pce-con | |||
trolled-id-space as of 06/06/24. --> | ||||
<reference anchor="I-D.ietf-pce-controlled-id-space" target="https://datatracker | ||||
.ietf.org/doc/html/draft-ietf-pce-controlled-id-space-00"> | ||||
<front> | ||||
<title> | ||||
Path Computation Element Communication Protocol (PCEP) extension to advertise th | ||||
e PCE Controlled Identifier Space | ||||
</title> | ||||
<author fullname="Cheng Li" initials="C." surname="Li"> | ||||
<organization>Huawei Technologies</organization> | ||||
</author> | ||||
<author fullname="Hang Shi" initials="H." surname="Shi" role="editor"> | ||||
<organization>Huawei Technologies</organization> | ||||
</author> | ||||
<author fullname="Aijun Wang" initials="A." surname="Wang"> | ||||
<organization>China Telecom</organization> | ||||
</author> | ||||
<author fullname="Weiqiang Cheng" initials="W." surname="Cheng"> | ||||
<organization>China Mobile</organization> | ||||
</author> | ||||
<author fullname="Chao Zhou" initials="C." surname="Zhou"> | ||||
<organization>HPE</organization> | ||||
</author> | ||||
<date day="4" month="June" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-controlled-id-space-00"/ | ||||
> | ||||
</reference> | ||||
&RFC8300; | <!-- [I-D.ietf-pce-stateful-interdomain] IESG state: Expired as of 06/06/24--> | |||
&RFC8355; | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | |||
&RFC8408; | e-stateful-interdomain.xml"/> | |||
&RFC8664; | <!-- [I-D.cbrt-pce-stateful-local-protection] IESG state: Expired as of 06/06/24 | |||
&RFC8735; | --> | |||
&RFC8751; | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-cbrt-pc | |||
&RFC8754; | e-stateful-local-protection.xml"/> | |||
&RFC8821; | ||||
&RFC8955; | ||||
&RFC8986; | ||||
&RFC9050; | ||||
&RFC9168; | ||||
&RFC9256; | ||||
&RFC9012; | ||||
&RFC9087; | ||||
&RFC9262; | ||||
&RFC9491; | ||||
&RFC9522; | ||||
&RFC9552; | ||||
&I-D.ietf-pce-pcep-extension-pce-controller-sr; | <!-- [I-D.ietf-pce-segment-routing-ipv6] IESG state: RFC Ed Queue as | |||
&I-D.li-pce-controlled-id-space; | of 06/06/24. Published as [RFC9603]. Updated reference and cite tags | |||
&I-D.ietf-pce-stateful-interdomain; | accordingly.--> | |||
&I-D.cbrt-pce-stateful-local-protection; | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
&I-D.ietf-pce-segment-routing-ipv6; | 603.xml"/> | |||
&I-D.ietf-mpls-seamless-mpls; | ||||
&I-D.chen-pce-bier; | <!-- [I-D.ietf-mpls-seamless-mpls] IESG state: Expired (IESG: Dead) as of 06/06/ | |||
&I-D.ietf-spring-sr-service-programming; | 24. Added missing editor role to XML.--> | |||
<reference anchor="I-D.ietf-mpls-seamless-mpls" target="https://datatracker.ietf | ||||
.org/doc/html/draft-ietf-mpls-seamless-mpls-07"> | ||||
<front> | ||||
<title>Seamless MPLS Architecture</title> | ||||
<author fullname="Nicolai Leymann" initials="N." surname="Leymann" role="editor" | ||||
> | ||||
<organization>Deutsche Telekom AG</organization> | ||||
</author> | ||||
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> | ||||
<organization>Orange</organization> | ||||
</author> | ||||
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author fullname="Maciek Konstantynowicz" initials="M." surname="Konstantynowicz | ||||
" role="editor"> | ||||
<organization>Cisco Systems</organization> | ||||
</author> | ||||
<author fullname="Dirk Steinberg" initials="D." surname="Steinberg"> | ||||
<organization>Steinberg Consulting</organization> | ||||
</author> | ||||
<date day="28" month="June" year="2014"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-seamless-mpls-07"/> | ||||
</reference> | ||||
&I-D.ietf-pce-segment-routing-policy-cp; | <!-- [I-D.chen-pce-bier] IESG state: Replaced by draft-ietf-pce-bier-te as of 06 | |||
/06/24 | ||||
Updated from "draft-chen-pce-bier" to "draft-ietf-pce-bier-te".--> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | ||||
e-bier-te-00.xml"/> | ||||
&I-D.ietf-pce-binding-label-sid; | <!-- [I-D.ietf-spring-sr-service-programming] IESG state: I-D Exists as of 06/06 | |||
&I-D.chen-pce-pcep-extension-pce-controller-bier; | /24--> | |||
&I-D.ietf-pce-pcep-extension-native-ip; | <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datat | |||
&I-D.dhody-pce-pcep-extension-pce-controller-srv6; | racker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-10"> | |||
<front> | ||||
<title>Service Programming with Segment Routing</title> | ||||
<author fullname="Francois Clad" initials="F." surname="Clad" role="editor"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author fullname="Xiaohu Xu" initials="X." surname="Xu" role="editor"> | ||||
<organization>China Mobile</organization> | ||||
</author> | ||||
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
</author> | ||||
<author fullname="Daniel Bernier" initials="D." surname="Bernier"> | ||||
<organization>Bell Canada</organization> | ||||
</author> | ||||
<author fullname="Cheng Li" initials="C." surname="Li"> | ||||
<organization>Huawei</organization> | ||||
</author> | ||||
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> | ||||
<organization>Orange</organization> | ||||
</author> | ||||
<author fullname="Shaowen Ma" initials="S." surname="Ma"> | ||||
<organization>Mellanox</organization> | ||||
</author> | ||||
<author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli"> | ||||
<organization>AT&T</organization> | ||||
</author> | ||||
<author fullname="Wim Henderickx" initials="W." surname="Henderickx"> | ||||
<organization>Nokia</organization> | ||||
</author> | ||||
<author fullname="Stefano Salsano" initials="S." surname="Salsano"> | ||||
<organization>Universita di Roma "Tor Vergata"</organization> | ||||
</author> | ||||
<date day="23" month="August" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programmin | ||||
g-10"/> | ||||
</reference> | ||||
<reference anchor="MAP-REDUCE" target="http://leeky.me/publications/m | <!-- [I-D.ietf-pce-segment-routing-policy-cp] IESG state: I-D Exists as of 06/06 | |||
apreduce_p2p.pdf"> | /24--> | |||
<front> | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | |||
e-segment-routing-policy-cp.xml"/> | ||||
<!-- [I-D.ietf-pce-binding-label-sid] Published as RFC 9604. Updated | ||||
reference and citation tags for [PCE-BINDING-LABEL-SID] to [RFC9604]. --> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
604.xml"/> | ||||
<!-- [I-D.chen-pce-pcep-extension-pce-controller-bier] IESG state: Expired as of | ||||
06/06/24--> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-chen-pc | ||||
e-pcep-extension-pce-controller-bier.xml"/> | ||||
<!-- [I-D.ietf-pce-pcep-extension-native-ip] IESG state: Publication Requested a | ||||
s of 06/06/24--> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | ||||
e-pcep-extension-native-ip.xml"/> | ||||
<!-- [I-D.dhody-pce-pcep-extension-pce-controller-srv6] IESG state: | ||||
Replaced by draft-ietf-pce-pcep-extension-pce-controller-srv6 as of | ||||
06/06/24. Updated URL and cite tag to use most current I-D. --> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc | ||||
e-pcep-extension-pce-controller-srv6.xml"/> | ||||
<reference anchor="MAP-REDUCE" target="https://leeky.me/publications/map | ||||
reduce_p2p.pdf"> | ||||
<front> | ||||
<title>Parallel Processing Framework on a P2P System Using Map and R educe Primitives</title> | <title>Parallel Processing Framework on a P2P System Using Map and R educe Primitives</title> | |||
<author initials="K" surname="Lee" fullname="Kyungyong Lee"> | <author initials="K" surname="Lee" fullname="Kyungyong Lee"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="T" surname="Choi" fullname="Tae Woong Choi"> | <author initials="T" surname="Choi" fullname="Tae Woong Choi"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="A" surname="Ganguly" fullname="Arijit Ganguly"> | <author initials="A" surname="Ganguly" fullname="Arijit Ganguly"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="D" surname="Wolinsky" fullname="David I. Wolinsky" > | <author initials="D" surname="Wolinsky" fullname="David I. Wolinsky" > | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="P" surname="Boykin" fullname="P.Oscar Boykin"> | <author initials="P" surname="Boykin" fullname="P.Oscar Boykin"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="R" surname="Figueiredo" fullname="Renato Figueired o"> | <author initials="R" surname="Figueiredo" fullname="Renato Figueired o"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<date month="may" year="2011" /> | <date month="May" year="2011"/> | |||
</front> | </front> | |||
<seriesInfo name="" value="" /> | <seriesInfo name="DOI" value="10.1109/IPDPS.2011.315"/> | |||
</reference> | </reference> | |||
<reference anchor="MPLS-DC" target="https://www.slideshare.net/DmitryAfana | ||||
siev1/yandex-nag201320131031"> | <reference anchor="MPLS-DC" target="https://www.slideshare.net/DmitryAfa | |||
<front> | nasiev1/yandex-nag201320131031"> | |||
<front> | ||||
<title>MPLS in DC and inter-DC | <title>MPLS in DC and inter-DC | |||
networks: the unified forwarding mechanism for network | networks: the unified forwarding mechanism for network | |||
programmability at scale</title> | programmability at scale</title> | |||
<author initials="D" surname="Afanasiev" fullname="Dimitry Afanasiev "> | <author initials="D" surname="Afanasiev" fullname="Dimitry Afanasiev "> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<author initials="D" surname="Ginsburg" fullname="Daniel Ginsburg"> | <author initials="D" surname="Ginsburg" fullname="Daniel Ginsburg"> | |||
<organization /> | <organization/> | |||
</author> | </author> | |||
<date month="march" year="2014" /> | <date month="March" year="2014"/> | |||
</front> | </front> | |||
<seriesInfo name="" value="" /> | </reference> | |||
</reference> | ||||
</references> | </references> | |||
<section title="Other Use Cases of PCECC" anchor="sect-15"> | </references> | |||
<t>This section lists some more use cases of PCECC that were proposed by operato | <section anchor="sect-15" numbered="true" toc="default"> | |||
rs and discussed within the working group, but are not in active development at | <name>Other Use Cases of the PCECC</name> | |||
the time of publication. They are listed here for future consideration.</t> | <t>This section lists some more use cases of the PCECC that were proposed | |||
<section title="PCECC for Network Migration" anchor="sect-15.1"><t> | by operators and discussed within the working group but are not in active develo | |||
pment at the time of publication. They are listed here for future consideration. | ||||
</t> | ||||
<section anchor="sect-15.1" numbered="true" toc="default"> | ||||
<name>PCECC for Network Migration</name> | ||||
<t> | ||||
One of the main advantages of the PCECC solution is its backward | One of the main advantages of the PCECC solution is its backward | |||
compatibility. The PCE server can function as a | compatibility. The PCE server can function as a | |||
proxy node of the MPLS network for all the new nodes that no longer support | proxy node of the MPLS network for all the new nodes that no longer support | |||
the signalling protocols.</t> | the signalling protocols.</t> | |||
<t> | <!-- [rfced] Should "signalling" be moved before "protocols" in the | |||
sentence below? | ||||
Original: | ||||
During the migration, the legacy nodes still need | ||||
to use the existing MPLS protocols signalling such as LDP and RSVP- | ||||
TE... | ||||
Perhaps: | ||||
During the migration, the legacy nodes still need | ||||
to use the existing MPLS signalling protocols such as LDP and RSVP- | ||||
TE... | ||||
--> | ||||
<t> | ||||
As illustrated in the following example, the current network | As illustrated in the following example, the current network | |||
could migrate to a total PCECC-controlled network gradually by | could migrate to a total PCECC-controlled network gradually by | |||
replacing the legacy nodes. During the migration, the legacy nodes | replacing the legacy nodes. During the migration, the legacy nodes | |||
still need to use the existing MPLS protocols signalling such as LDP and | still need to use the existing MPLS protocols signalling such as LDP and | |||
RSVP-TE, and the new nodes will set up their portion of the forwarding path | RSVP-TE, and the new nodes will set up their portion of the forwarding path | |||
through PCECC directly. With the PCECC function as the proxy of | through the PCECC directly. With the PCECC function as the proxy of | |||
these new nodes, MPLS signalling can populate through the network for both: o | these new nodes, MPLS signalling can populate through the network for both ol | |||
ld and new nodes.</t> | d and new nodes.</t> | |||
<t> | ||||
<t> | ||||
The example described in this section is based on network configurations | The example described in this section is based on network configurations | |||
illustrated using <xref target="fig_mig"/>:</t> | illustrated in <xref target="fig_mig" format="default"/>:</t> | |||
<figure anchor="fig_mig"> | ||||
<figure title="PCECC Initiated LSP Setup In the Network Migration" anchor="fig | <name>PCECC-Initiated LSP Setup in the Network Migration</name> | |||
_mig"><artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| PCE DOMAIN | | | PCE DOMAIN | | |||
| +-----------------------------------------------------+ | | | +-----------------------------------------------------+ | | |||
| | PCECC | | | | | PCECC | | | |||
| +-----------------------------------------------------+ | | | +-----------------------------------------------------+ | | |||
| ^ ^ ^ ^ | | | ^ ^ ^ ^ | | |||
| | PCEP | | PCEP | | | | | PCEP | | PCEP | | | |||
| V V V V | | | V V V V | | |||
| +--------+ +--------+ +--------+ +--------+ +--------+ | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | |||
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | |||
skipping to change at line 1597 ¶ | skipping to change at line 2192 ¶ | |||
| | PCEP | | PCEP | | | | | PCEP | | PCEP | | | |||
| V V V V | | | V V V V | | |||
| +--------+ +--------+ +--------+ +--------+ +--------+ | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | |||
| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | | |||
| | |...| |...| |...| |...| | | | | | |...| |...| |...| |...| | | | |||
| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | | | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | | |||
| | Node | | Node | |Enabled | |Enabled | | Enabled| | | | | Node | | Node | |Enabled | |Enabled | | Enabled| | | |||
| +--------+ +--------+ +--------+ +--------+ +--------+ | | | +--------+ +--------+ +--------+ +--------+ +--------+ | | |||
| | | | | | |||
+------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | ||||
In this example, there are five nodes for the TE LSP from the head end | ||||
(Node1) to the tail end (Node5). Where Node4 and Node5 are centrally | ||||
controlled and other nodes are legacy nodes.</t> | ||||
<t><list style="symbols"><t>Node1 sends a path request message for the setup o | ||||
f LSP | ||||
with the destination as Node5.</t> | ||||
<t>PCECC sends to Node1 a reply message for LSP setup with the path: | ||||
(Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5.</t> | ||||
<t>Node1, Node2, and Node3 will set up the LSP to Node5 using the local | ||||
labels as usual. Node 3 with the help of PCECC could proxy the signalling.< | ||||
/t> | ||||
<t>Then the PCECC will program the out-segment of Node3, the in-segment/ | <t>In this example, there are five nodes for the TE LSP from the head | |||
out-segment of Node4, and the in-segment for Node5.</t> | end (Node1) to the tail end (Node5), where Node4 and Node5 are | |||
centrally controlled and other nodes are legacy nodes.</t> | ||||
</list> | <ul spacing="normal"> | |||
</t> | <li> | |||
Node1 sends a path request message for the setup of the LSP | ||||
with the destination as Node5. | ||||
</li> | ||||
<li> | ||||
The PCECC sends a reply message to Node1 for LSP setup with the path | ||||
: | ||||
(Node1, if1), (Node2, if2), (Node3, if3), (Node4, if4), Node5. | ||||
</li> | ||||
<li> | ||||
Node1, Node2, and Node3 will set up the LSP to Node5 using the local | ||||
labels as usual. With the help of the PCECC, Node 3 could proxy the s | ||||
ignalling. | ||||
</li> | ||||
<li> | ||||
Then, the PCECC will program the out-segment of Node3, the | ||||
in-segment/out-segment of Node4, and the in-segment for Node5. | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</section> | <section anchor="sect-15.2" numbered="true" toc="default"> | |||
<name>PCECC for L3VPN and PWE3</name> | ||||
<section title="PCECC for L3VPN and PWE3" anchor="sect-15.2"> | <t>As described in <xref target="RFC8283" format="default"/>, various | |||
<t>As described in <xref target="RFC8283"/>, various network services may be | network services may be offered over a network. These include | |||
offered over a network. These | protection services (including Virtual Private Network (VPN) services | |||
include protection services (including | such as Layer 3 VPNs <xref target="RFC4364" format="default"/> or | |||
Virtual Private Network (VPN) services (such as Layer 3 VPNs | Ethernet VPNs <xref target="RFC7432" format="default"/>) or | |||
<xref target="RFC4364"/> or Ethernet VPNs <xref target="RFC7432"/>); or Pseud | pseudowires <xref target="RFC3985" format="default"/>. Delivering | |||
owires <xref target="RFC3985"/>. | services over a network in an optimal way requires coordination in the | |||
Delivering services over a network in an optimal way requires | way where network resources are allocated to support the services. A | |||
coordination in the way where network resources are allocated to | PCE-based central controller can consider the whole network and all | |||
support the services. A PCE-based central controller can consider | components of a service at once when planning how to deliver the | |||
the whole network and all components of a service at once when | service. It can then use PCEP to manage the network resources and to | |||
planning how to deliver the service. It can then use PCEP to manage | install the necessary associations between those resources.</t> | |||
the network resources and to install the necessary associations | <!-- [auth] <t> | |||
between those resources.</t> | ||||
<!--<t> | ||||
The existing services using MPLS LSP tunnels based on MPLS signaling | The existing services using MPLS LSP tunnels based on MPLS signaling | |||
mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the | mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the | |||
PCECC for label assignments for the L3VPN, PWE3 and | PCECC for label assignments for the L3VPN, PWE3 and | |||
IPv6 as well.</t>--> | IPv6 as well.</t>--> | |||
<t> | <t> | |||
In the case of L3VPN, VPN labels could also be assigned and distributed | In the case of L3VPN, VPN labels could also be assigned and distributed | |||
through PCEP among the PE router instead of using the BGP | through PCEP among the Provider Edge (PE) router instead of using the BGP | |||
protocols.</t> | protocols.</t> | |||
<t> | ||||
<t> | ||||
The example described in this section is based on network configurations | The example described in this section is based on network configurations | |||
illustrated using <xref target="fig_l3vpn"/>:</t> | illustrated in <xref target="fig_l3vpn" format="default"/>:</t> | |||
<figure anchor="fig_l3vpn"> | ||||
<figure title="PCECC for L3VPN and PWE3" anchor="fig_l3vpn"><artwork><![CDATA[ | <name>PCECC for L3VPN and PWE3</name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| PCE DOMAIN | | | PCE DOMAIN | | |||
| +-----------------------------------+ | | | +-----------------------------------+ | | |||
| | PCECC | | | | | PCECC | | | |||
| +-----------------------------------+ | | | +-----------------------------------+ | | |||
| ^ ^ ^ | | | ^ ^ ^ | | |||
|PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP | | | PWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP | | |||
| V V V | | | V V V | | |||
+--------+ | +--------+ +--------+ +--------+ | +--------+ | +--------+ | +--------+ +--------+ +--------+ | +--------+ | |||
| CE | | | PE1 | | NODE x | | PE2 | | | CE | | | CE | | | PE1 | | NODE x | | PE2 | | | CE | | |||
| |...... | |...| |...| |.....| | | | |...... | |...| |...| |.....| | | |||
| Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | | | Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | | |||
| Node | | | Enabled| |Enabled | |Enabled | | | Node | | | Node | | | Enabled| |Enabled | |Enabled | | | Node | | |||
+--------+ | +--------+ +--------+ +--------+ | +--------+ | +--------+ | +--------+ +--------+ +--------+ | +--------+ | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
In the case of PWE3, instead of using the LDP signalling protocols, the | In the case of PWE3, instead of using the LDP signalling protocols, the | |||
label and port pairs assigned to each pseudowire can be assigned | label and port pairs assigned to each pseudowire can be assigned | |||
through PCECC among the PE routers and the corresponding forwarding | through the PCECC among the PE routers and the corresponding forwarding | |||
entries will be distributed into each PE router through the extended | entries will be distributed into each PE router through the extended | |||
PCEP and PCECC mechanism.</t> | PCEP and PCECC mechanism.</t> | |||
</section> | ||||
</section> | <section anchor="sect-15.3" numbered="true" toc="default"> | |||
<section title="PCECC for Local Protection (RSVP-TE)" anchor="sect-15.3"> | <name>PCECC for Local Protection (RSVP-TE)</name> | |||
<t><xref target="I-D.cbrt-pce-stateful-local-protection"/> claim that there | <t><xref target="I-D.cbrt-pce-stateful-local-protection" format="default | |||
is a need for the PCE to maintain and associate the local protection paths for t | "/> claims that there is a need for the PCE to maintain and associate the local | |||
he RSVP-TE LSP. | protection paths for the RSVP-TE LSP. | |||
Local protection requires the setup of a bypass at the PLR. This | Local protection requires the setup of a bypass at the PLR. This | |||
bypass can be PCC-initiated and delegated, or PCE-initiated. In | bypass can be PCC-initiated and delegated or PCE-initiated. In | |||
either case, the PLR needs to maintain a PCEP session with the PCE. The Bypas | either case, the PLR needs to maintain a PCEP session with the PCE. The bypas | |||
s LSPs | s LSPs | |||
need to be mapped to the primary LSP. This could be done locally at the PLR b | need to be mapped to the primary LSP. This could be done locally at the PLR b | |||
ased on a local policy | ased on a local policy, | |||
but there is a need for a PCE to do the mapping as well to exert greater cont rol. </t> | but there is a need for a PCE to do the mapping as well to exert greater cont rol. </t> | |||
<t>This mapping can be done via PCECC procedures where the PCE could ins | ||||
<t>This mapping can be done via PCECC procedures where the PCE could instruct | truct the PLR to the mapping and | |||
the PLR to the mapping and | ||||
identify the primary LSP for which bypass should be used. | identify the primary LSP for which bypass should be used. | |||
</t> | </t> | |||
</section> | </section> | |||
<section title="Using reliable P2MP TE based multicast delivery for distribute | <section anchor="sect-15.4" numbered="true" toc="default"> | |||
d computations (MapReduce-Hadoop)" anchor="sect-15.4"> | <name>Using Reliable P2MP TE-Based Multicast Delivery for Distributed Co | |||
<t> | mputations (MapReduce-Hadoop)</name> | |||
MapReduce model of distributed computations in computing clusters is | ||||
widely deployed. In <eref target="https://hadoop.apache.org/">Hadoop</eref> 1 | ||||
.0 architecture MapReduce operations on | ||||
big data <!--performs by means of Master-Slave architecture-->in the Hadoop | ||||
Distributed File System (HDFS), where NameNode knows about | ||||
resources of the cluster and where actual data (chunks) for a particular | ||||
task are located (which DataNode). Each chunk of data (64MB or more) | ||||
should have 3 saved copies in different DataNodes based on their | ||||
proximity.</t> | ||||
<t> | <t> | |||
The proximity level currently has a semi-manual allocation and is based on | The MapReduce model of distributed computations in computing clusters is | |||
Rack IDs (The assumption is that closer data are better because of access | widely deployed. | |||
speed/smaller latency).</t> | ||||
<t> | In <eref target="https://hadoop.apache.org/">Hadoop</eref> 1.0 architecture, | |||
JobTracker node is responsible for computation tasks, and scheduling across | MapReduce operations occur on big data <!-- [auth] performs by | |||
DataNodes and also has Rack-awareness. Currently, transport protocols | means of Master-Slave architecture-->in the Hadoop Distributed File System (H | |||
DFS), where | ||||
NameNode knows about resources of the cluster and where actual data | ||||
(chunks) for a particular task are located (which DataNode). | ||||
Each chunk of data (64 MB or more) should have three saved copies in | ||||
different DataNodes based on their proximity.</t> | ||||
<t> | ||||
The proximity level currently has a semi-manual allocation and is based on | ||||
Rack IDs (the assumption is that closer data is better because of access | ||||
speed / smaller latency).</t> | ||||
<t> | ||||
The JobTracker node is responsible for computation tasks and scheduling acros | ||||
s | ||||
DataNodes and also has Rack awareness. Currently, transport protocols | ||||
between NameNode/JobTracker and DataNodes are based on IP unicast. | between NameNode/JobTracker and DataNodes are based on IP unicast. | |||
It has simplicity as an advantage but has numerous drawbacks related to | It has simplicity as an advantage but has numerous drawbacks related to | |||
its flat approach.</t> | its flat approach.</t> | |||
<t> | ||||
<t> | There is a need to go beyond one data center (DC) for Hadoop cluster | |||
There is a need to go beyond one data centre (DC) for Hadoop cluster creation | creation and move towards distributed clusters. In that case, one needs to | |||
and move towards distributed clusters. In that case, one needs to handle | handle performance and latency issues. Latency depends on the speed of | |||
performance and latency issues. | light in the fiber links and on the latency introduced by intermediate | |||
Latency depends on the speed of light in the fibre links and on the latency | devices in between. The latter is closely correlated with network device | |||
introduced by intermediate devices in between. The latter is | architecture and performance. The current performance of routers based on Ne | |||
closely correlated with network device architecture and performance. | twork Processing Unit (NPU) | |||
The current performance of NPU-based routers should be enough for creating | should be enough for creating distributed Hadoop clusters with predicted | |||
distributed Hadoop clusters with predicted latency. The performance of softwa | latency. The performance of software-based routers (mainly Virtual Network | |||
re-based routers (mainly virtual network functions (VNF)) with additional hardwa | Functions (VNFs)) with additional hardware features such as the Data Plane | |||
re features such | Development Kit (DPDK) is promising but requires additional research and | |||
as the Data Plane Development Kit (DPDK) is promising but requires additional | testing.</t> | |||
research and testing.</t> | <t> | |||
<t> | ||||
The main question is how to create a simple but effective architecture for | The main question is how to create a simple but effective architecture for | |||
a distributed Hadoop cluster.</t> | a distributed Hadoop cluster.</t> | |||
<t> | ||||
<t> | There is research <xref target="MAP-REDUCE" format="default"/> that shows | |||
There is research <xref target="MAP-REDUCE"/> that show | ||||
how usage of the multicast tree could improve the speed of resource or cluste r | how usage of the multicast tree could improve the speed of resource or cluste r | |||
members' discovery inside the cluster as well as increased redundancy in | members' discovery inside the cluster as well as increased redundancy in | |||
communications between cluster nodes.</t> | communications between cluster nodes.</t> | |||
<t> | <t> | |||
The traditional IP-based multicast may not be appropriate because it | The traditional IP-based multicast may not be appropriate because it | |||
requires an additional control plane (IGMP, PIM) and a lot of signalling, tha | requires an additional control plane (IGMP, PIM) and a lot of signalling, whi | |||
t | ch | |||
is not suitable for high-performance computations, that are very sensitive | is not suitable for high-performance computations that are very sensitive | |||
to latency.</t> | to latency.</t> | |||
<t> | ||||
<t> | ||||
P2MP TE tunnels are more suitable as a potential solution for the creation | P2MP TE tunnels are more suitable as a potential solution for the creation | |||
of multicast-based communications between NameNode as root and DataNodes as l eaves inside the | of multicast-based communications between NameNode as the root and DataNodes as leaves inside the | |||
cluster. These P2MP tunnels could be dynamically created and | cluster. These P2MP tunnels could be dynamically created and | |||
turned down (with no manual intervention). Here, the PCECC comes into play wi th | turned down (with no manual intervention). Here, the PCECC comes into play wi th | |||
the main objective of creating an optimal topology for each particular reque st for | the main objective of creating an optimal topology for each particular reque st for | |||
MapReduce computation and creating P2MP tunnels with needed parameters | MapReduce computation and creating P2MP tunnels with needed parameters | |||
such as bandwidth and delay.</t> | such as bandwidth and delay.</t> | |||
<t> | ||||
<t> | ||||
This solution will require the use of MPLS label-based forwarding inside the | This solution will require the use of MPLS label-based forwarding inside the | |||
cluster. The usage of label-based forwarding inside DC was proposed by Yandex | cluster. The usage of label-based forwarding inside DC was proposed by Yandex | |||
<xref target="MPLS-DC"/>. Technically it is already possible because MPLS on | <xref target="MPLS-DC" format="default"/>. Technically, it is already possibl | |||
switches | e because MPLS on switches | |||
is already supported by some vendors, MPLS also exists on Linux and OVS.</t> | is already supported by some vendors, and MPLS also exists on Linux and Open | |||
vSwitch (OVS).</t> | ||||
<t>A possible framework for this task is shown in <xref target="fig_mapred"/>: | <t>A possible framework for this task is shown in <xref target="fig_mapr | |||
</t> | ed" format="default"/>: | |||
</t> | ||||
<figure title="Using reliable P2MP TE based multicast delivery for distributed | <figure anchor="fig_mapred"> | |||
computations (MapReduce-Hadoop)" anchor="fig_mapred"><artwork><![CDATA[ | <name>Using Reliable P2MP TE-Based Multicast Delivery for Distributed | |||
Computations (MapReduce-Hadoop)</name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
+--------+ | +--------+ | |||
| APP | | | APP | | |||
+--------+ | +--------+ | |||
| NBI (REST API,...) | | NBI (REST API,...) | |||
| | | | |||
PCEP +----------+ REST API | PCEP +----------+ REST API | |||
+---------+ +---| PCECC |----------+ | +---------+ +---| PCECC |----------+ | |||
| Client |---|---| | | | | Client |---|---| | | | |||
+---------+ | +----------+ | | +---------+ | +----------+ | | |||
| | | | | | | | | | | | | | |||
skipping to change at line 1785 ¶ | skipping to change at line 2382 ¶ | |||
| | | | | | | | | | | | | | | | | | |||
+-------------+ | | | | +----------+ | +-------------+ | | | | +----------+ | |||
+------------------+ | +-----------+ | +------------------+ | +-----------+ | |||
| | | | | | | | | | |||
|---+-----P2MP TE--+-----|-----------| | | |---+-----P2MP TE--+-----|-----------| | | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
| DataNode1| | DataNode2| | DataNodeN| | | DataNode1| | DataNode2| | DataNodeN| | |||
|TaskTraker| |TaskTraker| .... |TaskTraker| | |TaskTraker| |TaskTraker| .... |TaskTraker| | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | ||||
Communication between JobTracker, NameNode | ||||
and PCECC can be done via REST API directly or via | ||||
cluster manager such as Mesos.</t> | ||||
<t> | <t>Communication between the JobTracker, NameNode, and PCECC can be done | |||
Phase 1: Distributed cluster resources discovery | via REST API directly or via a cluster manager such as Mesos.</t> | |||
During this phase, JobTracker and NameNode should identify and find available | <ul> | |||
DataNodes according to computing requests from the application (APP). | <li> | |||
NameNode should query PCECC about available DataNodes, NameNode may | <t> | |||
provide additional constraints to PCECC such as topological proximity, | Phase 1: Distributed cluster resource discovery occurs during this | |||
and redundancy level.</t> | phase. JobTracker and NameNode should identify and find available | |||
DataNodes according to computing requests from the application (APP). | ||||
NameNode should query the PCECC about available DataNodes, and NameNode ma | ||||
y | ||||
provide additional constraints to the PCECC such as topological proximity | ||||
and redundancy level. | ||||
</t> | ||||
<t> | ||||
The PCECC should analyze the topology of the distributed cluster and perfo | ||||
rm | ||||
a constraint-based path calculation from the client towards the most | ||||
suitable NameNodes. The PCECC should reply to NameNode with the list of th | ||||
e | ||||
most suitable DataNodes and their resource capabilities. The topology | ||||
discovery mechanism for the PCECC will be added later to that framework. | ||||
</t> | ||||
</li> | ||||
<li> | ||||
Phase 2: The PCECC should create P2MP LSPs from the client towards those | ||||
DataNodes by means of PCEP messages following the previously calculated | ||||
path. | ||||
</li> | ||||
<li> | ||||
Phase 3: NameNode should send this information to the client, and the PCECC | ||||
should inform the client about the optimal P2MP path towards DataNodes via a | ||||
PCEP message. | ||||
</li> | ||||
<li> | ||||
Phase 4: The client sends data blocks to those DataNodes for writing via | ||||
the created P2MP tunnel. | ||||
</li> | ||||
</ul> | ||||
<t>When this task is finished, the P2MP tunnel could be turned down.</t> | ||||
</section> | ||||
</section> | ||||
<t> | <section anchor="sect-14" numbered="false" toc="default"> | |||
PCECC should analyze the topology of the distributed cluster and perform | <name>Acknowledgments</name> | |||
constraint-based path calculation from the client towards the most | <t>Thanks to <contact fullname="Adrian Farrel"/>, <contact | |||
suitable NameNodes. PCECC should reply to NameNode with the list of the most | fullname="Aijun Wang"/>, <contact fullname="Robert Tao"/>, <contact | |||
suitable DataNodes and their resource capabilities. The topology discovery | fullname="Changjiang Yan"/>, <contact fullname="Tieying Huang"/>, | |||
mechanism for PCECC will be added later to that framework.</t> | <contact fullname="Sergio Belotti"/>, <contact fullname="Dieter | |||
Beller"/>, <contact fullname="Andrey Elperin"/>, and <contact | ||||
fullname="Evgeniy Brodskiy"/> for their useful comments and | ||||
suggestions.</t> | ||||
<t>Thanks to <contact fullname="Mach Chen"/> and <contact | ||||
fullname="Carlos Pignataro"/> for the RTGDIR review. Thanks to <contact | ||||
fullname="Derrell Piper"/> for the SECDIR review. Thanks to <contact | ||||
fullname="Sue Hares"/> for GENART review.</t> | ||||
<t>Thanks to <contact fullname="Vishnu Pavan Beeram"/> for being the | ||||
document shepherd and <contact fullname="Jim Guichard"/> for being the | ||||
responsible AD.</t> | ||||
<t>Thanks to <contact fullname="Roman Danyliw"/> for the IESG review | ||||
comments.</t> | ||||
</section> | ||||
<t> | <section toc="default" numbered="false"> | |||
Phase 2: PCECC should create P2MP LSP from the client towards those | <name>Contributors</name> | |||
DataNodes by means of PCEP messages following the previously calculated path. | ||||
</t> | ||||
<t>Phase 3. NameNode should send this information to the client, and PCECC sho | <contact fullname="Luyuan Fang"> | |||
uld inform | <organization></organization> | |||
the client about the optimal P2MP path towards DataNodes via PCEP message. | <address> | |||
</t> | <postal> | |||
<street></street> | ||||
<city></city> | ||||
<region></region> | ||||
<code></code> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>luyuanf@gmail.com</email> | ||||
</address> | ||||
</contact> | ||||
<t> | <contact fullname="Chao Zhou"> | |||
Phase 4. The Client sends data blocks to those DataNodes for writing via | <organization>HPE</organization> | |||
the created P2MP tunnel.</t> | <address> | |||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<region></region> | ||||
<code></code> | ||||
<country></country> | ||||
</postal> | ||||
<email>chaozhou_us@yahoo.com</email> | ||||
</address> | ||||
</contact> | ||||
<t> | <contact fullname="Boris Zhang"> | |||
When this task is finished, the P2MP tunnel could be turned down.</t> | <organization>Amazon</organization> | |||
<address> | ||||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<region></region> | ||||
<code></code> | ||||
<country></country> | ||||
</postal> | ||||
<email>zhangyud@amazon.com</email> | ||||
</address> | ||||
</contact> | ||||
</section> | <contact fullname="Artsiom Rachytski"> | |||
</section> | <organization></organization> | |||
<section title="Contributor Addresses" toc="default"> | <address> | |||
<t><figure align="left" alt="" height="" suppress-title="false" title="" | <postal> | |||
width=""> | <street></street> | |||
<artwork align="left" alt="" height="" name="" type="" width="" | <city></city> | |||
xml:space="preserve"><![CDATA[ | <region></region> | |||
<code></code> | ||||
<country>Belarus</country> | ||||
</postal> | ||||
<email>arachyts@gmail.com</email> | ||||
</address> | ||||
</contact> | ||||
Luyuan Fang | <contact fullname="Anton Gulida"> | |||
United States of America | <organization>EPAM Systems, Inc.</organization> | |||
<address> | ||||
<postal> | ||||
<street></street> | ||||
<city></city> | ||||
<region></region> | ||||
<code></code> | ||||
<country>Belarus</country> | ||||
</postal> | ||||
<email>Anton_Hulida@epam.com</email> | ||||
</address> | ||||
</contact> | ||||
</section> | ||||
Email: luyuanf@gmail.com | <!-- [rfced] We note that paths appear to be formatted differently throughout | |||
this document. Should they appear in quotation marks or without any additional | ||||
text styling? | ||||
Chao Zhou | Original (some examples): | |||
HPE | ||||
Email: chaozhou_us@yahoo.com | The traffic from R1 to R8 which fits color 200 will be steered to POL2 | |||
and follows the path: R1-link2-R2-link4-R5-R6-R8. | ||||
... | ||||
In this step, we will | ||||
have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 | ||||
... | ||||
* PCECC will provision each node along the path and assign incoming | ||||
and outgoing labels from R1 to R8 with the path as | ||||
"R1-link1-R2-link3-R4-link10-R3-link8-R8": | ||||
--> | ||||
Boris Zhang | <!-- [rfced] Should spaces appear between values (90012,1002,90024, etc.)? | |||
Amazon | ||||
Email: zhangyud@amazon.com | Original (some examples): | |||
Artsiom Rachytski | * For the end-to-end protection, PCECC can provision the secondary | |||
Belarus | path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}. | |||
... | ||||
As shown in Figure 3, R1 may send a packet to R8 by pushing an SR | ||||
header with segment list {1002, 9001, 1008}. | ||||
--> | ||||
Email: arachyts@gmail.com | <!-- [rfced] Terminology | |||
Anton Gulida | a) Should instances of "PCEP protocol" be updated to read simply | |||
EPAM Systems, Inc. | "PCEP" to avoid redundancy (if expanded, "PCEP protocol" would read "Path | |||
Belarus | Computation Element Communication Protocol protocol")? Please review and | |||
let us know if any updates are needed. | ||||
Email: Anton_Hulida@epam.com | b) We note use of the terms "PCE-based controller" and "PCE-based central | |||
]]></artwork> | controller". Should these be updated to "PCECC"? | |||
</figure></t> | ||||
</section> | ||||
</back> | ||||
</rfc> | Original (some examples): | |||
For this to work, the PCE-based controller will take responsibility | ||||
for managing some part of the MPLS label space for each of the | ||||
routers that it controls. | ||||
... | ||||
A PCE-based central controller can consider the whole | ||||
network and all components of a service at once when planning how to | ||||
deliver the service. | ||||
c) FYI - The terms below have been updated to match how they appear in RFCs | ||||
8279 and 9262. Please review and let us know any objections. | ||||
Original / Current: | ||||
bitmask / BitMask | ||||
BFR-ID / BFR-id | ||||
subdomain-ID / sub-domain-id | ||||
BIER Encapsulation / BIER encapsulation | ||||
d) We note the following differences in the use of the terms below. Please | ||||
review and let us know how to update each item for consistency. | ||||
headend v. head end | ||||
NODE 1 v. Node1 v. Node 3 (regarding spacing and capitalization) | ||||
--> | ||||
<!-- [rfced] Abbreviations | ||||
a) FYI - we have added expansions for "AS" and "ASBR" to the Terminology section | ||||
to avoid awkward expansions in the body of the text. Please let us know any | ||||
objections. | ||||
b) To match usage in RFC 5440, may we expand and update "TEDB" to "Traffic | ||||
Engineering Database (TED)" ? | ||||
Original: | ||||
* Since PCECC is aware of TEDB (TE state) and LSP-DB... | ||||
Perhaps: | ||||
* Since PCECC is aware of Traffic Engineering Database (TED) (TE state) | ||||
and LSP-DB... | ||||
c) How should "NBI" be expanded in the text below? | ||||
Original: | ||||
* After the operator's application or service orchestrator creates a | ||||
request for tunnel creation of a specific service, PCECC will | ||||
receive that request via NBI (NBI type is implementation | ||||
dependent, it could be NETCONF/Yang, REST etc.). | ||||
d) We note two different expansions of "TE" in this document. Should these | ||||
be updated for consistency? | ||||
traffic-engineered (TE) | ||||
Traffic Engineering (TE) | ||||
e) This document has mixed usage of the expanded and abbreviated forms of the | ||||
following terms. After they are expanded upon first use, may we replace all | ||||
instances thereafter with the abbreviated form (per guidance from the Web | ||||
Portion of the Style Guide at | ||||
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)? | ||||
Objective Function (OF) | ||||
bandwidth (BW) | ||||
Path Setup Type (PST) | ||||
Segment Routing (SR) | ||||
load balancing (LB) | ||||
Layer 3 VPN (L3VPN) | ||||
Ethernet VPN (EVPN) | ||||
f) FYI - We have updated the expansion for CCDR to match how it appears in | ||||
RFC 8735. Please let us know any objections. | ||||
Original: | ||||
Centrally Control Dynamic Routing (CCDR) | ||||
Current: | ||||
Centralized Control Dynamic Routing (CCDR) | ||||
g) FYI - We have added expansions for the following abbreviations | ||||
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each | ||||
expansion in the document carefully to ensure correctness. | ||||
Hierarchical PCE (H-PCE) | ||||
LSP Database (LSP-DB) (per RFC 8283) | ||||
Network Processing Unit (NPU) | ||||
Open vSwitch (OVS) | ||||
Provider Edge (PE) | ||||
Service Level Agreement (SLA) | ||||
Service Function Forwarder (SFF) | ||||
SR over MPLS (SR-MPLS) | ||||
SR over IPv6 (SRv6) | ||||
--> | ||||
<!-- [rfced] FYI - There are several author comments in the XML file. These have | ||||
been | ||||
marked with [auth]. Please review these and let us know if any updates are need | ||||
ed | ||||
based on those comments, as they will be removed before publication. | ||||
--> | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the online | ||||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. Updates of this nature typically | ||||
result in more precise language, which is helpful for readers. | ||||
a) For example, please consider whether "native" should be updated in the text | ||||
below: | ||||
Original: | ||||
Section 3.9. PCECC for Native IP | ||||
Figure 12: PCECC for Native IP | ||||
...traffic engineering for native IP networks. [RFC8821] defines the | ||||
framework for CCDR traffic engineering within a Native IP network... | ||||
b) In addition, please consider whether "tradition" should be updated for | ||||
clarity. While the NIST website | ||||
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a | ||||
uthor-instructions#table1> | ||||
indicates that this term is potentially biased, it is also ambiguous. | ||||
"Tradition" is a subjective term, as it is not the same for everyone. | ||||
Original: | ||||
The traditional IP-based multicast may not be appropriate because it... | ||||
--> | ||||
</back> | ||||
</rfc> | ||||
End of changes. 267 change blocks. | ||||
1391 lines changed or deleted | 2037 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |