draft-ietf-pce-binding-label-sid-09.txt   draft-ietf-pce-binding-label-sid-10.txt 
PCE Working Group S. Sivabalan PCE Working Group S. Sivabalan
Internet-Draft Ciena Corporation Internet-Draft Ciena Corporation
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: December 5, 2021 Cisco Systems, Inc. Expires: January 9, 2022 Cisco Systems, Inc.
J. Tantsura J. Tantsura
Juniper Networks Microsoft Corporation
S. Previdi S. Previdi
C. Li, Ed. C. Li, Ed.
Huawei Technologies Huawei Technologies
June 3, 2021 July 8, 2021
Carrying Binding Label/Segment Identifier in PCE-based Networks. Carrying Binding Label/Segment Identifier in PCE-based Networks.
draft-ietf-pce-binding-label-sid-09 draft-ietf-pce-binding-label-sid-10
Abstract Abstract
In order to provide greater scalability, network confidentiality, and In order to provide greater scalability, network confidentiality, and
service independence, Segment Routing (SR) utilizes a Binding Segment service independence, Segment Routing (SR) utilizes a Binding Segment
Identifier (BSID). It is possible to associate a BSID to an RSVP-TE- Identifier (BSID). It is possible to associate a BSID to an RSVP-TE-
signaled Traffic Engineering Label Switched Path or an SR Traffic signaled Traffic Engineering Label Switched Path or an SR Traffic
Engineering path. The BSID can be used by an upstream node for Engineering path. The BSID can be used by an upstream node for
steering traffic into the appropriate TE path to enforce SR policies. steering traffic into the appropriate TE path to enforce SR policies.
This document specifies the binding value as an MPLS label or Segment This document specifies the binding value as an MPLS label or Segment
Identifier. It further specify an approach for reporting binding Identifier. It further specifies an approach for reporting binding
label/SID by a Path Computation Client (PCC) to the Path Computation label/SID by a Path Computation Client (PCC) to the Path Computation
Element (PCE) to support PCE-based Traffic Engineering policies. Element (PCE) to support PCE-based Traffic Engineering policies.
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 December 5, 2021. This Internet-Draft will expire on January 9, 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
A Path Computation Element (PCE) can compute Traffic Engineering A Path Computation Element (PCE) can compute Traffic Engineering
paths (TE paths) through a network where those paths are subject to paths (TE paths) through a network where those paths are subject to
various constraints. Currently, TE paths are set up either using the various constraints. Currently, TE paths are set up using either the
RSVP-TE signaling protocol or Segment Routing (SR). We refer to such RSVP-TE signaling protocol or Segment Routing (SR). We refer to such
paths as RSVP-TE paths and SR-TE paths respectively in this document. paths as RSVP-TE paths and SR-TE paths respectively in this document.
As per [RFC8402] SR allows a head-end node to steer a packet flow As per [RFC8402] SR allows a head-end node to steer a packet flow
along any path. The head-end node is said to steer a flow into a along any path. The head-end node is said to steer a flow into a
Segment Routing Policy (SR Policy). Further, as per Segment Routing Policy (SR Policy). Further, as per
[I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework
that enables the instantiation of an ordered list of segments on a that enables the instantiation of an ordered list of segments on a
node for implementing a source routing policy with a specific intent node for implementing a source routing policy with a specific intent
for traffic steering from that node. for traffic steering from that node.
As described in [RFC8402], a Binding Segment Identifier (BSID) is As described in [RFC8402], a Binding Segment Identifier (BSID) is
bound to a Segment Routed (SR) Policy, instantiation of which may bound to a Segment Routing (SR) Policy, instantiation of which may
involve a list of SIDs. Any packets received with an active segment involve a list of SIDs. Any packets received with an active segment
equal to a BSID are steered onto the bound SR Policy. A BSID may be equal to a BSID are steered onto the bound SR Policy. A BSID may be
either a local (SR Local Block (SRLB)) or a global (SR Global Block either a local (SR Local Block (SRLB)) or a global (SR Global Block
(SRGB)) SID. As per Section 6.4 of (SRGB)) SID. As per Section 6.4 of
[I-D.ietf-spring-segment-routing-policy] a BSID can also be [I-D.ietf-spring-segment-routing-policy] a BSID can also be
associated with any type of interface or tunnel to enable the use of associated with any type of interface or tunnel to enable the use of
a non-SR interface or tunnel as a segment in a SID list. In this a non-SR interface or tunnel as a segment in a SID list. In this
document, binding label/SID is used to generalize the allocation of document, binding label/SID is used to generalize the allocation of
binding value for both SR and non-SR paths. binding value for both SR and non-SR paths.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
( ) SID of ( ) ( ) SID of ( )
'-----' Node-1 '-----' '-----' Node-1 '-----'
is Y SIDs for SR-TE LSP: is Y SIDs for SR-TE LSP:
{A, B, C, D} {A, B, C, D}
Figure 1: A sample Use-case of Binding SID Figure 1: A sample Use-case of Binding SID
A PCC could report to the stateful PCE the binding label/SID it A PCC could report to the stateful PCE the binding label/SID it
allocated via a Path Computation LSP State Report (PCRpt) message. allocated via a Path Computation LSP State Report (PCRpt) message.
It is also possible for a stateful PCE to request a PCC to allocate a It is also possible for a stateful PCE to request a PCC to allocate a
specific binding label/SID by sending aPath Computation LSP Update specific binding label/SID by sending a Path Computation LSP Update
Request (PCUpd) message. If the PCC can successfully allocate the Request (PCUpd) message. If the PCC can successfully allocate the
specified binding value, it reports the binding value to the PCE. specified binding value, it reports the binding value to the PCE.
Otherwise, the PCC sends an error message to the PCE indicating the Otherwise, the PCC sends an error message to the PCE indicating the
cause of the failure. A local policy or configuration at the PCC cause of the failure. A local policy or configuration at the PCC
SHOULD dictate if the binding label/SID needs to be assigned. SHOULD dictate if the binding label/SID needs to be assigned.
In this document, we introduce a new OPTIONAL TLV that a PCC can use In this document, we introduce a new OPTIONAL TLV that a PCC can use
in order to report the binding label/SID associated with a TE LSP, or in order to report the binding label/SID associated with a TE LSP, or
a PCE to request a PCC to allocate a specific binding label/SID a PCE to request a PCC to allocate a specific binding label/SID
value. This TLV is intended for TE LSPs established using RSVP-TE, value. This TLV is intended for TE LSPs established using RSVP-TE,
skipping to change at page 9, line 25 skipping to change at page 9, line 25
SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
by setting the BT (Binding Type) to 3. This enables the sender to by setting the BT (Binding Type) to 3. This enables the sender to
have control of the SRv6 Endpoint Behavior and SID Structure. A have control of the SRv6 Endpoint Behavior and SID Structure. A
sender MAY choose to set the BT to 2, in which case the receiving sender MAY choose to set the BT to 2, in which case the receiving
implementation chooses how to interpret the SRv6 Endpoint Behavior implementation chooses how to interpret the SRv6 Endpoint Behavior
and SID Structure according to local policy. and SID Structure according to local policy.
If a PCC wishes to withdraw a previously reported binding value, it If a PCC wishes to withdraw a previously reported binding value, it
MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with
R flag set to 1. If a PCC wishes to modify a previously reported R flag set to 1. If a PCC wishes to modify a previously reported
binding, it MUST withdraw the former old binding value (with R flag binding, it MUST withdraw the former binding value (with R flag set
set in the former TE-PATH-BINDING TLV) and include a new TE-PATH- in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING
BINDING TLV containing the new binding value. Note that other TLV containing the new binding value. Note that other instances of
instances of TE-PATH-BINDING TLVs that are unchanged MAY also be TE-PATH-BINDING TLVs that are unchanged MAY also be included.
included.
If a PCE requires a PCC to allocate a (or several) specific binding If a PCE requires a PCC to allocate a (or several) specific binding
value(s), it may do so by sending a PCUpd or PCInitiate message value(s), it may do so by sending a PCUpd or PCInitiate message
containing a TE-PATH-BINDING TLV(s). If the value(s) can be containing a TE-PATH-BINDING TLV(s). If the value(s) can be
successfully allocated, the PCC reports the binding value(s) to the successfully allocated, the PCC reports the binding value(s) to the
PCE. If the PCC considers the binding value specified by the PCE PCE. If the PCC considers the binding value specified by the PCE
invalid, it MUST send a PCErr message with Error-Type = TBD2 invalid, it MUST send a PCErr message with Error-Type = TBD2
("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID"). ("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID").
If the binding value is valid, but the PCC is unable to allocate the If the binding value is valid, but the PCC is unable to allocate the
binding value, it MUST send a PCErr message with Error-Type = TBD2 binding value, it MUST send a PCErr message with Error-Type = TBD2
skipping to change at page 12, line 33 skipping to change at page 12, line 28
TE-PATH-BINDING TLV in the LSP object. TE-PATH-BINDING TLV in the LSP object.
o To let the PCC allocates the binding label/SID, a PCE MUST set P=0 o To let the PCC allocates the binding label/SID, a PCE MUST set P=0
and include an empty TE-PATH-BINDING TLV ( i.e., no binding value and include an empty TE-PATH-BINDING TLV ( i.e., no binding value
is specified) in the LSP object in PCInitiate/PCUpd message. is specified) in the LSP object in PCInitiate/PCUpd message.
o To request that the PCE allocate the binding label/SID, a PCC MUST o To request that the PCE allocate the binding label/SID, a PCC MUST
set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt
message. The PCE SHOULD allocate it and respond to the PCC with message. The PCE SHOULD allocate it and respond to the PCC with
PCUpd message including the allocated binding label/SID in the TE- PCUpd message including the allocated binding label/SID in the TE-
PATH-BINDING TLV and P=1, D=1 in the LSP object. PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is
unable to allocate, it MUST send a PCErr message with Error-Type =
TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable
to allocate a new binding label/SID").
o If both peers have not exchanged the PCECC capabilities as per o If both peers have not exchanged the PCECC capabilities as per
[I-D.ietf-pce-pcep-extension-for-pce-controller] and a PCEP peer [I-D.ietf-pce-pcep-extension-for-pce-controller] and a PCEP peer
receives P=1 in the LSP object, it needs to act as per receives P=1 in the LSP object, it needs to act as per
[I-D.ietf-pce-pcep-extension-for-pce-controller]: [I-D.ietf-pce-pcep-extension-for-pce-controller]:
* Send a PCErr message with Error-Type=19 (Invalid Operation) and * Send a PCErr message with Error-Type=19 (Invalid Operation) and
Error-Value=16 (Attempted PCECC operations when PCECC Error-Value=16 (Attempted PCECC operations when PCECC
capability was not advertised) capability was not advertised)
skipping to change at page 21, line 13 skipping to change at page 21, line 13
EMail: msiva282@gmail.com EMail: msiva282@gmail.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Pegasus Parc Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831 De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM BELGIUM
EMail: cfilsfil@cisco.com EMail: cfilsfil@cisco.com
Jeff Tantsura Jeff Tantsura
Juniper Networks Microsoft Corporation
EMail: jefftant.ietf@gmail.com EMail: jefftant.ietf@gmail.com
Stefano Previdi Stefano Previdi
Huawei Technologies Huawei Technologies
EMail: stefano@previdi.net EMail: stefano@previdi.net
Cheng Li (editor) Cheng Li (editor)
Huawei Technologies Huawei Technologies
 End of changes. 12 change blocks. 
16 lines changed or deleted 18 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/