< draft-xiong-pce-pcep-extension-sr-tp-02.txt   draft-xiong-pce-pcep-extension-sr-tp-03.txt >
PCE WG Quan Xiong PCE WG Quan Xiong
Internet-Draft Fangwei Hu Internet-Draft Shuangping Zhan
Intended status: Standards Track Shuangping Zhan Intended status: Standards Track ZTE Corporation
Expires: April 25, 2019 ZTE Corporation Expires: September 12, 2019 Fangwei Hu
October 22, 2018 Individual
March 11, 2019
PCEP extensions for SR MPLS-TP PCEP extensions for SR-MPLS-TP
draft-xiong-pce-pcep-extension-sr-tp-02 draft-xiong-pce-pcep-extension-sr-tp-03
Abstract Abstract
This document proposes a set of extensions to PCEP for Segment This document proposes a set of extensions to PCEP for Transport
Routing in MPLS Transport Profile (MPLS-TP) networks and defines a Profile of SR-MPLS (SR-MPLS-TP) networks and defines a mechanism to
mechanism to create the bi-directional SR tunnel in SR networks with create the bi-directional SR tunnel with PCE.
PCE.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The SR MPLS-TP Architecture with PCE . . . . . . . . . . . . 3 2. The SR-MPLS-TP Architecture with PCE . . . . . . . . . . . . 3
2.1. SR Path SID Allocation . . . . . . . . . . . . . . . . . 4 2.1. SR Path SID Allocation . . . . . . . . . . . . . . . . . 5
2.2. Associated Bi-directional SR tunnel . . . . . . . . . . . 5 2.2. Associated Bi-directional SR tunnel . . . . . . . . . . . 6
3. PCEP extensions for SR MPLS-TP . . . . . . . . . . . . . . . 6 3. PCEP extensions for SR-MPLS-TP . . . . . . . . . . . . . . . 7
3.1. ERO extension . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ERO extension . . . . . . . . . . . . . . . . . . . . . . 8
3.2. E bit in LSP object . . . . . . . . . . . . . . . . . . . 7 3.2. E bit in LSP object . . . . . . . . . . . . . . . . . . . 9
3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 7 3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 10
7.1. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Path Computation Element Communication Protocol (PCEP) defined in The Path Computation Element Communication Protocol (PCEP) defined in
[RFC5440] provides mechanisms for Path Computation Elements (PCEs) to [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to
perform path computations in response to Path Computation Clients perform path computations in response to Path Computation Clients
(PCCs) requests. (PCCs) requests.
[I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow [I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow
a stateful PCE to compute Traffic Engineering (TE) paths in segment a stateful PCE to compute Traffic Engineering (TE) paths in segment
routing (SR) networks. But it is applicable to Multi-protocol Label routing (SR) networks. But it is applicable to Multi-protocol Label
Switching (MPLS) networks. [I-D.hu-spring-sr-tp-use-case] describes Switching (MPLS) networks refered as to SR-MPLS. In the context of
the use case of SR tunnel to be deployed in MPLS Transport Profile the Transport Profile of SR-MPLS, referred to in this document as SR-
(MPLS-TP) network. It is required to extend the PCEP protocol to MPLS-TP, a Path Segment uniquely identifies an SR path in a specific
meet the new requirements for SR MPLS-TP services. One of the context. It is required to extend the PCEP protocol to meet the new
requirements is the bidirectional SR tunnel described in requirements for SR-MPLS-TP services. One of the requirements is the
[I-D.cheng-spring-mpls-path-segment]. bidirectional SR tunnel described in
[I-D.ietf-spring-mpls-path-segment].
This document proposes a set of extensions to PCEP for Segment This document proposes a set of extensions to PCEP for SR-MPLS-TP
Routing in MPLS Transport Profile networks and defines a mechanism to networks and defines a mechanism to create the bidirectional SR
create the bidirectional SR tunnel in SR networks with PCE. tunnel with PCE.
1.1. Requirements Language 1.1. Requirements Language
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The terminology is defined as [RFC5440], The terminology is defined as [RFC5440],
[I-D.ietf-pce-segment-routing] , [I-D.cheng-spring-mpls-path-segment] [I-D.ietf-pce-segment-routing] and
and [I-D.hu-spring-sr-tp-use-case]. [I-D.ietf-spring-mpls-path-segment].
2. The SR MPLS-TP Architecture with PCE MPLS-TP: MPLS transport profile.
As described in [I-D.hu-spring-sr-tp-use-case], in MPLS-TP networks, SR: Segment Routing.
the centralized controller may calculate the end to end SR paths, and
creates the ordered segment list. The centralized controller may be SR-MPLS: Segment routing over MPLS data plane.
replaced to PCE as the Figure 1 shown. The PCE can calculate the SR
paths and a SR path can be initiated by PCE or PCC. SR-MPLS-TP: Transport Profile of SR-MPLS.
2. The SR-MPLS-TP Architecture with PCE
As described in [I-D.ietf-spring-mpls-path-segment], in transport
networks, the centralized controller may calculate the end to end SR
paths, and creates the ordered segment list. The centralized
controller may be replaced to PCE as the Figure 1 shown. The PCE can
calculate the SR paths and a SR path can be initiated by PCE or PCC.
| |
| |
V V
+---+--+ +---+--+
+--------------+ PCE +---------------+ +--------------+ PCE +---------------+
| +---+--+ | | +---+--+ |
+-------|-------------------------------------|--------+ +-------|-------------------------------------|--------+
| | SR network | | | | SR network | |
| | | | | | | |
skipping to change at page 3, line 51 skipping to change at page 4, line 37
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Label A | | Label C | | Label A | | Label C |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| ... | | ... | | ... | | ... |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Label C | | Label A | | Label C | | Label A |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| Forward Path Label | | Reverse Path Label | | Forward Path Label | | Reverse Path Label |
+--------------------+ +--------------------+ +--------------------+ +--------------------+
Figure 1 The SR MPLS-TP Architecture with PCE Figure 1 The SR-MPLS-TP Architecture with PCE
It is required to support bidirectional SR tunnel to meet the It is required to support bidirectional SR tunnel to meet the
requirement of MPLS-TP networks. A label named path segment at both requirement of SR-MPLS-TP networks. A label named path segment at
ends of the paths was defined to identify the direction of the SR both ends of the paths was defined to identify the direction of the
paths as defined in [I-D.cheng-spring-mpls-path-segment]. It mainly SR paths as defined in [I-D.ietf-spring-mpls-path-segment]. It
aims to bind two unidirectional SR paths to a single bidirectional mainly aims to bind two unidirectional SR paths to a single
tunnel. bidirectional tunnel.
As the Figure 1 shown, the forward and backward directions of the As the Figure 1 shown, the forward and reverse directions of the
bidirectional SR tunnel are identified by the forward and reverse bidirectional SR tunnel are identified by the forward and reverse
path label respectively. For the ingress node, the forward path path label respectively. For the ingress node, the forward path
label shall be added to the bottom of the label stack and the reverse label shall be added to the bottom of the label stack and the reverse
path label shall be configured to the data plane as incoming label path label shall be configured to the data plane as incoming label
for the SR LSP. And for the egress node, the reverse path label need for the SR LSP. And for the egress node, the reverse path label need
to be the last one label of the label stack and the forward path to be the last one label of the label stack and the forward path
label shall be used as outgoing label. label shall be used as outgoing label.
2.1. SR Path SID Allocation 2.1. SR Path SID Allocation
[RFC8402] defined the IGP, BGP, and Binding segments for the SR-MPLS [RFC8402] defined the IGP, BGP, and Binding segments for the SR-MPLS
and SRv6 data planes which can be referred to by Segment Identifier and SRv6 data planes which can be referred as to Segment Identifier
(SID). And [I-D.cheng-spring-mpls-path-segment] defined a new type (SID). And [I-D.ietf-spring-mpls-path-segment] defined a new type of
of segment named path segment. So the path segment can also be segment named path segment. So the path segment can also be
identified by SID called SR path SID. The path segment may be identified by SID called SR path SID. The path segment may be
associated with a unidirectional path. associated with a unidirectional path.
The path SID allocation includes ingress PCC allocated, egress PCC The path SID allocation includes ingress PCC allocated, egress PCC
allocated and PCE allocated in the domain. In case of egress PCC allocated and PCE allocated in the domain. In case of egress PCC
allocated, the ingress PCC needs to comunicate with PCE to send path allocated, the ingress PCC needs to comunicate with PCE to send path
segment request to egress PCC as the Figure 2 shown. When the segment request to egress PCC as the Figure 2 shown. When the
ingress PCC requests PCE to compute the SR path with PCReq message, ingress PCC requests PCE to compute the SR path with PCReq message,
the PCE needs to request egress PCC to allocate the path SID with the the PCE needs to request egress PCC to allocate the path SID with the
PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. The egress PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. The egress
skipping to change at page 5, line 5 skipping to change at page 6, line 5
When the path SID is allocated by ingress PCC, it need to inform PCE When the path SID is allocated by ingress PCC, it need to inform PCE
with the PCRpt message and the latter one sends the notification to with the PCRpt message and the latter one sends the notification to
egress PCC with PCUpd or PCInit message carried LSP object which set egress PCC with PCUpd or PCInit message carried LSP object which set
the E bit to 1. the E bit to 1.
When the path SID is allocated by PCE, it need to inform ingress and When the path SID is allocated by PCE, it need to inform ingress and
egress PCC with PCUpd or PCInit message carrying the Tunnel 1 and LSP egress PCC with PCUpd or PCInit message carrying the Tunnel 1 and LSP
1. But the message sent to egress PCC MUST set the E bit to 1 to 1. But the message sent to egress PCC MUST set the E bit to 1 to
avoid triggering the LSP initiation. avoid triggering the LSP initiation.
+------+ +------+
| PCE | | PCE |
+------+ +------+
PCReq ^ \ PCUpd/PCInit PCReq ^ \ PCUpd/PCInit
Tunnel 1 / \ Tunnel 1 Tunnel 1 / \ Tunnel 1
LSP1 / \ LSP1, E=1 LSP1 / \ LSP1, E=1
/ \ / v
/ v +--------+ LSP1 +-------+
+--------+ LSP1 +-------+ |Ingress |----------->|Egress |
|Ingress |----------->|Egress | |PCC |<-----------|PCC |
|PCC |<-----------|PCC | +--------+ LSP2 +-------+
+--------+ LSP2 +-------+
Figure 2 The path SID allocation with PCE Figure 2 The path SID allocation with PCE
2.2. Associated Bi-directional SR tunnel 2.2. Associated Bi-directional SR tunnel
As [RFC5654] defined, MPLS-TP MUST support unidirectional, co-routed As [RFC5654] defined, MPLS-TP MUST support unidirectional, co-routed
bidirectional, and associated bidirectional point-to-point transport bidirectional, and associated bidirectional point-to-point transport
paths. Based on the defination of co-routed bidirectional path, the paths. As [RFC8402] defined, segment routing leverages the source
forward and backward directions follow the same route (links and
nodes) across the network and must be setup, monitored and protected
as a single entity.
However, as [RFC8402] defined, segment routing leverages the source
routing paradigm and the sourse node steers a packet through an routing paradigm and the sourse node steers a packet through an
ordered segment list along a unidirectional path. So for ordered segment list along a unidirectional path. So for
bidirectional SR tunnel, the forward and backward directional paths bidirectional SR tunnel, the forward and backward directional paths
may be setup by the source node and destination node seperately. So may be setup by the source node and destination node seperately.
the co-routed birectional SR paths can not be provisioned by PCE.
As described in [I-D.ietf-pce-association-bidir], two reverse As described in [I-D.ietf-pce-association-bidir], two reverse
unidirectional LSPs can be associated as an associated bidirectional unidirectional LSPs can be associated as an associated bidirectional
tunnel which can be initialed by single-sided and double-sided tunnel which can be initialed by single-sided and double-sided
methods. Based on the discussion above, the associated bidirectional methods. Based on the discussion above, the associated bidirectional
SR tunnel can only be provisioned on both ingress and egress node SR tunnel can only be provisioned on both ingress and egress node
(PCCs). (PCCs).
The Double-sided initiation can be initiated by PCCs or PCE.The The Single-sided initiation can be initiated by ingress SR node and
forward and reverse directional paths can be co-routed or non- initiate two unidirectional LSPs to headend SR nodes as shown in
corouted. The SR bidirectional tunnel may follow the same path in Figure 3. The Double-sided initiation can be initiated by PCCs or
the forward and reverse directions and initialed as a co-routed PCE as shown in Figure 4 and 5 respectively. The forward and reverse
associated bidirectional LSP. directional paths can be co-routed or non-corouted. The SR
bidirectional tunnel may follow the same path in the forward and
reverse directions and initiated as a co-routed associated
bidirectional LSP. When the PCE initiated the LSP, the B flag need
to be set to indicate a bi-directional LSP as defined in
[I-D.ietf-pce-pcep-stateful-pce-gmpls].
3. PCEP extensions for SR MPLS-TP +---------+
| PCE |
+---------+
1,PCReq ^ /2,PCInit\ 2,PCInit
Tunnel 1 / / Tunnel 1 \ Tunnel 1
/ / LSP1 \ LSP2
/ v v
+--------+ LSP1 +-------+
|Ingress |----------->|Egress |
|PCC |<-----------|PCC |
+--------+ LSP2 +-------+
Figure 3 PCC-initiated Single-sided Associated Bi-directional LSPs
+---------+
| PCE |
+---------+
1,PCReq ^ /2,PCInit \ ^ 1,PCReq
Tunnel 1 / / Tunnel 1 \ \ Tunnel 1
LSP1 / / LSP1/LSP2 \ \ LSP2
/ v v \
+--------+ LSP1 +-------+
|Ingress |----------->|Egress |
|PCC |<-----------|PCC |
+--------+ LSP2 +-------+
Figure 4 PCC-initiated Double-sided Associated Bi-directional LSPs
+---------+
| PCE |
+---------+
PCInit / \ PCInit
Tunnel 1 / \ Tunnel 1
LSP1 / \ LSP2
v v
+--------+ LSP1 +-------+
|Ingress |----------->|Egress |
|PCC |<-----------|PCC |
+--------+ LSP2 +-------+
Figure 5 PCE-initiated Double-sided Associated Bi-directional LSPs
3. PCEP extensions for SR-MPLS-TP
3.1. ERO extension 3.1. ERO extension
As described in [I-D.hu-spring-sr-tp-use-case], it is required to As described in [I-D.ietf-spring-mpls-path-segment], it is required
support bi-directional tunnel to meet the requirement of SR networks. to support bi-directional tunnel to meet the requirement of SR
But it is the uni-directional tunnel for SR and engineering traffic networks. But it is the uni-directional tunnel for SR and
network as discussed in [I-D.ietf-pce-segment-routing]. The SR path engineering traffic network as discussed in
is carried in the Segment Routing Explicit Route Object (SR-ERO), [I-D.ietf-pce-segment-routing]. The SR path is carried in the
which consists of a sequence of SR subobjects. This document Segment Routing Explicit Route Object (SR-ERO), which consists of a
proposes the extension of the SR-ERO Subobject to carry the bi- sequence of SR subobjects. This document proposes the extension of
directional tunnel information as the Figure 3 shown. The subobjects the SR-ERO Subobject to carry the bi-directional tunnel information
with path SIDs need to be added to the list of the SR-ERO subobjects. as the Figure 6 shown. The subobjects with path SIDs need to be
added to the list of the SR-ERO subobjects.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | NT | Flags |R|F|S|C|M| |L| Type | Length | NT | Flags |R|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID | | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI(variable,optional) // // NAI(variable,optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Extension of SR-ERO Subobject format Figure 6 Extension of SR-ERO Subobject format
NAI Type (NT) : A new type of NT = 6 is added in this document and it NAI Type (NT) : A new type of NT = 6 is added in this document and it
indicates the type and format of the NAI associated with the path SID indicates the type and format of the NAI associated with the path SID
contained in the object body. When NT is set to 6, the format of NAI contained in the object body. When NT is set to 6, the format of NAI
field is shown as figure 4. field is shown as Figure 7.
R (Reverse Flag -- 1 bit): indicates the SR path direction, when it R (Reverse Flag -- 1 bit): indicates the SR path direction, when it
is clear, it indicates the forward direction and when it is set, it is clear, it indicates the forward direction and when it is set, it
indicates the reverse direction. indicates the reverse direction.
The definition of other fields is the same with The definition of other fields is the same with
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Label | TC |S| TTL | | Path Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 NAI for Path Label information Figure 7 NAI for Path Label information
The format of Path Label information is specified as The format of Path Label information is specified as
[I-D.cheng-spring-mpls-path-segment]. [I-D.ietf-spring-mpls-path-segment].
3.2. E bit in LSP object 3.2. E bit in LSP object
The LSP object is defined in [RFC8231]. This document proposes the E The LSP object is defined in [RFC8231]. This document proposes the E
bit in flag field of the LSP object: bit in flag field of the LSP object as shown in Figure 8:
E (Egress PCC Operation bit): If the bit is set to 1, it indicates E (Egress PCC Operation bit): If the bit is set to 1, it indicates
that the egress PCC operation with PCUpd or PCInit message and no that the egress PCC operation with PCUpd or PCInit message and no
need to trigger the LSP initiation. A PCE would set the bit to 1 in need to trigger the LSP initiation. A PCE would set the bit to 1 in
SR network to request or inform the path SID information. SR network to request or inform the path SID information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag |E| | PLSP-ID | Flag |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 The extension of LSP object Figure 8 The extension of LSP object
3.3. Processing Rules 3.3. Processing Rules
As discussed in [I-D.cheng-spring-mpls-path-segment], the bi- As discussed in [I-D.ietf-spring-mpls-path-segment], the bi-
directional SR tunnel is created from two binding unidirectional SR directional SR tunnel is created from two binding unidirectional SR
paths. As defined in [RFC8281], the stateful PCE calculates the SR paths. As defined in [RFC8281], the stateful PCE calculates the SR
paths and initiates the bi-directional LSP with PCUpd or PCInit paths and initiates the bi-directional LSP with PCUpd or PCInit
message. message.
The B bit in SRP Object MUST be set and the two unidirectional SR The B bit in SRP Object MUST be set and the two unidirectional SR
paths may be computed from the forward and reverse direction and sent paths may be computed from the forward and reverse direction and sent
to the source and destination PCC respectively in SR-ERO object. The to the source and destination PCC respectively in SR-ERO object. The
path labels which binding the paths may be generated in PCE and sent path labels which binding the paths may be generated in PCE and sent
to the related PCC carried in the bottom of the SR-ERO. When the to the related PCC carried in the bottom of the SR-ERO. When the
skipping to change at page 8, line 13 skipping to change at page 10, line 9
TBD. TBD.
5. IANA Considerations 5. IANA Considerations
TBD. TBD.
6. Acknowledgements 6. Acknowledgements
TBD. TBD.
7. References 7. Normative References
7.1. Informative References
[I-D.hu-spring-sr-tp-use-case]
hu, f., Xiong, Q., Mirsky, G., and W. Cheng, "Segment
Routing Transport Profile Use Case", draft-hu-spring-sr-
tp-use-case-01 (work in progress), March 2018.
7.2. Normative References
[I-D.cheng-spring-mpls-path-segment]
Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler,
R., and S. Zhan, "Path Segment in MPLS Based Segment
Routing Network", draft-cheng-spring-mpls-path-segment-03
(work in progress), October 2018.
[I-D.ietf-pce-association-bidir] [I-D.ietf-pce-association-bidir]
Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for
Associated Bidirectional Label Switched Paths (LSPs)", Associated Bidirectional Label Switched Paths (LSPs)",
draft-ietf-pce-association-bidir-01 (work in progress), draft-ietf-pce-association-bidir-02 (work in progress),
May 2018. November 2018.
[I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zhang, F., Casellas, R., Dios, O., and Z. Ali,
"Path Computation Element (PCE) Protocol Extensions for
Stateful PCE Usage in GMPLS-controlled Networks", draft-
ietf-pce-pcep-stateful-pce-gmpls-10 (work in progress),
March 2019.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-14 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
October 2018. March 2019.
[I-D.ietf-spring-mpls-path-segment]
Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler,
"Path Segment in MPLS Based Segment Routing Network",
draft-ietf-spring-mpls-path-segment-00 (work in progress),
March 2019.
[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>.
[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>.
skipping to change at page 9, line 38 skipping to change at page 11, line 33
Quan Xiong Quan Xiong
ZTE Corporation ZTE Corporation
No.6 Huashi Park Rd No.6 Huashi Park Rd
Wuhan, Hubei 430223 Wuhan, Hubei 430223
China China
Phone: +86 27 83531060 Phone: +86 27 83531060
Email: xiong.quan@zte.com.cn Email: xiong.quan@zte.com.cn
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Shuangping Zhan Shuangping Zhan
ZTE Corporation ZTE Corporation
Liuxian Rd Liuxian Rd
Shenzhen 518057 Shenzhen 518057
China China
Phone: +86 755 26773770 Phone: +86 755 26773770
Email: zhan.shuangping@zte.com.cn Email: zhan.shuangping@zte.com.cn
Fangwei Hu
Individual
Email: hufwei@gmail.com
 End of changes. 35 change blocks. 
124 lines changed or deleted 161 lines changed or added

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