draft-ietf-pce-pcep-extension-native-ip-14.txt   draft-ietf-pce-pcep-extension-native-ip-15.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: December 9, 2021 Yandex LLC Expires: 28 January 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
June 7, 2021 27 July 2021
PCEP Extension for Native IP Network PCEP Extension for Native IP Network
draft-ietf-pce-pcep-extension-native-ip-14 draft-ietf-pce-pcep-extension-native-ip-15
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 December 9, 2021. This Internet-Draft will expire on 28 January 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
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
skipping to change at page 2, line 38 skipping to change at page 2, line 37
6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 12 6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 12
7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13
7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 14 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 14
7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17
7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 19 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 19
8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 8. End to End Path Protection . . . . . . . . . . . . . . . . . 21
9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21
10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 11. New Error-Types and Error-Values Defined . . . . . . . . . . 22
12. Deployment Considerations . . . . . . . . . . . . . . . . . . 22 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 23 14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 24
14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 24 14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 24
14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 24 14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 24
14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25
15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 25 15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
17. Normative References . . . . . . . . . . . . . . . . . . . . 25 17. Normative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 * CCDR: Central Control Dynamic Routing
o E2E: End to End * E2E: End to End
o BPI: BGP Peer Info * BPI: BGP Peer Info
o EPR: Explicit Peer Route * EPR: Explicit Peer Route
o PPA: Peer Prefix Advertisement * PPA: Peer Prefix Advertisement
o QoS: Quality of Service * QoS: Quality of Service
4. Capability Advertisemnt 4. Capability Advertisemnt
4.1. Open message 4.1. Open message
During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of Native IP extensions. advertise their support of Native IP extensions.
This document defines a new Path Setup Type (PST) [RFC8408] for This document defines a new Path Setup Type (PST) [RFC8408] for
Native-IP, as follows: Native-IP, as follows:
o PST = TBD1: Path is a Native IP path as per [RFC8821]. * PST = TBD1: Path is a Native IP path as per [RFC8821].
A PCEP speaker MUST indicate its support of the function described in A PCEP speaker MUST indicate its support of the function described in
this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
object with this new PST included in the PST list. object with this new PST included in the PST list.
[I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC-
CAPABILITY sub-TLV to exchange information about their PCECC CAPABILITY sub-TLV to exchange information about their PCECC
capability. A new flag is defined in PCECC-CAPABILITY sub-TLV for capability. A new flag is defined in PCECC-CAPABILITY sub-TLV for
Native IP: Native IP:
N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP
speaker, it indicates that the PCEP speaker is capable for TE in speaker, it indicates that the PCEP speaker is capable for TE in
Native IP network as specified in this document. The flag MUST be Native IP network as specified in this document. The flag MUST be
set by both the PCC and PCE in order to support this extension. set by both the PCC and PCE in order to support this extension.
If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
the newly defined path setup type, but without the N bit set in the newly defined path setup type, but without the N bit set in
PCECC-CAPABILITY sub-TLV, it MUST: PCECC-CAPABILITY sub-TLV, it MUST:
o Send a PCErr message with Error-Type=10(Reception of an invalid * Send a PCErr message with Error-Type=10(Reception of an invalid
object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is
not set). not set).
o Terminate the PCEP session * Terminate the PCEP session
5. PCEP messages 5. PCEP messages
PCECC Native IP TE solution utilizing the existing PCE LSP Initate PCECC Native IP TE solution utilizing the existing PCE LSP Initate
Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt) Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt)
[RFC8281] to accomplish the multi BGP sessions establishment, E2E TE [RFC8281] to accomplish the multi BGP sessions establishment, E2E TE
path deployment, and route prefixes advertisement among different BGP path deployment, and route prefixes advertisement among different BGP
sessions. A new PST for Native-IP is used to indicate the path setup sessions. A new PST for Native-IP is used to indicate the path setup
based on TE in Native IP networks. based on TE in Native IP networks.
The extended PCInitiate message described in The extended PCInitiate message described in
[I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download
or cleanup central controller's instructions (CCIs). or cleanup central controller's instructions (CCIs).
[I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object
called CCI for the encoding of central controller's instructions. called CCI for the encoding of central controller's instructions.
This document specify a new CCI object-type for Native IP. The PCEP This document specify a new CCI object-type for Native IP. The PCEP
messages are extended in this document to handle the PCECC operations messages are extended in this document to handle the PCECC operations
for Native IP. Three new PCEP Objects (BGP Peer Info (BPI) Object, for Native IP. Three new PCEP Objects (BGP Peer Info (BPI) Object,
Explicit Peer Route (EPR) Object and Peer Prefix Advertisement (PPA) Explicit Peer Route (EPR) Object and Peer Prefix Advertisement (PPA)
Object) are defined in this document. Refer to (Section 7) for Object) are defined in this document. Refer toSection 7 for detail
detail object definitions. object definitions.
5.1. The PCInitiate message 5.1. The PCInitiate message
The PCInitiate Message defined in [RFC8281] and extended in The PCInitiate Message defined in [RFC8281] and extended in
[I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended
to support Native-IP CCI. to support Native-IP CCI.
The format of the extended PCInitiate message is as follows: The format of the extended PCInitiate message is as follows:
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
skipping to change at page 7, line 47 skipping to change at page 7, line 47
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 is The procedures for establishing the BGP session between two peers by
shown below, using the PCInitiate and PCRpt message pair. using the PCInitiate and PCRpt message pair is shown below.
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 route reflector(RR). In the example in Figure 1, it should be and/or route reflector(RR).
sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR.
In the example in Figure 1, if the router R1 and R7 are within one AS
and R3 acts as the route reflector, PCInitiate message should be sent
to route reflector clients R1(M1) and R7(M4), and the route reflector
R3(M2 & M3) respectively. For inter-AS scenario, such message can be
sent directly to the ASBR router to build EBGP session.
PCInitiate message creates an auto-configuration function for these
BGP peers providing the indicated Peer AS and the Local/Peer IP
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
the associated information, it should report the result via the PCRpt the associated information, it should report the result via the PCRpt
messages, with BPI object and the corresponding SRP and CCI object messages, with BPI object and the corresponding SRP and CCI object
included. included.
skipping to change at page 11, line 45 skipping to change at page 11, line 45
+------------------------------------------------------------------+ +------------------------------------------------------------------+
|M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | |M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) |
|M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)| |M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)|
+------------------------------------------------------------------+ +------------------------------------------------------------------+
In order to avoid the transient loop during the deploy of explicit In order to avoid the transient loop during the deploy of explicit
peer route, the EPR object should be sent to the PCCs in the reverse peer route, the EPR object should be sent to the PCCs in the reverse
order of the E2E path. To remove the explicit peer route, the EPR order of the E2E path. To remove the explicit peer route, the EPR
object should be sent to the PCCs in the same order of E2E path. object should be sent to the PCCs in the same order of E2E path.
Upon the error occurs, the PCC SHOULD send the corresponding error To accomplish ECMP effects, the PCE can send multiple EPR objects to
via PCErr message, with an error information (Error-type=TBD6, Error- the same node, with the same route priority and peer address value
but different next hop addresses.
The PCC should verify that the next hop address is reachable. Upon
the error occurs, the PCC SHOULD send the corresponding error via
PCErr message, with an error information (Error-type=TBD6, Error-
value=TBD12, Explicit Peer Route Error) that defined in Section 11. value=TBD12, Explicit Peer Route Error) that defined in Section 11.
When the peer info is not the same as the peer info that indicated in When the peer info is not the same as the peer info that indicated in
BPI object in PCC for the same path that is identified by Symbolic BPI object in PCC for the same path that is identified by Symbolic
Path Name TLV, an error (Error-type=TBD6, Error-value=17, EPR/BPI Path Name TLV, an error (Error-type=TBD6, Error-value=17, EPR/BPI
Peer Info mismatch) should be reported via the PCErr message. Peer Info mismatch) should be reported via the PCErr message.
6.3. BGP Prefix Advertisement Procedures 6.3. BGP Prefix Advertisement Procedures
The detail procedures for BGP prefix advertisement are shown below, The detail procedures for BGP prefix advertisement are shown below,
skipping to change at page 12, line 32 skipping to change at page 12, line 40
and the corresponding SRP and CCI object included. and the corresponding SRP and CCI object included.
When PCC receives the PPA and the CCI object with the R bit set to 1 When PCC receives the PPA and the CCI object with the R bit set to 1
in SRP object in PCInitiate message, the PCC should withdraw the in SRP object in PCInitiate message, the PCC should withdraw the
prefixes advertisement to the peer that indicated by this object. prefixes advertisement to the peer that indicated by this object.
When PCC withdraws successfully the prefixes that indicated by this When PCC withdraws successfully the prefixes that indicated by this
object, it should report the result via the PCRpt message, with the object, it should report the result via the PCRpt message, with the
PPA object included, and the corresponding SRP and CCI object. PPA object included, and the corresponding SRP and CCI object.
The IPv4 prefix MUST only be advertised via the IPv4 BGP session and The allowed AFI/SAFI for the IPv4 BGP session should be 1/1(IPv4
the IPv6 prefix MUST only be advertised via the IPv6 BGP session. If prefix) and the allowed AFI/SAFI for the IPv6 BGP session should be
mismatch occur, an error(Error-type=TBD6, Error-value=TBD18, BPI/PPR 2/1(IPv6 prefix). If mismatch occur, an error(Error-type=TBD6,
address family mismatch) should be reported via PCErr message. Error-value=TBD18, BPI/PPR address family mismatch) should be
reported via PCErr message.
When the peer info is not the same as the peer info that indicated in When the peer info is not the same as the peer info that indicated in
BPI object in PCC for the same path that is identified by Symbolic BPI object in PCC for the same path that is identified by Symbolic
Path Name TLV, an error (Error-type=TBD6, Error-value=TBD19, PPA/BPI Path Name TLV, an error (Error-type=TBD6, Error-value=TBD19, PPA/BPI
peer info mismatch) should be reported via the PCErr message. peer info mismatch) should be reported via the PCErr message.
+------------------+ +------------------+
+----------+ PCE +-----------+ +----------+ PCE +-----------+
| +------------------+ | | +------------------+ |
| +--+ | | +--+ |
skipping to change at page 14, line 18 skipping to change at page 14, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | | Reserved | Flags |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| | | |
// Optional TLV // // Optional TLV //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: CCI Object for Native IP Figure 5: CCI Object for Native IP
Figure 1 Figure 1
The field CC-ID is as described in The field CC-ID is as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields
are defined for CCI Object-Type TBD13 are defined for CCI Object-Type TBD13
Reserved: is set to zero while sending, ignored on receipt. Reserved: is set to zero while sending, ignored on receipt.
Flags: is used to carry any additional information pertaining to the Flags: is used to carry any additional information pertaining to the
CCI. Currently no flag bits are defined. CCI. Currently no flag bits are defined.
skipping to change at page 16, line 50 skipping to change at page 16, line 50
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional TLVs | | Additional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BGP Peer Info Object Body Format for IPv6 Figure 7: BGP Peer Info Object Body Format for IPv6
Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer.
ETTL: 1 Byte, to indicate the multi hop count for EBGP session. It ETTL: 1 Byte, to indicate the multihop count for EBGP session. It
should be 0 and ignored when Local AS and Peer AS is same. should be 0 and ignored when Local AS and Peer AS is same.
Reserved: is set to zero while sending, ignored on receipt. Reserved: is set to zero while sending, ignored on receipt.
T bit: Indicates whether the traffic that associated with the T bit: Indicates whether the traffic that associated with the
prefixes advertised via this BGP session is transported via IPinIP prefixes advertised via this BGP session is transported via IPinIP
tunnel (when T bit is set) or not (when T bit is clear). tunnel (when T bit is set) or not (when T bit is clear).
Local IP Address(4/16 Bytes): IP address of the local router, used to Local IP Address(4/16 Bytes): IP address of the local router, used to
peer with other end router. When Object-Type is 1, length is 4 peer with other end router. When Object-Type is 1, length is 4
skipping to change at page 19, line 9 skipping to change at page 19, line 9
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional TLVs | | Additional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Explicit Peer Route Object Body Format for IPv6 Figure 9: Explicit Peer Route Object Body Format for IPv6
Route Priority: 2 Bytes, The priority of this explicit route. The Route Priority: 2 Bytes, The priority of this explicit route. The
higher priority should be preferred by the device. This field is higher priority should be preferred by the device. This field is
used to indicate the backup path at each hop. used to indicate the backup path at each hop.
Reserved.: is set to zero while sending, ignored on receipt. Reserved: is set to zero while sending, ignored on receipt.
Peer/Tunnel Destination Address: To indicate the peer address(4/16 Peer/Tunnel Destination Address: To indicate the peer address(4/16
Bytes). When T bit is set in the associated BPI object, use the Bytes). When T bit is set in the associated BPI object, use the
tunnel destination address in BPI object; when T bit is clear, use tunnel destination address in BPI object; when T bit is clear, use
the peer address in BPI object. the peer address in BPI object.
Next Hop Address to the Peer/Tunnel Destination Address: To indicate Next Hop Address to the Peer/Tunnel Destination Address: To indicate
the next hop address(4/16 Bytes) to the corresponding peer/tunnel the next hop address(4/16 Bytes) to the corresponding peer/tunnel
destination address. destination address.
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 explicit peer path to convey other necessary information for explicit peer path
establishment. Its definition is out of the current document. establishment. Their definitions are out of the current document.
7.4. Peer Prefix Advertisement Object 7.4. Peer Prefix Advertisement Object
The Peer Prefix Advertisement object is defined to specify the IP The Peer Prefix Advertisement object is defined to specify the IP
prefixes that should be advertised to the corresponding peer. This prefixes that should be advertised to the corresponding peer. This
object should only be included and sent to the head/end router of the object should only be included and sent to the head/end router of the
end2end path. end2end path.
The prefixes information included in this object MUST only be The prefixes information included in this object MUST only be
advertised to the indicated peer, MUST NOT be advertised to other BGP advertised to the indicated peer, MUST NOT be advertised to other BGP
skipping to change at page 20, line 47 skipping to change at page 20, line 47
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.
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 prefixes advertisement. to convey other necessary information for prefixes advertisement.
Its definition is out of the current document. Their definitions are out of the current document.
8. End to End Path Protection 8. End to End Path Protection
[RFC8697] defines the path associations procedures between sets of [RFC8697] defines the path associations procedures between sets of
Label Switched Path (LSP). Such procedures can also be used for the Label Switched Path (LSP). Such procedures can also be used for the
E2E path protection. To accomplish this, the PCE should attach the E2E path protection. To accomplish this, the PCE should attach the
ASSOCIATION object with the EPR object in the PCInitiate message, ASSOCIATION object with the EPR object in the PCInitiate message,
with the association type set to 1 (Path Protection Association). with the association type set to 1 (Path Protection Association).
The Extended Association ID that included within the Extended The Extended Association ID that included within the Extended
Association ID TLV, which is included in the ASSOCIATION object, Association ID TLV, which is included in the ASSOCIATION object,
should be set to the Symbolic Path Name of different E2E path. This should be set to the Symbolic Path Name of different E2E path. This
PCinitiate should be sent to the head-end of the E2E path. PCinitiate should be sent to the head-end of the E2E path.
The head-end of the path can use the existing path detection The head-end of the path can use the existing path detection
mechanism, to monitor the status of the active path. Once it detects mechanism(for example, Bidirectional Forwarding Detection [RFC5880]),
the failure, it can switch the backup protection path immediately. to monitor the status of the active path. Once it detects the
failure, it can switch the backup protection path immediately.
9. Re-Delegation and Clean up 9. Re-Delegation and Clean up
In case of a PCE failure, a new PCE can gain control over the central In case of a PCE failure, a new PCE can gain control over the central
controller instructions. As per the PCEP procedures in [RFC8281], controller instructions. As per the PCEP procedures in [RFC8281],
the State Timeout Interval timer is used to ensure that a PCE failure the State Timeout Interval timer is used to ensure that a PCE failure
does not result in automatic and immediate disruption for the does not result in automatic and immediate disruption for the
services. Similarly, as per services. Similarly, as per
[I-D.ietf-pce-pcep-extension-for-pce-controller], the central [I-D.ietf-pce-pcep-extension-for-pce-controller], the central
controller instructions are not removed immediately upon PCE failure. controller instructions are not removed immediately upon PCE failure.
skipping to change at page 25, line 32 skipping to change at page 25, line 38
TBD17:EPR/BPI Peer Info mismatch TBD17:EPR/BPI Peer Info mismatch
TBD18:BPI/PPA Address Family mismatch TBD18:BPI/PPA Address Family mismatch
TBD19:PPA/BPI Peer Info mismatch TBD19:PPA/BPI Peer Info mismatch
15. Contributor 15. Contributor
Dhruv Dhody has contributed the contents of this draft. Dhruv Dhody has contributed the contents of this draft.
16. Acknowledgement 16. Acknowledgement
Thanks Mike Koldychev, Siva Sivabalan, Adam Simpson for his valuable Thanks Mike Koldychev, Susan Hares, Siva Sivabalan, Adam Simpson for
suggestions and comments. his valuable suggestions and comments.
17. Normative References 17. Normative References
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,
"PCEP Procedures and Protocol Extensions for Using PCE as "Path Computation Element Communication Protocol (PCEP)
a Central Controller (PCECC) of LSPs", draft-ietf-pce- Procedures and Extensions for Using the PCE as a Central
pcep-extension-for-pce-controller-14 (work in progress), Controller (PCECC) of LSPs", Work in Progress, Internet-
March 2021. Draft, draft-ietf-pce-pcep-extension-for-pce-controller-
14, 5 March 2021, <https://www.ietf.org/archive/id/draft-
ietf-pce-pcep-extension-for-pce-controller-14.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 26, line 19 skipping to change at page 26, line 29
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
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>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
skipping to change at page 27, line 28 skipping to change at page 28, line 4
"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>.
[RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based [RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
Traffic Engineering (TE) in Native IP Networks", RFC 8821, Traffic Engineering (TE) in Native IP Networks", RFC 8821,
DOI 10.17487/RFC8821, April 2021, DOI 10.17487/RFC8821, April 2021,
<https://www.rfc-editor.org/info/rfc8821>. <https://www.rfc-editor.org/info/rfc8821>.
Authors' Addresses Authors' Addresses
Aijun Wang Aijun Wang
China Telecom China Telecom
Beiqijia Town, Changping District Beiqijia Town, Changping District
Beijing, Beijing 102209 Beijing
Beijing, 102209
China China
Email: wangaj3@chinatelecom.cn Email: wangaj3@chinatelecom.cn
Boris Khasanov Boris Khasanov
Yandex LLC Yandex LLC
Ulitsa Lva Tolstogo 16 Ulitsa Lva Tolstogo 16
Moscow Moscow
Russia
Email: bhassanov@yahoo.com Email: bhassanov@yahoo.com
Sheng Fang Sheng Fang
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing Beijing
China China
Email: fsheng@huawei.com Email: fsheng@huawei.com
Ren Tan Ren Tan
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
skipping to change at page 28, line 23 skipping to change at page 28, line 39
Huawei Technologies,Co.,Ltd Huawei Technologies,Co.,Ltd
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing Beijing
China China
Email: tanren@huawei.com Email: tanren@huawei.com
Chun Zhu Chun Zhu
ZTE Corporation ZTE Corporation
50 Software Avenue, Yuhua District 50 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing
Jiangsu, 210012
China China
Email: zhu.chun1@zte.com.cn Email: zhu.chun1@zte.com.cn
 End of changes. 36 change blocks. 
53 lines changed or deleted 75 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/