< 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/ |