draft-ietf-pce-pcep-extension-native-ip-15.txt   draft-ietf-pce-pcep-extension-native-ip-16.txt 
PCE Working Group A. Wang PCE Working Group A. Wang
Internet-Draft China Telecom Internet-Draft China Telecom
Intended status: Standards Track B. Khasanov Intended status: Standards Track B. Khasanov
Expires: 28 January 2022 Yandex LLC Expires: 17 February 2022 Yandex LLC
S. Fang S. Fang
R. Tan R. Tan
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
C. Zhu C. Zhu
ZTE Corporation ZTE Corporation
27 July 2021 16 August 2021
PCEP Extension for Native IP Network PCEP Extension for Native IP Network
draft-ietf-pce-pcep-extension-native-ip-15 draft-ietf-pce-pcep-extension-native-ip-16
Abstract Abstract
This document defines the Path Computation Element Communication This document defines the Path Computation Element Communication
Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
based application in Native IP network. The scenario and framework based application in Native IP network. The scenario and framework
of CCDR in native IP is described in [RFC8735] and [RFC8821]. This of CCDR in native IP is described in [RFC8735] and [RFC8821]. This
draft describes the key information that is transferred between Path draft describes the key information that is transferred between Path
Computation Element (PCE) and Path Computation Clients (PCC) to Computation Element (PCE) and Path Computation Clients (PCC) to
accomplish the End to End (E2E) traffic assurance in Native IP accomplish the End to End (E2E) traffic assurance in Native IP
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 28 January 2022. This Internet-Draft will expire on 17 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Capability Advertisemnt . . . . . . . . . . . . . . . . . . . 4 4. Capability Advertisemnt . . . . . . . . . . . . . . . . . . . 4
4.1. Open message . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Open message . . . . . . . . . . . . . . . . . . . . . . 4
5. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 4 5. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The PCInitiate message . . . . . . . . . . . . . . . . . 5 5.1. The PCInitiate message . . . . . . . . . . . . . . . . . 5
5.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 6 5.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 6
6. PCECC Native IP TE Procedures . . . . . . . . . . . . . . . . 7 6. PCECC Native IP TE Procedures . . . . . . . . . . . . . . . . 7
6.1. BGP Session Establishment Procedures . . . . . . . . . . 7 6.1. BGP Session Establishment Procedures . . . . . . . . . . 8
6.2. Explicit Route Establish Procedures . . . . . . . . . . . 9 6.2. Explicit Route Establish Procedures . . . . . . . . . . . 10
6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 12 6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 13
7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14
7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 14 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 15
7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 18
7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 19 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 20
8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 8. End to End Path Protection . . . . . . . . . . . . . . . . . 22
9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 22
10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 11. New Error-Types and Error-Values Defined . . . . . . . . . . 23
12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 24 14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 25
14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 24 14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 25
14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 24 14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 25
14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26
15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 25 15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 26
16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
17. Normative References . . . . . . . . . . . . . . . . . . . . 25 17. Normative References . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-
TE) requires the corresponding network devices support Multiprotocol TE) requires the corresponding network devices support Multiprotocol
Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label
Distribution Protocol (LDP) technologies to assure the End-to-End Distribution Protocol (LDP) technologies to assure the End-to-End
(E2E) traffic performance. In Segment Routing either IGP extensions (E2E) traffic performance. In Segment Routing either IGP extensions
or BGP are used to steer a packet through an SR Policy instantiated or BGP are used to steer a packet through an SR Policy instantiated
as an ordered list of instructions called "segments". But in native as an ordered list of instructions called "segments". But in native
skipping to change at page 7, line 47 skipping to change at page 8, line 7
value=TBD5(Only one of the BPI, EPR or PPA object can be included in value=TBD5(Only one of the BPI, EPR or PPA object can be included in
this message). this message).
6. PCECC Native IP TE Procedures 6. PCECC Native IP TE Procedures
The detail procedures for the TE in native IP environment are The detail procedures for the TE in native IP environment are
described in the following sections. described in the following sections.
6.1. BGP Session Establishment Procedures 6.1. BGP Session Establishment Procedures
The procedures for establishing the BGP session between two peers by The PCInitiate message can be used to configure the parameters for a
using the PCInitiate and PCRpt message pair is shown below. BGP peer session using the PCInitiate and PCRpt message pair. This
pair of PCE messages is exchanged with a PCE function attached to
each BGP peer which needs to be configured. After the BGP peer
session has been configured via this pair of PCE messages the BGP
session establishment process operates in a normal fashion. All BGP
peers are configured for peer to peer communication whether the peers
are E-BGP peers or I-BGP peers. One of the IBGP topologies requires
that multiple I-BGPs peers operate in a route-reflector I-BGP peer
topology. The example below shows two I-BGP route reflector clients
interacting with one Route Reflector (RR), but Route Reflector
topologies may have up to 100s of clients. Centralized configuration
via PCE provides mechanisms to scale auto-configuration of small and
large topologies.
The PCInitiate message should be sent to PCC which acts as BGP router The PCInitiate message should be sent to PCC which acts as BGP router
and/or route reflector(RR). and/or route reflector(RR).
In the example in Figure 1, if the router R1 and R7 are within one AS The route reflector topology for a single AS is shown in Figure 1.
and R3 acts as the route reflector, PCInitiate message should be sent The BGP routers R1, R3, and R7 are within a single AS. R1 and R7 are
to route reflector clients R1(M1) and R7(M4), and the route reflector BGP router-reflector clients, and R3 is a Route Reflector. The
R3(M2 & M3) respectively. For inter-AS scenario, such message can be PCInitiate message should be sent all of the BGP routers that need to
sent directly to the ASBR router to build EBGP session. be configured R1 (M3), R3 (M2 & M3), and R7 (M4).
PCInitiate message creates an auto-configuration function for these PCInitiate message creates an auto-configuration function for these
BGP peers providing the indicated Peer AS and the Local/Peer IP BGP peers providing the indicated Peer AS and the Local/Peer IP
Address. Address.
When PCC receives the BPI and CCI object (with the R bit set to 0 in When PCC receives the BPI and CCI object (with the R bit set to 0 in
SRP object) in PCInitiate message, the PCC should try to establish SRP object) in PCInitiate message, the PCC should try to establish
the BGP session with the indicated Peer AS and Local/Peer IP address. the BGP session with the indicated Peer AS and Local/Peer IP address.
When PCC creates successfully the BGP session that is indicated by When PCC creates successfully the BGP session that is indicated by
skipping to change at page 9, line 30 skipping to change at page 10, line 4
+-------------------------------------------------------------+ +-------------------------------------------------------------+
|M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) | |M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) |
|M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)| |M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)|
+-------------------------------------------------------------+ +-------------------------------------------------------------+
If the PCC cannot establish the BGP session that required by this If the PCC cannot establish the BGP session that required by this
object, it should report the error values via PCErr message with the object, it should report the error values via PCErr message with the
newly defined error type(Error-type=TBD6) and error value(Error- newly defined error type(Error-type=TBD6) and error value(Error-
value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be
reached), which is indicated in Section 11 reached), which is indicated in Section 11
If the Local IP Address or Peer IP Address within BPI object is used If the Local IP Address or Peer IP Address within BPI object is used
in other existing BGP sessions, the PCC should report such error in other existing BGP sessions, the PCC should report such error
situation via PCErr message with Err-type=TBD6 and error value(Error- situation via PCErr message with Err-type=TBD6 and error value(Error-
value=TBD9, Local IP is in use; Error-value=TBD10, Remote IP is in value=TBD9, Local IP is in use; Error-value=TBD10, Remote IP is in
use). use).
6.2. Explicit Route Establish Procedures 6.2. Explicit Route Establish Procedures
The detail procedures for the explicit route establishment procedures The explicit route establishment procedures can be used to install a
is shown below, using PCInitiate and PCRpt message pair. route via PCE in the PCC/BGP Peer, using PCInitiate and PCRpt message
pair. Although the BGP policy might redistribute the routes
installed by explicit route, the PCE-BGP implementation needs to
prohibit the redistribution of the explicit route. PCE explicit
routes operate similar to static routes installed by network
management protocols (netconf/restconf) but the routes are associated
with the PCE routing module. Explicit route installations (like NM
static routes) must carefully install and uninstall static routes in
an specific order so that the pathways are established without loops.
The PCInitiate message should be sent to the on-path routers The PCInitiate message should be sent to the on-path routers
respectively. In the example, for explicit route from R1 to R7, the respectively. In the example, for explicit route from R1 to R7, the
PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as
shown in Figure 2. For explicit route from R7 to R1, the PCInitiate shown in Figure 2. For explicit route from R7 to R1, the PCInitiate
message should be sent to R7(M1), R4(M2) and R2(M3), as shown in message should be sent to R7(M1), R4(M2) and R2(M3), as shown in
Figure 3. Figure 3.
When PCC receives the EPR and the CCI object (with the R bit set to 0 When PCC receives the EPR and the CCI object (with the R bit set to 0
in SRP object) in PCInitiate message, the PCC should install the in SRP object) in PCInitiate message, the PCC should install the
 End of changes. 9 change blocks. 
37 lines changed or deleted 56 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/