draft-ietf-teas-pce-native-ip-10.txt   draft-ietf-teas-pce-native-ip-11.txt 
TEAS Working Group A. Wang TEAS Working Group A. Wang
Internet-Draft China Telecom Internet-Draft China Telecom
Intended status: Experimental B. Khasanov Intended status: Experimental B. Khasanov
Expires: February 11, 2021 Huawei Technologies Expires: February 26, 2021 Huawei Technologies
Q. Zhao Q. Zhao
Etheric Networks Etheric Networks
H. Chen H. Chen
Futurewei Futurewei
August 10, 2020 August 25, 2020
PCE in Native IP Network PCE in Native IP Network
draft-ietf-teas-pce-native-ip-10 draft-ietf-teas-pce-native-ip-11
Abstract Abstract
This document defines the architecture for traffic engineering within This document defines the architecture for traffic engineering within
native IP network, using multiple BGP sessions strategy and PCE native IP network, using multiple BGP sessions strategy and PCE
-based central control mechanism. It uses the Central Control -based central control mechanism. It uses the Central Control
Dynamic Routing (CCDR) procedures described in this document, and the Dynamic Routing (CCDR) procedures described in this document, and the
Path Computation Element Communication Protocol (PCEP) extension Path Computation Element Communication Protocol (PCEP) extension
specified in draft ietf-pce-pcep-extension-native-ip. specified in draft ietf-pce-pcep-extension-native-ip.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 11, 2021. This Internet-Draft will expire on February 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
path computations within and across PCEP sessions. Furthermore, path computations within and across PCEP sessions. Furthermore,
[RFC8281] specifies a mechanism to dynamically instantiate LSPs on a [RFC8281] specifies a mechanism to dynamically instantiate LSPs on a
PCC based on the requests from a stateful PCE or a controller using PCC based on the requests from a stateful PCE or a controller using
stateful PCE. [RFC8283] introduces the architecture for PCE as a stateful PCE. [RFC8283] introduces the architecture for PCE as a
central controller as an extension of the architecture described in central controller as an extension of the architecture described in
[RFC4655] and assumes the continued use of PCEP as the protocol used [RFC4655] and assumes the continued use of PCEP as the protocol used
between PCE and PCC.[RFC8283] further examines the motivations and between PCE and PCC.[RFC8283] further examines the motivations and
applicability for PCEP as a Southbound Interface (SBI), and applicability for PCEP as a Southbound Interface (SBI), and
introduces the implications for the protocol. introduces the implications for the protocol.
This document defines the framework for traffic engineering within This document defines the architecture for traffic engineering within
native IP network, using multiple BGP session strategy, to meet the native IP network, using multiple BGP session strategy, to meet the
above criteria in dynamical and centrally control mode. The above criteria in dynamical and centrally control mode. The
framework is referred as CCDR framework. It depends on the central architecture is referred as CCDR architecture. It depends on the
control (PCE) element to compute the optimal path for selected central control (PCE) element to compute the optimal path for
traffic, and utilizes the dynamic routing behavior of traditional selected traffic, and utilizes the dynamic routing behavior of
IGP/BGP protocols to forward such traffic. traditional IGP/BGP protocols to forward such traffic.
The control messages between PCE and underlying network node are The control messages between PCE and underlying network node are
transmitted via Path Computation Element Communications Protocol transmitted via Path Computation Element Communications Protocol
(PCEP) protocol. The related PCEP extensions are provided in draft (PCEP) protocol. The related PCEP extensions are provided in draft
[I-D.ietf-pce-pcep-extension-native-ip]. [I-D.ietf-pce-pcep-extension-native-ip].
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: This document uses the following terms defined in [RFC5440]:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
normal traffic, traffic between prefix PF12(on SW1) and prefix normal traffic, traffic between prefix PF12(on SW1) and prefix
PF22(on SW2) is priority traffic that should be treated with PF22(on SW2) is priority traffic that should be treated with
priority. priority.
In Intra-AS scenario, IGP and BGP are deployed between R1 and R2. In In Intra-AS scenario, IGP and BGP are deployed between R1 and R2. In
inter-AS scenario, only native BGP protocol is deployed. The traffic inter-AS scenario, only native BGP protocol is deployed. The traffic
between each address pair may change in real time and the between each address pair may change in real time and the
corresponding source/destination addresses of the traffic may also corresponding source/destination addresses of the traffic may also
change dynamically. change dynamically.
The key ideas of the CCDR framework for this simple topology are the The key ideas of the CCDR architecture for this simple topology are
followings: the followings:
o Build two BGP sessions between R1 and R2, via the different o Build two BGP sessions between R1 and R2, via the different
loopback addresses on these routers. loopback addresses on these routers.
o Send different prefixes via the established BGP sessions. For o Send different prefixes via the established BGP sessions. For
example, PF11/PF21 via the BGP session 1 and PF12/PF22 via the BGP example, PF11/PF21 via the BGP session 1 and PF12/PF22 via the BGP
session 2. session 2.
o Set the explicit peer route on R1 and R2 respectively for BGP next o Set the explicit peer route on R1 and R2 respectively for BGP next
hop to different physical link addresses between R1 and R2. Such hop to different physical link addresses between R1 and R2. Such
skipping to change at page 5, line 37 skipping to change at page 5, line 37
| | | |
| BGP Session 2(lo12/lo22)| | BGP Session 2(lo12/lo22)|
+-------------------------+ +-------------------------+
PF12 | | PF22 PF12 | | PF22
PF11 | | PF21 PF11 | | PF21
+---+ +-----+-----+ +-----+-----+ +---+ +---+ +-----+-----+ +-----+-----+ +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+--------------+SW2| |SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+--------------+SW2|
+---+ | R1 +-------------+ R2 | +---+ +---+ | R1 +-------------+ R2 | +---+
+-----------+ +-----------+ +-----------+ +-----------+
Figure 1: CCDR framework in simple topology Figure 1: CCDR architecture in simple topology
4. CCDR Architecture in Large Scale Topology 4. CCDR Architecture in Large Scale Topology
When the assured traffic spans across the large scale network, as When the assured traffic spans across the large scale network, as
that illustrated in Figure 2, the multiple BGP sessions cannot be that illustrated in Figure 2, the multiple BGP sessions cannot be
established hop by hop, especially for the iBGP within one AS. established hop by hop, especially for the iBGP within one AS.
For such scenario, we should consider using the Route Reflector (RR) For such scenario, we should consider using the Route Reflector (RR)
[RFC4456] to achieve the similar effect. Every edge router will [RFC4456] to achieve the similar effect. Every edge router will
establish two BGP sessions with the RR via different loopback establish two BGP sessions with the RR via different loopback
addresses respectively. The other steps for traffic differentiation addresses respectively. The other steps for traffic differentiation
are same as that described in the CCDR framework for simple topology. are same as that described in the CCDR architecture for simple
topology.
As shown in Figure 2, if we select R3 as the RR, every edge router(R1 As shown in Figure 2, if we select R3 as the RR, every edge router(R1
and R7 in this example) will build two BGP session with the RR. If and R7 in this example) will build two BGP session with the RR. If
the PCE selects the dedicated path as R1-R2-R4-R7, then the operator the PCE selects the dedicated path as R1-R2-R4-R7, then the operator
should set the explicit peer routes via PCEP protocol on these should set the explicit peer routes via PCEP protocol on these
routers respectively, pointing to the BGP next hop (loopback routers respectively, pointing to the BGP next hop (loopback
addresses of R1 and R7, which are used to send the prefix of the addresses of R1 and R7, which are used to send the prefix of the
assured traffic) to the selected forwarding address. assured traffic) to the selected forwarding address.
+-----+ +-----+
skipping to change at page 6, line 30 skipping to change at page 6, line 30
PF12 | +--+ | PF22 PF12 | +--+ | PF22
PF11 | | PF21 PF11 | | PF21
+---+ ++-+ +--+ +--+ +-++ +---+ +---+ ++-+ +--+ +--+ +-++ +---+
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2| |SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2|
+---+ ++-+ +--+ +--+ +-++ +---+ +---+ ++-+ +--+ +--+ +-++ +---+
| | | |
| | | |
| +--+ +--+ | | +--+ +--+ |
+------------+R2+----------+R4+-----------+ +------------+R2+----------+R4+-----------+
+--+ +--+ +--+ +--+
Figure 2: CCDR framework in large scale network Figure 2: CCDR architecture in large scale network
5. CCDR Multiple BGP Sessions Strategy 5. CCDR Multiple BGP Sessions Strategy
In general situation, different applications may require different In general situation, different applications may require different
QoS criteria, which may include: QoS criteria, which may include:
o Traffic that requires low latency and is not sensitive to packet o Traffic that requires low latency and is not sensitive to packet
loss. loss.
o Traffic that requires low packet loss and can endure higher o Traffic that requires low packet loss and can endure higher
skipping to change at page 7, line 33 skipping to change at page 7, line 33
It is almost impossible to provide an End-to-End (E2E) path It is almost impossible to provide an End-to-End (E2E) path
efficiently with latency, jitter, packet loss constraints to meet the efficiently with latency, jitter, packet loss constraints to meet the
above requirements in large scale IP-based network via the above requirements in large scale IP-based network via the
distributed routing protocol, but these requirements can be solved distributed routing protocol, but these requirements can be solved
with the assistance of PCE, as that described in [RFC4655] and with the assistance of PCE, as that described in [RFC4655] and
[RFC8283] because the PCE has the overall network view, can collect [RFC8283] because the PCE has the overall network view, can collect
real network topology and network performance information about the real network topology and network performance information about the
underlying network, select the appropriate path to meet various underlying network, select the appropriate path to meet various
network performance requirements of different traffics. network performance requirements of different traffics.
The framework to implement the CCDR Multiple BGP sessions strategy The architecture to implement the CCDR Multiple BGP sessions strategy
are the followings. Here PCE is the main component of the Software are the followings. Here PCE is the main component of the Software
Definition Network (SDN) controller and is responsible for optimal Definition Network (SDN) controller and is responsible for optimal
path computation for priority traffic. path computation for priority traffic.
o SDN controller gets topology via BGP-LS[RFC7752] and link o SDN controller gets topology via BGP-LS[RFC7752] and link
utilization information via existing Network Monitor System (NMS) utilization information via existing Network Monitor System (NMS)
from the underlying network. from the underlying network.
o PCE calculates the appropriate path upon application's o PCE calculates the appropriate path upon application's
requirements, sends the key parameters to edge/RR routers(R1, R7 requirements, sends the key parameters to edge/RR routers(R1, R7
skipping to change at page 8, line 38 skipping to change at page 8, line 38
PF12 | +--+ | PF22 PF12 | +--+ | PF22
PF11 | | PF21 PF11 | | PF21
+---+ +v-+ +--+ +--+ +-v+ +---+ +---+ +v-+ +--+ +--+ +-v+ +---+
|SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2| |SW1+-------+R1+----------+R5+----------+R6+---------+R7+--------+SW2|
+---+ ++-+ +--+ +--+ +-++ +---+ +---+ ++-+ +--+ +--+ +-++ +---+
| | | |
| | | |
| +--+ +--+ | | +--+ +--+ |
+------------+R2+----------+R4+-----------+ +------------+R2+----------+R4+-----------+
Figure 3: CCDR framework for Multi-BGP deployment Figure 3: CCDR architecture for Multi-BGP deployment
6. PCEP Extension for Key Parameters Delivery 6. PCEP Extension for Key Parameters Delivery
The PCEP protocol needs to be extended to transfer the following key The PCEP protocol needs to be extended to transfer the following key
parameters: parameters:
o Peer addresses pair that is used to build the BGP session o Peer addresses pair that is used to build the BGP session
o Advertised prefixes and their associated BGP session. o Advertised prefixes and their associated BGP session.
skipping to change at page 9, line 25 skipping to change at page 9, line 25
[RFC8231] and PCECC [RFC8283] mechanism. [RFC8231] and PCECC [RFC8283] mechanism.
Details of communications between PCEP and BGP subsystems in router's Details of communications between PCEP and BGP subsystems in router's
control plane are out of scope of this draft and will be described in control plane are out of scope of this draft and will be described in
separate draft [I-D.ietf-pce-pcep-extension-native-ip] . separate draft [I-D.ietf-pce-pcep-extension-native-ip] .
7. Deployment Consideration 7. Deployment Consideration
7.1. Scalability 7.1. Scalability
In CCDR framework, PCE needs only influence the edge routers for the In CCDR architecture, PCE needs only influence the edge routers for
prefixes advertisement via the multiple BGP sessions deployment. The the prefixes advertisement via the multiple BGP sessions deployment.
route information for these prefixes within the on-path routers were The route information for these prefixes within the on-path routers
distributed via the BGP protocol. were distributed via the BGP protocol.
For multiple domains deployment, the PCE or the pool of PCEs that For multiple domains deployment, the PCE or the pool of PCEs that
reponsible for these domains need only control the edge router to reponsible for these domains need only control the edge router to
build multiple EBGP sessions, all other procedures are the same that build multiple EBGP sessions, all other procedures are the same that
in one domain. in one domain.
Unlike the solution from BGP Flowspec, the on-path router need only Unlike the solution from BGP Flowspec, the on-path router need only
keep the specific policy routes to the BGP next-hop of the keep the specific policy routes to the BGP next-hop of the
differentiate prefixes, not the specific routes to the prefixes differentiate prefixes, not the specific routes to the prefixes
themselves. This can lessen the burden from the table size of policy themselves. This can lessen the burden from the table size of policy
based routes for the on-path routers, and has more expandability when based routes for the on-path routers, and has more expandability when
comparing with the solution from BGP flowspec or Openflow. For comparing with the solution from BGP flowspec or Openflow. For
example, if we want to differentiate 1000 prefixes from the normal example, if we want to differentiate 1000 prefixes from the normal
traffic, CCDR needs only one explicit peer route in every on-path traffic, CCDR needs only one explicit peer route in every on-path
router, but the BGP flowspec or Openflow needs 1000 policy routes on router, but the BGP flowspec or Openflow needs 1000 policy routes on
them. them.
7.2. High Availability 7.2. High Availability
The CCDR framework is based on the distributed IP protocol. If the The CCDR architecture is based on the distributed IP protocol. If
PCE failed, the forwarding plane will not be impacted, as the BGP the PCE failed, the forwarding plane will not be impacted, as the BGP
session between all devices will not flap, and the forwarding table session between all devices will not flap, and the forwarding table
will remain unchanged. will remain unchanged.
If one node on the optimal path is failed, the priority traffic will If one node on the optimal path is failed, the priority traffic will
fall over to the best-effort forwarding path. One can even design fall over to the best-effort forwarding path. One can even design
several assurance paths to load balance/hot-standby the priority several assurance paths to load balance/hot-standby the priority
traffic to meet the path failure situation. traffic to meet the path failure situation.
For high availability of PCE/SDN-controller, operator should rely on For high availability of PCE/SDN-controller, operator should rely on
existing high availability solutions for SDN controller, such as existing high availability solutions for SDN controller, such as
skipping to change at page 10, line 31 skipping to change at page 10, line 31
first, and then the traffic can be assured between different domains. first, and then the traffic can be assured between different domains.
Within each domain, the traffic will be forwarded along the best- Within each domain, the traffic will be forwarded along the best-
effort path. Service provider can selectively upgrade the routers on effort path. Service provider can selectively upgrade the routers on
each domain in sequence. each domain in sequence.
8. Security Considerations 8. Security Considerations
A PCE needs to assure calculation of E2E path based on the status of A PCE needs to assure calculation of E2E path based on the status of
network and the service requirements in real-time. network and the service requirements in real-time.
The PCE need consider the explicit route deployment order (for The PCE needs consider the explicit route deployment order (for
example, from tail router to head router) to eliminate the possible example, from tail router to head router) to eliminate the possible
transient traffic loop. transient traffic loop.
The setup of BGP session, prefix advertisement and explicit peer The setup of BGP session, prefix advertisement and explicit peer
route establishment are all controlled by the PCE. To prevent the route establishment are all controlled by the PCE. To prevent the
bogus PCE to send harmful messages to the network nodes, the network bogus PCE to send harmful messages to the network nodes, the network
devices should authenticate the validity of PCE and keep secures devices should authenticate the validity of PCE and keep secures
communication channel between them. Mechanism described in [RFC8253] communication channel between them. Mechanism described in [RFC8253]
should be used to avoid such situation. should be used to avoid such situation.
CCDR framework does not require the change of forward behavior on the CCDR architecture does not require the change of forward behavior on
underlay devices, then there will no additional security impact on the underlay devices, then there will no additional security impact
the devices. on the devices.
9. IANA Considerations 9. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
10. Acknowledgement 10. Acknowledgement
The author would like to thank Deborah Brungard, Adrian Farrel, The author would like to thank Deborah Brungard, Adrian Farrel,
Vishnu Beeram, Lou Berger, Dhruv Dhody, Raghavendra Mallya , Mike Vishnu Beeram, Lou Berger, Dhruv Dhody, Raghavendra Mallya , Mike
Koldychev, Haomian Zheng, Penghui Mi, Shaofu Peng and Jessica Chen Koldychev, Haomian Zheng, Penghui Mi, Shaofu Peng and Jessica Chen
skipping to change at page 12, line 27 skipping to change at page 12, line 27
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP "Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>. <https://www.rfc-editor.org/info/rfc8735>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pce-pcep-extension-native-ip] [I-D.ietf-pce-pcep-extension-native-ip]
Wang, A., Khasanov, B., Fang, S., and C. Zhu, "PCEP Wang, A., Khasanov, B., Fang, S., and C. Zhu, "PCEP
Extension for Native IP Network", draft-ietf-pce-pcep- Extension for Native IP Network", draft-ietf-pce-pcep-
extension-native-ip-05 (work in progress), February 2020. extension-native-ip-06 (work in progress), August 2020.
Authors' Addresses Authors' Addresses
Aijun Wang Aijun Wang
China Telecom China Telecom
Beiqijia Town, Changping District Beiqijia Town, Changping District
Beijing 102209 Beijing 102209
China China
Email: wangaj3@chinatelecom.cn Email: wangaj3@chinatelecom.cn
 End of changes. 17 change blocks. 
27 lines changed or deleted 28 lines changed or added

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