< draft-ietf-pce-binding-label-sid-08-20210324.txt   draft-ietf-pce-binding-label-sid-08.txt >
skipping to change at page 1, line 25 skipping to change at page 1, line 25
draft-ietf-pce-binding-label-sid-08 draft-ietf-pce-binding-label-sid-08
Abstract Abstract
In order to provide greater scalability, network opacity, and service In order to provide greater scalability, network opacity, and service
independence, Segment Routing (SR) utilizes a Binding Segment 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 Switching Path or an SR Traffic signaled Traffic Engineering Label Switching 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 a 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 specify 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 5 4. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SRv6 Endpoint Behavior and SID Structure . . . . . . . . 7 4.1. SRv6 Endpoint Behavior and SID Structure . . . . . . . . 7
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Binding SID in SR-ERO . . . . . . . . . . . . . . . . . . . . 10 6. Binding SID in SR-ERO . . . . . . . . . . . . . . . . . . . . 10
7. Binding SID in SRv6-ERO . . . . . . . . . . . . . . . . . . . 10 7. Binding SID in SRv6-ERO . . . . . . . . . . . . . . . . . . . 11
8. PCE Allocation of Binding label/SID . . . . . . . . . . . . . 10 8. PCE Allocation of Binding label/SID . . . . . . . . . . . . . 11
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
9.1. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Manageability Considerations . . . . . . . . . . . . . . . . 14 11. Manageability Considerations . . . . . . . . . . . . . . . . 14
11.1. Control of Function and Policy . . . . . . . . . . . . . 14 11.1. Control of Function and Policy . . . . . . . . . . . . . 14
11.2. Information and Data Models . . . . . . . . . . . . . . 14 11.2. Information and Data Models . . . . . . . . . . . . . . 14
11.3. Liveness Detection and Monitoring . . . . . . . . . . . 14 11.3. Liveness Detection and Monitoring . . . . . . . . . . . 14
11.4. Verify Correct Operations . . . . . . . . . . . . . . . 14 11.4. Verify Correct Operations . . . . . . . . . . . . . . . 15
11.5. Requirements On Other Protocols . . . . . . . . . . . . 14 11.5. Requirements On Other Protocols . . . . . . . . . . . . 15
11.6. Impact On Network Operations . . . . . . . . . . . . . . 14 11.6. Impact On Network Operations . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15 12.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15
12.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . 15 12.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . 15
12.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 16
12.3. PCEP Error Type and Value . . . . . . . . . . . . . . . 16 12.3. PCEP Error Type and Value . . . . . . . . . . . . . . . 16
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 18 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 either set up using the various constraints. Currently, TE paths are either set up using 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.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
included in the TLV. This document specifies the following BT included in the TLV. This document specifies the following BT
values: values:
o BT = 0: The binding value is a 20-bit MPLS label value. The TLV o BT = 0: The binding value is a 20-bit MPLS label value. The TLV
is padded to 4-bytes alignment. The Length MUST be set to 7 and is padded to 4-bytes alignment. The Length MUST be set to 7 and
first 20 bits are used to encode the MPLS label value. first 20 bits are used to encode the MPLS label value.
o BT = 1: The binding value is a 32-bit MPLS label stack entry as o BT = 1: The binding value is a 32-bit MPLS label stack entry as
per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded. per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded.
Note that the receiver MAY choose to override TC, S, and TTL Note that the receiver MAY choose to override TC, S, and TTL
values according its local policy. The Length MUST be set to 8. values according to its local policy. The Length MUST be set to
8.
o BT = 2: The binding value is an SRv6 SID with a format of a 16 o BT = 2: The binding value is an SRv6 SID with a format of a 16
octet IPv6 address, representing the binding SID for SRv6. The octet IPv6 address, representing the binding SID for SRv6. The
Length MUST be set to 20. Length MUST be set to 20.
o BT = 3: The binding value is a 24 octet field, defined in o BT = 3: The binding value is a 24 octet field, defined in
Section 4.1, that contains the SRv6 SID as well as its Behavior Section 4.1, that contains the SRv6 SID as well as its Behavior
and Structure. The Length MUST be set to 28. and Structure. The Length MUST be set to 28.
Section 12.1.1 defines the IANA registry used to maintain all these Section 12.1.1 defines the IANA registry used to maintain all these
skipping to change at page 8, line 18 skipping to change at page 8, line 30
representing the binding SID for SRv6. representing the binding SID for SRv6.
o Reserved: 2 octets. It MUST be set to 0 on transmit and ignored o Reserved: 2 octets. It MUST be set to 0 on transmit and ignored
on receipt. on receipt.
o Endpoint Behavior: 2 octets. The Endpoint Behavior code point for o Endpoint Behavior: 2 octets. The Endpoint Behavior code point for
this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint
Behaviors", created by [RFC8986]. When the field is set with the Behaviors", created by [RFC8986]. When the field is set with the
value 0, the endpoint behavior is considered unknown. value 0, the endpoint behavior is considered unknown.
o The following fields is used to advertise the length of each o The following fields are used to advertise the length of each
individual part of the SRv6 SID as defined in [RFC8986]: individual part of the SRv6 SID as defined in [RFC8986]:
* LB Length: 1 octet. SRv6 SID Locator Block length in bits. * LB Length: 1 octet. SRv6 SID Locator Block length in bits.
* LN Length: 1 octet. SRv6 SID Locator Node length in bits. * LN Length: 1 octet. SRv6 SID Locator Node length in bits.
* Function Length: 1 octet. SRv6 SID Function length in bits. * Function Length: 1 octet. SRv6 SID Function length in bits.
* Argument Length: 1 octet. SRv6 SID Arguments length in bits. * Argument Length: 1 octet. SRv6 SID Arguments length in bits.
5. Operation 5. Operation
The binding value is allocated by the PCC and reported to a PCE via The binding value is allocated by the PCC and reported to a PCE via
PCRpt message. If a PCE does not recognize the TE-PATH-BINDING TLV, PCRpt message. If a PCE does not recognize the TE-PATH-BINDING TLV,
it would ignore the TLV in accordance with [RFC5440]. If a PCE it would ignore the TLV in accordance with [RFC5440]. If a PCE
recognizes the TLV but does not support the TLV, it MUST send PCErr recognizes the TLV but does not support the TLV, it MUST send PCErr
with Error-Type = 2 (Capability not supported). with Error-Type = 2 (Capability not supported).
Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
LSP object. This signifies the presence of multiple binding SIDs for
the given LSP. In case of multiple TE-PATH-BINDING TLVs, all
existing instances of TE-PATH-BINDING TLVs MUST always be included in
the LSP object. In case of an error condition, the whole message is
rejected and the resulting PCErr message MAY include the offending
TE-PATH-BINDING TLV in the PCEP-ERROR object.
If a TE-PATH-BINDING TLV is absent in the PCRpt message, the PCE MUST If a TE-PATH-BINDING TLV is absent in the PCRpt message, the PCE MUST
assume that the corresponding LSP does not have any binding. If a assume that the corresponding LSP does not have any binding. If a
PCE recognizes an invalid binding value (e.g., label value from the PCE recognizes an invalid binding value (e.g., label value from the
reserved label space when MPLS label binding is used), it MUST send a reserved label space when MPLS label binding is used), it MUST send a
PCErr message with Error-Type = 10 ("Reception of an invalid object") PCErr message with Error-Type = 10 ("Reception of an invalid object")
and Error Value = 2 ("Bad label value") as specified in [RFC8664]. and Error Value = 2 ("Bad label value") as specified in [RFC8664].
Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
LSP object. This signifies the presence of multiple binding SIDs for
the given LSP. In case of multiple TE-PATH-BINDING TLVs, all valid
instances of TE-PATH-BINDING TLVs MUST always be included in the LSP
object. In case of an error, a PCErr message MAY include the
offending TE-PATH-BINDING TLV in the PCEP-ERROR object.
For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
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, instead of 2. The choice of by setting the BT (Binding Type) to 3, instead of 2. The choice of
interpreting SRv6 Endpoint Behavior and SID Structure when none is interpreting SRv6 Endpoint Behavior and SID Structure when none is
explicitly specified is left up to the implementation. explicitly specified is left up to the implementation.
If a PCE requires a PCC to allocate a specific binding value, it may If a PCE requires a PCC to allocate a specific binding value(s), it
do so by sending a PCUpd or PCInitiate message containing a TE-PATH- may do so by sending a PCUpd or PCInitiate message containing a TE-
BINDING TLV. If the value can be successfully allocated, the PCC PATH-BINDING TLV(s). If the value(s) can be successfully allocated,
reports the binding value to the PCE. If the PCC considers the the PCC reports the binding value(s) to the PCE. If the PCC
binding value specified by the PCE invalid, it MUST send a PCErr considers the binding value specified by the PCE invalid, it MUST
message with Error-Type = TBD2 ("Binding label/SID failure") and send a PCErr message with Error-Type = TBD2 ("Binding label/SID
Error Value = TBD3 ("Invalid SID"). If the binding value is valid, failure") and Error Value = TBD3 ("Invalid SID"). If the binding
but the PCC is unable to allocate the binding value, it MUST send a value is valid, but the PCC is unable to allocate the binding value,
PCErr message with Error-Type = TBD2 ("Binding label/SID failure") it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/
and Error Value = TBD4 ("Unable to allocate the specified label/ SID failure") and Error Value = TBD4 ("Unable to allocate the
SID"). specified label/SID"). Note that in case of an error, the PCC
rejects the PCUpd or PCInitiate message in its entirety and can carry
the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.
If a PCC receives a TE-PATH-BINDING TLV in any message other than If a PCC receives a TE-PATH-BINDING TLV in any message other than
PCUpd or PCInitiate, it MUST close the corresponding PCEP session PCUpd or PCInitiate, it MUST close the corresponding PCEP session
with the reason "Reception of a malformed PCEP message" (according to with the reason "Reception of a malformed PCEP message" (according to
[RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in
any message other than a PCRpt or if the TE-PATH-BINDING TLV is any message other than a PCRpt or if the TE-PATH-BINDING TLV is
associated with any object other than an LSP or PCEP-ERROR object, associated with any object other than an LSP or PCEP-ERROR object,
the PCE MUST close the corresponding PCEP session with the reason the PCE MUST close the corresponding PCEP session with the reason
"Reception of a malformed PCEP message" (according to [RFC5440]). "Reception of a malformed PCEP message" (according to [RFC5440]).
If a PCC wishes to withdraw or modify a previously reported binding If a PCC wishes to withdraw a previously reported binding value, it
value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV MUST send a PCRpt message without the specific TE-PATH-BINDING TLV.
or with the TE-PATH-BINDING TLV containing the new binding value If a PCC wishes to modify a previously reported binding, it MUST
respectively. Note that in case of multiple TE-PATH-BINDING TLVs, withdraw the old binding value and include a new TE-PATH-BINDING TLV
any other instances of TE-PATH-BINDING TLV that remains unchanged are containing the new binding value. Note that, other instances of TE-
also included. PATH-BINDING TLV that are unchanged are always included.
If a PCE wishes to modify a previously requested binding value, it Similarly, if a PCE wishes to modify a previously requested binding
MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new value, it MUST send a PCUpd message with TE-PATH-BINDING TLV
binding value. Note that in case of multiple TE-PATH-BINDING TLVs, containing the new binding value. Note that, other instances of TE-
any other instances of TE-PATH-BINDING TLV that remains unchanged are PATH-BINDING TLV that are unchanged are always included.
also included.
The absence of TE-PATH-BINDING TLV in PCUpd message means that the The absence of TE-PATH-BINDING TLV in PCUpd message means that the
PCE does not specify a binding value in which case the binding value PCE does not specify a binding value in which case any previous
allocation is governed by the PCC's local policy. allocated binding values are withdraw.
If a PCC receives a valid binding value from a PCE which is different If a PCC receives a new valid binding value from the PCE, it MUST try
than the current binding value, it MUST try to allocate the new to allocate the new binding value. If a PCC does not receive an old
value. If the new binding value is successfully allocated, the PCC binding value for the PCE, it MUST withdraw the old binding value.
MUST report the new value to the PCE. Otherwise, it MUST send a If the new binding value is successfully allocated, the PCC MUST
PCErr message with Error-Type = TBD2 ("Binding label/SID failure") report the new value to the PCE. Otherwise, it MUST send a PCErr
and Error Value = TBD4 ("Unable to allocate the specified label/ message with Error-Type = TBD2 ("Binding label/SID failure") and
SID"). Note that in case of multiple TE-PATH-BINDING TLVs, all Error Value = TBD4 ("Unable to allocate the specified label/SID").
instances of TE-PATH-BINDING TLV that remains unchanged are always Note that, all instances of TE-PATH-BINDING TLV that remains
included in the LSP object and the offending TE-PATH-BINDING TLV is unchanged are always included in the LSP object and the offending TE-
included in the PCEP-ERROR object. PATH-BINDING TLV is included in the PCEP-ERROR object.
In some cases, a stateful PCE can request the PCC to allocate a In some cases, a stateful PCE can request the PCC to allocate a
binding value. It instructs the PCC by sending a PCUpd message binding value. It instructs the PCC by sending a PCUpd message
containing an empty TE-PATH-BINDING TLV, i.e., no binding value is containing an empty TE-PATH-BINDING TLV, i.e., no binding value is
specified (making the length field of the TLV as 4). A PCE can also specified (making the length field of the TLV as 4). A PCE can also
request PCC to allocate a binding value at the time of initiation by request PCC to allocate a binding value at the time of initiation by
sending a PCInitiate message with an empty TE-PATH-BINDING TLV. If sending a PCInitiate message with an empty TE-PATH-BINDING TLV. Only
the PCC is unable to allocate a binding value, it MUST send a PCErr one such instance of empty TE-PATH-BINDING TLV SHOULD be included in
message with Error-Type = TBD2 ("Binding label/SID failure") and the LSP object and other ignored on receipt. If the PCC is unable to
Error-Value = TBD5 ("Unable to allocate label/SID"). allocate a binding value, it MUST send a PCErr message with Error-
Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD5
("Unable to allocate label/SID").
6. Binding SID in SR-ERO 6. Binding SID in SR-ERO
In PCEP messages, LSP route information is carried in the Explicit In PCEP messages, LSP route information is carried in the Explicit
Route Object (ERO), which consists of a sequence of subobjects. Route Object (ERO), which consists of a sequence of subobjects.
[RFC8664] defines a new ERO subobject "SR-ERO subobject" capable of [RFC8664] defines a new ERO subobject "SR-ERO subobject" capable of
carrying a SID as well as the identity of the node/adjacency (NAI) carrying a SID as well as the identity of the node/adjacency (NAI)
represented by the SID. The NAI Type (NT) field indicates the type represented by the SID. The NAI Type (NT) field indicates the type
and format of the NAI contained in the SR-ERO. In case of binding and format of the NAI contained in the SR-ERO. In case of binding
SID, the NAI MUST NOT be included and NT MUST be set to zero. So as SID, the NAI MUST NOT be included and NT MUST be set to zero. So as
 End of changes. 15 change blocks. 
59 lines changed or deleted 64 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/