draft-ietf-pce-pcep-extension-native-ip-07.txt   draft-ietf-pce-pcep-extension-native-ip-08.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: March 15, 2021 S. Fang Expires: March 18, 2021 S. Fang
R. Tan R. Tan
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
C. Zhu C. Zhu
ZTE Corporation ZTE Corporation
September 11, 2020 September 14, 2020
PCEP Extension for Native IP Network PCEP Extension for Native IP Network
draft-ietf-pce-pcep-extension-native-ip-07 draft-ietf-pce-pcep-extension-native-ip-08
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 of CCDR in native IP is described in [RFC8735] and
[I-D.ietf-teas-pce-native-ip]. This draft describes the key [I-D.ietf-teas-pce-native-ip]. This draft describes the key
information that is transferred between Path Computation Element information that is transferred between Path Computation Element
(PCE) and Path Computation Clients (PCC) to accomplish the End to End (PCE) and Path Computation Clients (PCC) to accomplish the End to End
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 March 15, 2021. This Internet-Draft will expire on March 18, 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 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . . . 3 4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . . . 3
5. PCE-Initiated Native IP TE Procedures . . . . . . . . . . . . 4 5. PCE-Initiated Native IP TE Procedures . . . . . . . . . . . . 4
6. New Objects Extension . . . . . . . . . . . . . . . . . . . . 4 6. New Objects Extension . . . . . . . . . . . . . . . . . . . . 4
7. Objects Formats . . . . . . . . . . . . . . . . . . . . . . . 4 7. Objects Formats . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 5 7.1. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 5
7.2. Explicit Peer Route Object . . . . . . . . . . . . . . . 9 7.2. Explicit Peer Route Object . . . . . . . . . . . . . . . 9
7.3. Peer Prefix Association Object . . . . . . . . . . . . . 12 7.3. Peer Prefix Association Object . . . . . . . . . . . . . 13
8. New Error-Types and Error-Values Defined . . . . . . . . . . 14 8. New Error-Types and Error-Values Defined . . . . . . . . . . 16
9. Management Consideration . . . . . . . . . . . . . . . . . . 15 9. Management Consideration . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11.1. PCEP Object Types . . . . . . . . . . . . . . . . . . . 16 11.1. PCEP Object Types . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
13. Normative References . . . . . . . . . . . . . . . . . . . . 16 13. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Traditionally, Multiprotocol Label Switching Traffic Engineering Traditionally, Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) traffic assurance requires the corresponding network (MPLS-TE) requires the corresponding network devices support
devices support Multiprotocol Label Switching (MPLS) or the complex Multiprotocol Label Switching (MPLS) or Resource ReSerVation Protocol
Resource ReSerVation Protocol (RSVP)/Label Distribution Protocol (RSVP)/Label Distribution Protocol (LDP) technologies to assure the
(LDP) /Segment Routing etc. technologies to assure the End-to-End End-to-End (E2E) traffic performance. But in native IP network,
(E2E) traffic performance. But in native IP network, there will be there will be no such signaling protocol to synchronize the action
no such signaling protocol to synchronize the action among different among different network devices. It is necessary to use the central
network devices. It is necessary to use the central control mode control mode that described in [RFC8283] to correlate the forwarding
that described in [RFC8283] to correlate the forwarding behavior behavior among different network devices. Draft
among different network devices. Draft [I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip] describes the architecture and solution
describes the architecture and solution philosophy for the E2E philosophy for the E2E traffic assurance in Native IP network via
traffic assurance in Native IP network via Dual/Multi Border Gateway Dual/Multi Border Gateway Protocol (BGP) solution. This draft
Protocol (BGP) solution. This draft describes the corresponding Path describes the corresponding Path Computation Element Communication
Computation Element Communication Protocol (PCEP) extensions to Protocol (PCEP) extensions to transfer the key information about peer
transfer the key information about peer address list, peer prefix address list, peer prefix association and the explicit peer route on
association and the explicit peer route on on-path router. on-path routers.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
.This document uses the following terms defined in [RFC5440]: PCE, This document uses the following terms defined in [RFC5440]: PCE,
PCEP PCEP
The following terms are defined in this document: The following terms are defined in this document:
o CCDR: Central Control Dynamic Routing o CCDR: Central Control Dynamic Routing
o E2E: End to End o E2E: End to End
o BPI: BGP Peer Info o BPI: BGP Peer Info
skipping to change at page 4, line 21 skipping to change at page 4, line 21
5. PCE-Initiated Native IP TE Procedures 5. PCE-Initiated Native IP TE Procedures
PCE-Initated Native IP TE solution utilizing the existing PCE LSP PCE-Initated Native IP TE solution utilizing the existing PCE LSP
Initate Request message(PCInitiate)[RFC8281], PCE Report Initate Request message(PCInitiate)[RFC8281], PCE Report
message(PCRpt) [RFC8281]and PCE Update message(PCUpd)[RFC8281] to message(PCRpt) [RFC8281]and PCE Update message(PCUpd)[RFC8281] to
accomplish the multi BGP sessions establishment, end to end TE path accomplish the multi BGP sessions establishment, end to end TE path
deployment, and route prefixes advertisement among different BGP deployment, and route prefixes advertisement among different BGP
sessions. sessions.
There is no label switch path within the Native IP environment, but There is no label switch path within the Native IP environment, but
there exist the end to end forwarding path that assigned to the there exist end to end forwarding path that assigned to the priority
priority traffic. Such path can be identified by the PLSP-ID that traffic. Such path can be identified by the PLSP-ID that defined in
defined in Label Switched Path(LSP) object [RFC8231]_. _The PLSP-ID Label Switched Path(LSP) object [RFC8231]_. _The PLSP-ID is assigned
is assigned by each PCC, based on the Symbolic Path Name TLV in the by each PCC, based on the Symbolic Path Name TLV in the LSP object
LSP object that from PCInitiate message. The Symbolic Path Name TLV that from PCInitiate message. The Symbolic Path Name TLV can be used
can be used to identify the end to end TE path in Native IP to identify the end to end TE path in Native IP environment. The
environment. The association of Symbolic Path Name and each PLSP-ID association of Symbolic Path Name and each PLSP-ID in every PCC
in every PCC assures the TE policies are assigned end to end in the assures the TE policies are assigned end to end in the network.
network.
6. New Objects Extension 6. New Objects Extension
Three new objects are defined in this draft: Three new objects are defined in this draft:
o BPI Object: BGP Peer Info Object, used to indicate the PCC which o BPI Object: BGP Peer Info Object, used to indicate the PCC which
peer it should be peered with dynamically. BGP peer it should be peered with dynamically.
o PPA Object: Peer Prefix Association Object, used to indicate the
PCC which prefixes should be advertised via the corresponding
peer.
o EPR Object: Explicit Peer Route object, used to indicate the PCC o EPR Object: Explicit Peer Route object, used to indicate the PCC
which route should be taken into to arrive to the peer. which route should be taken into to arrive to the peer.
o PPA Object: Peer Prefix Association Object, used to indicate the
PCC which prefixes should be advertised via the corresponding BGP
peer.
7. Objects Formats 7. Objects Formats
Each extension object takes the similar format, that is to say, it Each extension object takes the similar format, that is to say, it
began with the common object header defined in [RFC5440] as the began with the common object header defined in [RFC5440] as the
following: following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length(bytes) | | Object-Class | OT |Res|P|I| Object Length(bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Object body) | | (Object body) |
// // // //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PCEP Object Format Figure 2: PCEP Object Format
Different object-class, object type and the corresponding object body Different object-class, object type and the corresponding object body
is defined separately in the following section. is defined separately in the following sections.
7.1. BGP Peer Info Object 7.1. BGP Peer Info Object
The BGP Peer Info object is used to specify the information about the The BGP Peer Info object is used to specify the information about the
peer that the PCC should establish the BGP relationship with. This peer that the PCC should establish the BGP relationship with. This
object should only be included and sent to the head and end router of object should only be included and sent to the head and end router of
the E2E path in case there is no Route Reflection (RR) involved. If the E2E path in case there is no Route Reflection (RR) involved. If
the RR is used between the head and end routers, then such the RR is used between the head and end routers, then such
information should be sent to head router, RR and end router information should be sent to head router, RR and end router
respectively. respectively.
skipping to change at page 8, line 4 skipping to change at page 7, line 25
peer with the local router. When Object-Type is 1, length is 4 peer with the local router. When Object-Type is 1, length is 4
bytes; when Object-Type is 2, length is 16 bytes; bytes; when Object-Type is 2, length is 16 bytes;
Additional TLVs: TLVs that associated with this object, can be used Additional TLVs: TLVs that associated with this object, can be used
to convey other necessary information for dynamic BGP session to convey other necessary information for dynamic BGP session
establishment. Its definition is out of the current document. establishment. Its definition is out of the current document.
The detail procedures for the usage of this object is shown The detail procedures for the usage of this object is shown
below(PCInitiate and PCRpt message pair, other message pairs are below(PCInitiate and PCRpt message pair, other message pairs are
similar) similar)
M2 PCInitiate Message: M3 PCInitiate Message:
PLSP-ID=X1(Symbolic Path Name=Class A) PLSP-ID=X1(Symbolic Path Name=Class A)
BPI Object(Local IP=R3_A, Peer IP=R1_A) BPI Object(Local IP=R3_A, Peer IP=R7_A)
M2-R PCRpt Message: M3-R PCRpt Message: The PCInitiate message should be sent to R1(M1), R3(M2 & M3) and
PLSP-ID=X1 PLSP-ID=X1 R7(M4) when R3 acts as RR.
BPI Object(Local IP=R3_A, Peer IP=R1_A) BPI Object(Local IP=R3_A, Peer IP=R7_A)
^ ^
| |
| |
| |
| |
| +------------------+ |
M1 PCInitiate Message: + +----------+ PCE +-----------+ + M4 PCInitiate Message:
PLSP-ID=X1(Symbolic Path Name=Class A) | | | +--------^---------+ | | | PLSP-ID=X7(Symbolic Path Name=Class A)
BPI Object(Local IP=R1_A, Peer IP=R3_A) | | | | | | | BPI Object(Local IP=R7_A,Peer IP=R3_A)
| | +----------------------------+ | |
| | | | |
M1-R PCRpt Message: ^ | | | | | ^M4-R PCRpt Message:
PLSP-ID=X1 | | | +v-+ | | | PLSP-ID=X7
BPI Object(Local IP=R1_A, Peer IP=R3_A | | +------------------+R3+-------------------+ | | BPI Object(Local IP=R3_A, Peer IP=R1_A) )
| | | +--+ | | |
| | | | | |
| | +v-+ +--+ +--+ +-v+ | |
+ v |R1+----------+R5+----------+R6+---------+R7| v +
++-+ +--+ +--+ +-++
| |
| |
| +--+ +--+ |
+------------+R2+----------+R4+-----------+
Figure 5: BGP Peer Establishment Procedures(R3 act as RR) M2 PCInitiate Message: M3 PCInitiate Message:
PLSP-ID=X3(Symbolic Path Name=Class A) PLSP-ID=X3(Symbolic Path Name=Class A)
BPI Object(Local IP=R3_A, Peer IP=R1_A) BPI Object(Local IP=R3_A, Peer IP=R7_A)
M2-R PCRpt Message: M3-R PCRpt Message:
PLSP-ID=X3 PLSP-ID=X3
BPI Object(Local IP=R3_A, Peer IP=R1_A) BPI Object(Local IP=R3_A, Peer IP=R7_A)
^ ^
| |
+------------------------------------^------------------+
|
|
|
| +------------------+
M1 PCInitiate Message: +----------+ PCE +-----------+
PLSP-ID=X1(Symbolic Path Name=Class A) | | +--------^---------+ |
BPI Object(Local IP=R1_A, Peer IP=R3_A) | | | |
| | | |
<------+ +-------------+ +---+
M1-R PCRpt Message: | | | |
PLSP-ID=X1 | +v-+ | |
BPI Object(Local IP=R1_A, Peer IP=R3_A +------------------+R3+-------------------+ | )
| +--+ | |
| | |
+v-+ +--+ +--+ +-v+ |
|R1+----------+R5+----------+R6+---------+R7| |
++-+ +--+ +--+ +-++ |
M4 PCInitiate Message: | | |
PLSP-ID=X7(Symbolic Path Name=Class A) | | |
BPI Object(Local IP=R7_A,Peer IP=R3_A) | +--+ +--+ | |
+------------+R2+----------+R4+-----------+ |
|
M4-R PCRpt Message: |
PLSP-ID=X7 <----------------------------------------------------+
BPI Object(Local IP=R3_A, Peer IP=R1_A)
Figure 5: BGP Peer Establishment Procedures(R3 act as RR)
When PCC receives this object with the R bit set to 0 in SRP object When PCC receives this object with the R bit set to 0 in SRP object
in PCInitiate message, the PCC should try to establish the BGP in PCInitiate message, the PCC should try to establish the BGP
session with the indicated Peer AS and Local/Peer IP address. 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
the associated information, it should report the result via the PCRpt the associated information, it should report the result via the PCRpt
messages, with this object included, and the corresponding SRP and messages, with this object included, and the corresponding SRP and
LSP object. LSP object.
skipping to change at page 11, line 4 skipping to change at page 11, line 8
Resv.: Bit reserved for future use. Resv.: Bit reserved for future use.
Peer Address: To indicate the peer address. Peer Address: To indicate the peer address.
Next Hop Address to the Peer: To indicate the next hop address to the Next Hop Address to the Peer: To indicate the next hop address to the
corresponding peer. corresponding peer.
The detail procedures for the usage of this object is shown The detail procedures for the usage of this object is shown
below(PCInitiate and PCRpt message pair, other message pairs are below(PCInitiate and PCRpt message pair, other message pairs are
similar) similar)
For explicit route from R1 to R7, the PCIniitate message should be
sent to R1(M1), R2(M2) and R4(M3).
+------------------+ +------------------+
M4 PCInitiate Message: + +----------+ PCE +-----------+ + M1 PCInitiate Message: M1 PCInitiate Message: +----------+ PCE +-----------+
PLSP-ID=X1(Symbolic Path Name=Class A) | | +----^---^---^-----+ | | PLSP-ID=X7(Symbolic Path Name=Class A) PLSP-ID=X1(Symbolic Path Name=Class A) | +----^---^---^-----+ |
EPR Object(Peer Address=R7_A | | | | | | | EPR Object(Peer Address=R1_A EPR Object(Peer Address=R7_A | | | | |
Next Hop=R2_A) | | | | | | | Next Hop=R4_A) Next Hop=R2_A) | | | | |
| | | | | | | | | | | |
M4-R PCRpt Message: ^ | | | | | | | ^ M1-R PCRpt Message: M1-R PCRpt Message: <---------------+ | | | |
PLSP-ID=X1 | | | | +v-+ | | | | PLSP-ID=X7 PLSP-ID=X1 | | +v-+ | |
EPR Object(Peer Address=R7_A | | +------------- ----+R3+-------------------+ | | EPR Object(Peer Address=R1_A ) EPR Object(Peer Address=R7_A +------------+ +---+R3+-------------------+ )
Next Hop=R2_A) | | | | +--+ | | | | Next Hop=R4_A) Next Hop=R2_A) | | +--+ | |
| | | | | | | | | | | |
| | +v-+ +--+ | | +--+ +-v+ | | +v-+ +--+ | | +--+ +-v+
+ v |R1+------+R5+- -----------------+R6+----+R7| v + |R1+------+R5++ +----------------+R6+----+R7|
++-+ +--+ | | +--+ +-++ ++-+ +--+ | | +--+ +-++
| | | | | | | |
| +---+ +---+ | M2 PCInitiate Message | +---+ +---+ |
| +v-+ +v-+ | PLSP-ID=X2(Symbolic Path Name=Class A) | +v-+ | | +v-+ |
+----------+R2+- ---------+R4+-----------+ EPR Object(Peer Address=R7_A +----------+R2+-+ +--------+R4+-----------+
Next Hop=R4_A) | |
| |
M2-R PCRpt Message | |
PLSP-ID=X2(Symbolic Path Name=Class A) <----------------------+ |
EPR Object(Peer Address=R7_A |
Next Hop=R4_A) |
v
M3 PCInitiate Message
PLSP-ID=X4(Symbolic Path Name=Class A)
EPR Object(Peer Address=R7_A
Next Hop=R7_A)
M3 PCInitiate Message M2 PCInitiate Message M3-R PCRpt Message
PLSP-ID=X2(Symbolic Path Name=Class A) PLSP-ID=X4(Symbolic Path Name=Class A) PLSP-ID=X4(Symbolic Path Name=Class A)
EPR Object(Peer Address=R1_A EPR Object(Peer Address=R1_A EPR Object(Peer Address=R7_A
Next Hop=R1_A) Next Hop=R2_A) Next Hop=R7_A)
M3-R PCRpt Message M2-R PCRpt Message Figure 8: Explicit Route Establish Procedures(From R1 to R7)
PLSP-ID=X2(Symbolic Path Name=Class A) PLSP-ID=X4(Symbolic Path Name=Class A)
EPR Object(Peer Address=R1_A EPR Object(Peer Address=R1_A
Next Hop=R1_A) Next Hop=R2_A)
Figure 8: Explicit Route Establish Procedures(From R1 to R7) For explicit route from R7 to R1, the PCIniitate message should be
sent to R7(M1), R4(M2) and R2(M3).
-------------------------------------------------------------------------+
| |
v +------------------+ |
M1 PCInitiate Message: +----------+ PCE +-----+-----+
PLSP-ID=X7(Symbolic Path Name=Class A) | +----^---^---^-----+ |
EPR Object(Peer Address=R1_A | | | | |
Next Hop=R4_A) | | | | |
| | | | |
M1-R PCRpt Message: | | | | |
PLSP-ID=X7 | | +v-+ | |
EPR Object(Peer Address=R1_A +------------+ +---+R3+-------------------+ )
Next Hop=R4_A) | | +--+ | |
| | | |
+v-+ +--+ | | +--+ +-v+
|R1+------+R5++ +----------------+R6+----+R7|
++-+ +--+ | | +--+ +-++
| | | |
M3 PCInitiate Message | +---+ +---+ |
PLSP-ID=X2(Symbolic Path Name=Class A) | +v-+ | | +v-+ |
EPR Object(Peer Address=R1_A +----------+R2+-+ +--------+R4+-----------+
Next Hop=R1_A) | |
| |
M3-R PCRpt Message | |
PLSP-ID=X2(Symbolic Path Name=Class A) <----------------------+ |
EPR Object(Peer Address=R1_A |
Next Hop=R1_A) |
v
M2 PCInitiate Message
PLSP-ID=X4(Symbolic Path Name=Class A)
EPR Object(Peer Address=R1_A
Next Hop=R2_A)
M2-R PCRpt Message
PLSP-ID=X4(Symbolic Path Name=Class A)
EPR Object(Peer Address=R1_A
Next Hop=R2_A)
Figure 9: Explicit Route Establish Procedures(From R7 to R1)
When PCC receives this object with the R bit set to 0 in SRP object When PCC receives this object with the R bit set to 0 in SRP object
in PCInitiate message, the PCC should install the explicit route to in PCInitiate message, the PCC should install the explicit route to
the the peer. the the peer.
When PCC install successfully the explicit route to the peer, it When PCC install successfully the explicit route to the peer, it
should report the result via the PCRpt messages, with this object should report the result via the PCRpt messages, with this object
included, and the corresponding SRP and LSP object. included, and the corresponding SRP and LSP object.
When PCC receives this object with the R bit set to 1 in SRP object When PCC receives this object with the R bit set to 1 in SRP object
skipping to change at page 12, line 41 skipping to change at page 13, line 49
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IPv4 Address | | Peer IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IPv4 Prefix subobjects // // IPv4 Prefix subobjects //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Peer Prefix Association Object Body Format for IPv4 Figure 10: Peer Prefix Association Object Body Format for IPv4
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IPv6 Address | | Peer IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IPv6 Prefix subobjects // // IPv6 Prefix subobjects //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Peer Prefix Association Object Body Format for IPv6 Figure 11: Peer Prefix Association Object Body Format for IPv6
Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that
the associated prefixes will be sent to. the associated prefixes will be sent to.
IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in
[RFC3209], identify the prefixes that will be sent to the peer that [RFC3209], identify the prefixes that will be sent to the peer that
identified by Peer IPv4 Address List. identified by Peer IPv4 Address List.
Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that
the associated prefixes will be sent to. the associated prefixes will be sent to.
IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in
[RFC3209], identify the prefixes that will be sent to the peer that [RFC3209], identify the prefixes that will be sent to the peer that
identified by Peer IPv6 Address List. identified by Peer IPv6 Address List.
The detail procedures for the usage of this object is shown The detail procedures for the usage of this object is shown
below(PCInitiate and PCRpt message pair, other message pairs are below(PCInitiate and PCRpt message pair, other message pairs are
similar) similar)
+------------------+ The PCInitiate message should be sent to R1(M1) and R7(M2)
M1 PCInitiate Message: + +----------+ PCE +-----------+ + M2 PCInitiate Message: respectively.
PLSP+ID=X1(Symbolic Path Name=Class A) | | +--------^---------+ | | PLSP+ID=X7(Symbolic Path Name=Class A)
PPA Object(Peer IP=R7_A, Prefix=1_A) | | | | | PPA Object(Peer IP=R1_A, Prefix=7_A) M2 PCInitiate Message:
| | | | | PLSP-ID=X7(Symbolic Path Name=Class A)
| | | | | PPA Object(Peer IP=R1_A, Prefix=7_A)
M1-R PCRpt Message: ^ | | | | | ^ M2-R PCRpt Message:
PLSP+ID=X1 | | | +v-+ | | | PLSP+ID=X7 <-----+
PPA Object(Peer IP=R7_A,Prefix=1_A) | | +------------------+R3+-------------------+ | | PPA Object(Peer IP=R1_A, Prefix=7_A) ) M2-R PCRpt Message: |
| | | +--+ | | | PLSP-ID=X7 |
| | | | | | PPA Object(Peer IP=R1_A, Prefix=7_A) |
| | +v-+ +--+ +--+ +-v+ | | |
+ v |R1+----------+R5+----------+R6+---------+R7| v + |
|
+------------------+ |
M1 PCInitiate Message: +----------+ PCE +-----------+ |
PLSP-ID=X1(Symbolic Path Name=Class A) | +------------------+ | |
PPA Object(Peer IP=R7_A, Prefix=1_A) | | |
| | |
<----------+ +---+
M1-R PCRpt Message: | |
PLSP-ID=X1 | +--+ |
PPA Object(Peer IP=R7_A,Prefix=1_A) +------------------+R3+-------------------+ )
| +--+ |
| |
+v-+ +--+ +--+ +-v+
|R1+----------+R5+----------+R6+---------+R7|
++-+ +--+ +--+ +-++ ++-+ +--+ +--+ +-++
| | | |
| | | |
| +--+ +--+ | | +--+ +--+ |
+------------+R2+----------+R4+-----------+ +------------+R2+----------+R4+-----------+
Figure 11: BGP Prefix Advertisement Procedures Figure 12: BGP Prefix Advertisement Procedures
When PCC receives this object with the R bit set to 0 in SRP object When PCC receives this object with the R bit set to 0 in SRP object
in PCInitiate message, the PCC should send the prefixes indicated in in PCInitiate message, the PCC should send the prefixes indicated in
this object to the appointed BGP peer. this object to the appointed BGP peer.
When PCC sends successfully the prefixes to the appointed BGP peer, When PCC sends successfully the prefixes to the appointed BGP peer,
it should report the result via the PCRpt messages, with this object it should report the result via the PCRpt messages, with this object
included, and the corresponding SRP and LSP object. included, and the corresponding SRP and LSP object.
When PCC receives this object with the R bit set to 1 in SRP object When PCC receives this object with the R bit set to 1 in SRP object
skipping to change at page 15, line 31 skipping to change at page 17, line 31
| | | 5: PAL/EPR Object AF mismatch| | | | 5: PAL/EPR Object AF mismatch|
+------------+---------------+------------------------------+ +------------+---------------+------------------------------+
| | | 6: PPA/EPR object AF mismatch| | | | 6: PPA/EPR object AF mismatch|
+------------+---------------+------------------------------+ +------------+---------------+------------------------------+
| | | 7: | | | | 7: |
+------------+---------------+------------------------------+ +------------+---------------+------------------------------+
| | | 8: | | | | 8: |
+------------+---------------+------------------------------+ +------------+---------------+------------------------------+
| | | 9: | | | | 9: |
+------------+---------------+------------------------------+ +------------+---------------+------------------------------+
Figure 12: Newly defined Error-Type and Error-Value Figure 13: Newly defined Error-Type and Error-Value
9. Management Consideration 9. Management Consideration
The information transferred in this draft is mainly used for the The information transferred in this draft is mainly used for the
light weight BGP session setup, the prefix distribution and the light weight BGP session setup, explicit route deployment and the
explicit route deployment. The planning, allocation and distribution prefix distribution. The planning, allocation and distribution of
of the peer addresses within IGP should be accomplished in advanced the peer addresses within IGP should be accomplished in advanced and
and they are out of the scope of this draft. they are out of the scope of this draft.
[RFC8232] describes the state synchronization procedure between
stateful PCE and PCC. The communication of PCE and PCC described in
this draft should also follow this procedures, treat the three newly
defined objects that associated with the same symbolic path name as
the attribute of the same path in the LSP-DB.
When PCE detects one or some of the PCCs are out of control, it
should recompute and redeploy the traffic engineering path for native
IP on the active PCCs. When PCC detects that it is out of control of
the PCE, it should clear the information that initiated by the PCE.
The PCE should assures the avoidance of possible transient loop in
such node failure when it deploy the explicit peer route on the PCCs.
10. Security Considerations 10. Security Considerations
Service provider should consider the protection of PCE and their Service provider should consider the protection of PCE and their
communication with the underlay devices, which is described in communication with the underlay devices, which is described in
document [RFC5440] and [RFC8253] document [RFC5440] and [RFC8253]
11. IANA Considerations 11. IANA Considerations
11.1. PCEP Object Types 11.1. PCEP Object Types
IANA is requested to allocate new registry for the PCEP Object Type: IANA is requested to allocate new registry for the PCEP Object Type:
Object-Type Value Name Reference Object-Type Value Name Reference
TBD BGP Peer Info This document TBD BGP Peer Info This document
Object-Type Object-Type
1: IPv4 address 1: IPv4 address
2: IPv6 address 2: IPv6 address
skipping to change at page 16, line 14 skipping to change at page 18, line 23
11.1. PCEP Object Types 11.1. PCEP Object Types
IANA is requested to allocate new registry for the PCEP Object Type: IANA is requested to allocate new registry for the PCEP Object Type:
Object-Type Value Name Reference Object-Type Value Name Reference
TBD BGP Peer Info This document TBD BGP Peer Info This document
Object-Type Object-Type
1: IPv4 address 1: IPv4 address
2: IPv6 address 2: IPv6 address
TBD Peer Prefix Association This document TBD Explicit Peer Route This document
Object-Type Object-Type
1: IPv4 address 1: IPv4 address
2: IPv6 address 2: IPv6 address
TBD Explicit Peer Route This document TBD Peer Prefix Association This document
Object-Type Object-Type
1: IPv4 address 1: IPv4 address
2: IPv6 address 2: IPv6 address
12. Acknowledgement 12. Acknowledgement
Thanks Dhruv Dhody, Mike Koldychev, Siva Sivabalan, Adam Simpson for Thanks Dhruv Dhody, Mike Koldychev, Siva Sivabalan, Adam Simpson for
his valuable suggestions and comments. his valuable suggestions and comments.
13. Normative References 13. Normative References
skipping to change at page 17, line 5 skipping to change at page 19, line 16
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
 End of changes. 30 change blocks. 
121 lines changed or deleted 215 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/