| draft-ietf-idr-bgp-ls-sr-policy-06.txt | draft-ietf-idr-bgp-ls-sr-policy-07.txt | |||
|---|---|---|---|---|
| Inter-Domain Routing S. Previdi | Inter-Domain Routing S. Previdi | |||
| Internet-Draft Individual | Internet-Draft Individual | |||
| Intended status: Standards Track K. Talaulikar, Ed. | Intended status: Standards Track K. Talaulikar, Ed. | |||
| Expires: 22 April 2025 Cisco Systems | Expires: 27 April 2025 Cisco Systems | |||
| J. Dong | J. Dong | |||
| Huawei Technologies | Huawei Technologies | |||
| H. Gredler | H. Gredler | |||
| RtBrick Inc. | RtBrick Inc. | |||
| J. Tantsura | J. Tantsura | |||
| Nvidia | Nvidia | |||
| 19 October 2024 | 24 October 2024 | |||
| Advertisement of Segment Routing Policies using BGP Link-State | Advertisement of Segment Routing Policies using BGP Link-State | |||
| draft-ietf-idr-bgp-ls-sr-policy-06 | draft-ietf-idr-bgp-ls-sr-policy-07 | |||
| Abstract | Abstract | |||
| This document describes a mechanism to collect the Segment Routing | This document describes a mechanism to collect the Segment Routing | |||
| Policy information that is locally available in a node and advertise | Policy information that is locally available in a node and advertise | |||
| it into BGP Link-State (BGP-LS) updates. Such information can be | it into BGP Link-State (BGP-LS) updates. Such information can be | |||
| used by external components for path computation, re-optimization, | used by external components for path computation, re-optimization, | |||
| service placement, network visualization, etc. | service placement, network visualization, etc. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 22 April 2025. | This Internet-Draft will expire on 27 April 2025. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 26 ¶ | skipping to change at page 2, line 26 ¶ | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
| 2. Carrying SR Policy Information in BGP . . . . . . . . . . . . 5 | 2. Carrying SR Policy Information in BGP . . . . . . . . . . . . 5 | |||
| 3. SR Policy Candidate Path NLRI Type . . . . . . . . . . . . . 6 | 3. SR Policy Candidate Path NLRI Type . . . . . . . . . . . . . 6 | |||
| 4. SR Policy Candidate Path Descriptor . . . . . . . . . . . . . 7 | 4. SR Policy Candidate Path Descriptor . . . . . . . . . . . . . 7 | |||
| 5. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 9 | 5. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5.1. SR Binding SID TLV . . . . . . . . . . . . . . . . . . . 9 | 5.1. SR Binding SID TLV . . . . . . . . . . . . . . . . . . . 9 | |||
| 5.2. SRv6 Binding SID TLV . . . . . . . . . . . . . . . . . . 11 | 5.2. SRv6 Binding SID TLV . . . . . . . . . . . . . . . . . . 11 | |||
| 5.3. SR Candidate Path State TLV . . . . . . . . . . . . . . . 13 | 5.3. SR Candidate Path State TLV . . . . . . . . . . . . . . . 13 | |||
| 5.4. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 15 | 5.4. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.5. SR Candidate Path Name TLV . . . . . . . . . . . . . . . 15 | 5.5. SR Candidate Path Name TLV . . . . . . . . . . . . . . . 16 | |||
| 5.6. SR Candidate Path Constraints TLV . . . . . . . . . . . . 16 | 5.6. SR Candidate Path Constraints TLV . . . . . . . . . . . . 16 | |||
| 5.6.1. SR Affinity Constraint Sub-TLV . . . . . . . . . . . 18 | 5.6.1. SR Affinity Constraint Sub-TLV . . . . . . . . . . . 19 | |||
| 5.6.2. SR SRLG Constraint Sub-TLV . . . . . . . . . . . . . 20 | 5.6.2. SR SRLG Constraint Sub-TLV . . . . . . . . . . . . . 20 | |||
| 5.6.3. SR Bandwidth Constraint Sub-TLV . . . . . . . . . . . 20 | 5.6.3. SR Bandwidth Constraint Sub-TLV . . . . . . . . . . . 21 | |||
| 5.6.4. SR Disjoint Group Constraint Sub-TLV . . . . . . . . 21 | 5.6.4. SR Disjoint Group Constraint Sub-TLV . . . . . . . . 21 | |||
| 5.6.5. SR Bidirectional Group Constraint Sub-TLV . . . . . . 23 | 5.6.5. SR Bidirectional Group Constraint Sub-TLV . . . . . . 24 | |||
| 5.6.6. SR Metric Constraint Sub-TLV . . . . . . . . . . . . 24 | 5.6.6. SR Metric Constraint Sub-TLV . . . . . . . . . . . . 25 | |||
| 5.7. SR Segment List TLV . . . . . . . . . . . . . . . . . . . 26 | 5.7. SR Segment List TLV . . . . . . . . . . . . . . . . . . . 27 | |||
| 5.8. SR Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 28 | 5.8. SR Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 29 | |||
| 5.8.1. Segment Descriptors . . . . . . . . . . . . . . . . . 30 | 5.8.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31 | |||
| 5.9. SR Segment List Metric Sub-TLV . . . . . . . . . . . . . 37 | 5.9. SR Segment List Metric Sub-TLV . . . . . . . . . . . . . 38 | |||
| 5.10. SR Segment List Bandwidth Sub-TLV . . . . . . . . . . . . 39 | 5.10. SR Segment List Bandwidth Sub-TLV . . . . . . . . . . . . 40 | |||
| 5.11. SR Segment List Identifier Sub-TLV . . . . . . . . . . . 40 | 5.11. SR Segment List Identifier Sub-TLV . . . . . . . . . . . 41 | |||
| 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
| 7. Manageability Considerations . . . . . . . . . . . . . . . . 41 | 7. Manageability Considerations . . . . . . . . . . . . . . . . 42 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | |||
| 8.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 41 | 8.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 42 | |||
| 8.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 42 | 8.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 43 | |||
| 8.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 42 | 8.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| 8.4. SR Policy Protocol Origin . . . . . . . . . . . . . . . . 43 | 8.4. SR Policy Protocol Origin . . . . . . . . . . . . . . . . 44 | |||
| 8.5. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 43 | 8.5. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 45 | |||
| 8.6. BGP-LS SR Policy Metric Type . . . . . . . . . . . . . . 44 | 8.6. BGP-LS SR Policy Metric Type . . . . . . . . . . . . . . 46 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | |||
| 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 46 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 48 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 47 | 12.2. Informative References . . . . . . . . . . . . . . . . . 49 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
| 1. Introduction | 1. Introduction | |||
| SR Policy architecture details are specified in [RFC9256]. An SR | SR Policy architecture details are specified in [RFC9256]. An SR | |||
| Policy comprises one or more candidate paths (CP) of which at a given | Policy comprises one or more candidate paths (CP) of which at a given | |||
| time one and only one may be active (i.e., installed in forwarding | time one and only one may be active (i.e., installed in forwarding | |||
| and usable for steering of traffic). Each CP in turn may have one or | and usable for steering of traffic). Each CP in turn may have one or | |||
| more SID-List of which one or more SID-List may be active. When | more SID-List of which one or more SID-List may be active. When | |||
| multiple SID-Lists are active then traffic is load balanced over | multiple SID-Lists are active then traffic is load balanced over | |||
| them. This document covers the advertisement of state information at | them. This document covers the advertisement of state information at | |||
| skipping to change at page 10, line 45 ¶ | skipping to change at page 10, line 45 ¶ | |||
| where: | where: | |||
| - D-Flag: Indicates the dataplane for the BSIDs and if they are | - D-Flag: Indicates the dataplane for the BSIDs and if they are | |||
| 16 octet SRv6 SID when set and are 4 octet SR/MPLS label value | 16 octet SRv6 SID when set and are 4 octet SR/MPLS label value | |||
| when clear. | when clear. | |||
| - B-Flag: Indicates the allocation of the value in the BSID field | - B-Flag: Indicates the allocation of the value in the BSID field | |||
| when set and indicates that BSID is not allocated when clear. | when set and indicates that BSID is not allocated when clear. | |||
| - U-Flag: Indicates the specified BSID value is unavailable when | - U-Flag: Indicates the specified BSID value is unavailable when | |||
| set. | set. When clear it indicates that this CP is using the | |||
| specified BSID. This flag is ignored when there is no | ||||
| specified BSID. | ||||
| - L-Flag: Indicates the BSID value is from the Segment Routing | - L-Flag: Indicates the BSID value is from the Segment Routing | |||
| Local Block (SRLB) of the headend node when set and is from the | Local Block (SRLB) of the headend node when set and is from the | |||
| local dynamic label pool when clear | local dynamic label pool when clear. | |||
| - F-Flag: Indicates the BSID value is one allocated from dynamic | - F-Flag: Indicates the BSID value is one allocated from dynamic | |||
| label pool due to fallback (e.g. when specified BSID is | label pool due to fallback (e.g. when specified BSID is | |||
| unavailable) when set. | unavailable) when set and indicates that there has been no | |||
| fallback for BSID allocation when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Binding SID: It indicates the operational or allocated BSID value | * Binding SID: It indicates the operational or allocated BSID value | |||
| based on the status flags. | based on the status flags. | |||
| * Specified BSID: It is used to report the explicitly specified BSID | * Specified BSID: It is used to report the explicitly specified BSID | |||
| value regardless of whether it is successfully allocated or not. | value regardless of whether it is successfully allocated or not. | |||
| The field is set to value 0 when BSID has not been specified. | The field is set to value 0 when BSID has not been specified. | |||
| skipping to change at page 12, line 49 ¶ | skipping to change at page 12, line 51 ¶ | |||
| - B-Flag: Indicates the allocation of the value in the BSID field | - B-Flag: Indicates the allocation of the value in the BSID field | |||
| when set and indicates that BSID is not allocated when clear. | when set and indicates that BSID is not allocated when clear. | |||
| - U-Flag: Indicates the specified BSID value is unavailable when | - U-Flag: Indicates the specified BSID value is unavailable when | |||
| set. When clear it indicates that this CP is using the | set. When clear it indicates that this CP is using the | |||
| specified BSID. This flag is ignored when there is no | specified BSID. This flag is ignored when there is no | |||
| specified BSID. | specified BSID. | |||
| - F-Flag: Indicates the BSID value is one allocated dynamically | - F-Flag: Indicates the BSID value is one allocated dynamically | |||
| due to fallback (e.g. when specified BSID is unavailable) when | due to fallback (e.g. when specified BSID is unavailable) when | |||
| set. | set and indicates that there has been no fallback for BSID | |||
| allocation when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Binding SID: It indicates the operational or allocated BSID value | * Binding SID: It indicates the operational or allocated BSID value | |||
| based on the status flags. | based on the status flags. | |||
| * Specified BSID: It is used to report the explicitly specified BSID | * Specified BSID: It is used to report the explicitly specified BSID | |||
| value regardless of whether it is successfully allocated or not. | value regardless of whether it is successfully allocated or not. | |||
| The field is set to value 0 when BSID has not been specified. | The field is set to value 0 when BSID has not been specified. | |||
| skipping to change at page 14, line 7 ¶ | skipping to change at page 14, line 10 ¶ | |||
| * Length: 8 octets | * Length: 8 octets | |||
| * Priority: 1-octet value which indicates the priority of the CP. | * Priority: 1-octet value which indicates the priority of the CP. | |||
| Refer Section 2.12 of [RFC9256]. | Refer Section 2.12 of [RFC9256]. | |||
| * RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be | * RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be | |||
| ignored by a receiver. | ignored by a receiver. | |||
| * Flags: 2-octet field that indicates attribute and status of the | * Flags: 2-octet field that indicates attribute and status of the | |||
| CP. The following bit positions are defined and the semantics are | CP. The following bit positions are defined and the semantics are | |||
| described in detail in [RFC9256]. Other bits MUST be cleared by | described in section 5 of [RFC9256] unless stated otherwise for | |||
| the originator and MUST be ignored by a receiver. | individual flags. Other bits MUST be cleared by the originator | |||
| and MUST be ignored by a receiver. | ||||
| 0 1 | 0 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |S|A|B|E|V|O|D|C|I|T|U| | | |S|A|B|E|V|O|D|C|I|T|U| | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - S-Flag: Indicates the CP is in an administrative shut state | - S-Flag: Indicates the CP is in an administrative shut state | |||
| when set | when set and not in administrative shut state when clear. | |||
| - A-Flag: Indicates the CP is the active path (i.e. one | - A-Flag: Indicates the CP is the active path (i.e. one | |||
| provisioned in the forwarding plane) for the SR Policy when set | provisioned in the forwarding plane as specified in section 2.9 | |||
| of [RFC9256]) for the SR Policy when set and not the active | ||||
| path when clear. | ||||
| - B-Flag: Indicates the CP is the backup path (i.e. one | - B-Flag: Indicates the CP is the backup path (i.e. one | |||
| identified for path protection of the active path) for the SR | identified for path protection of the active path as specified | |||
| Policy when set | in section 9.3 of [RFC9256]) for the SR Policy when set and not | |||
| the backup path when clear. | ||||
| - E-Flag: Indicates that the CP has been evaluated for validity | - E-Flag: Indicates that the CP has been evaluated for validity | |||
| (e.g. headend may evaluate CPs based on their preferences) when | (e.g. headend may evaluate CPs based on their preferences) when | |||
| set | set and has not been evaluated for validity when clear. | |||
| - V-Flag: Indicates the CP has at least one valid SID-List when | - V-Flag: Indicates the CP has at least one valid SID-List when | |||
| set. When the E-Flag is clear (i.e. the CP has not been | set and indicates no valid SID-List is available or evaluated | |||
| when clear. When the E-Flag is clear (i.e. the CP has not been | ||||
| evaluated), then this flag MUST be set to 0 by the originator | evaluated), then this flag MUST be set to 0 by the originator | |||
| and ignored by the receiver. | and ignored by the receiver. | |||
| - O-Flag: Indicates the CP was instantiated by the headend due to | - O-Flag: Indicates the CP was instantiated by the headend due to | |||
| an on-demand nexthop trigger based on a local template when | an on-demand nexthop trigger based on a local template when set | |||
| set. Refer to section 8.5 of [RFC9256] for details. | and that the CP has not been instantiated due to on-demand | |||
| nexthop trigger when clear. Refer to section 8.5 of [RFC9256] | ||||
| for details. | ||||
| - D-Flag: Indicates the CP was delegated for computation to a | - D-Flag: Indicates the CP was delegated for computation to a | |||
| PCE/controller when set | PCE/controller when set and indicates that the CP has not been | |||
| delegated for computation when clear. | ||||
| - C-Flag: Indicates the CP was provisioned by a PCE/controller | - C-Flag: Indicates the CP was provisioned by a PCE/controller | |||
| when set | when set and indicates that the CP was not provisioned by a | |||
| PCE/controller when clear. | ||||
| - I-Flag: Indicates the CP is to perform the "drop upon invalid" | - I-Flag: Indicates the CP is to perform the "drop upon invalid" | |||
| behavior when no other valid CP is available for this SR Policy | behavior when no other valid CP is available for this SR Policy | |||
| when the flag is set. Refer to section 8.2 of [RFC9256] for | when the flag is set. Refer to section 8.2 of [RFC9256] for | |||
| details. | details. When clear, it indicates that the CP is not enabled | |||
| for the "drop upon invalid" behavior. | ||||
| - T-Flag: Indicates the CP has been marked as eligible for use as | - T-Flag: Indicates the CP has been marked as eligible for use as | |||
| Transit Policy on the headend when set. Refer to section 8.3 | a transit policy on the headend when set and not eligible for | |||
| of [RFC9256]. | use as a transit policy when clear. Refer to section 8.3 of | |||
| [RFC9256]. | ||||
| - U-Flag: Indicates that this CP is reported as active and is | - U-Flag: Indicates that this CP is reported as active and is | |||
| dropping traffic as a result of the "drop upon invalid" | dropping traffic as a result of the "drop upon invalid" | |||
| behavior being activated for the SR Policy when set. | behavior being activated for the SR Policy when set. When | |||
| clear, it indicates that the CP is either dropping traffic as a | ||||
| result of the "drop upon invalid" behavior. Refer to section | ||||
| 8.2 of [RFC9256] for details. | ||||
| * Preference: 4-octet value which indicates the preference of the | * Preference: 4-octet value which indicates the preference of the | |||
| CP. Refer to section 2.7 of [RFC9256] for details. | CP. Refer to section 2.7 of [RFC9256] for details. | |||
| 5.4. SR Policy Name TLV | 5.4. SR Policy Name TLV | |||
| The SR Policy Name TLV is an optional TLV that is used to carry the | The SR Policy Name TLV is an optional TLV that is used to carry the | |||
| symbolic name associated with the SR Policy. Only a single instance | symbolic name associated with the SR Policy. Only a single instance | |||
| of this TLV is advertised for a given CP. If multiple instances are | of this TLV is advertised for a given CP. If multiple instances are | |||
| present, then the first one is considered valid and the rest are | present, then the first one is considered valid and the rest are | |||
| skipping to change at page 17, line 40 ¶ | skipping to change at page 17, line 47 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |D|P|U|A|T|S|F|H| | | |D|P|U|A|T|S|F|H| | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - D-Flag: Indicates that the CP uses SRv6 dataplane when set and | - D-Flag: Indicates that the CP uses SRv6 dataplane when set and | |||
| SR/MPLS dataplane when clear | SR/MPLS dataplane when clear | |||
| - P-Flag: Indicates that the CP prefers the use of only protected | - P-Flag: Indicates that the CP prefers the use of only protected | |||
| SIDs when set. This flag is mutually exclusive with the | SIDs when set and indicates that the CP does not prefer the use | |||
| U-Flag. | of only protected SIDs when clear. This flag is mutually | |||
| exclusive with the U-Flag (i.e., both these flags cannot be set | ||||
| at the same time). | ||||
| - U-Flag: Indicates that the CP prefers the use of only | - U-Flag: Indicates that the CP prefers the use of only | |||
| unprotected SIDs when set. This flag is mutually exclusive | unprotected SIDs when set and indicates that the CP does not | |||
| with the P-Flag. | prefer the use of only unprotected SIDs when clear. This flag | |||
| is mutually exclusive with the P-Flag (i.e., both these flags | ||||
| cannot be set at the same time). | ||||
| - A-Flag: Indicates that the CP uses only the SIDs belonging to | - A-Flag: Indicates that the CP uses only the SIDs belonging to | |||
| the specified SR Algorithm when set | the specified SR Algorithm when set and indicates that the CP | |||
| does not use only the SIDs belonging to the specified SR | ||||
| Algorithm when clear. | ||||
| - T-Flag: Indicates that the CP uses only the SIDs belonging to | - T-Flag: Indicates that the CP uses only the SIDs belonging to | |||
| the specified topology when set | the specified topology when set and indicates that the CP does | |||
| not use only the SIDs belonging to the specified topology when | ||||
| clear. | ||||
| - S-Flag: Indicates that the use of protected (P-Flag) or | - S-Flag: Indicates that the use of protected (P-Flag) or | |||
| unprotected (U-Flag) SIDs becomes a strict constraint instead | unprotected (U-Flag) SIDs becomes a strict constraint instead | |||
| of a preference when set | of a preference when set and indicates that there is no strict | |||
| constraint (and only a preference) when clear. | ||||
| - F-Flag: Indicates that the CP is fixed once computed and not | - F-Flag: Indicates that the CP is fixed once computed and not | |||
| modified except on operator intervention. | modified except on operator intervention and indicates that the | |||
| CP may be modified as part of recomputation when clear. | ||||
| - H-Flag: Indicates that the CP uses only adjacency SIDs and | - H-Flag: Indicates that the CP uses only adjacency SIDs and | |||
| traverses hop-by-hop over the links corresponding to those | traverses hop-by-hop over the links corresponding to those | |||
| adjacency SIDs when set | adjacency SIDs when set and indicates that the CP is not using | |||
| only hop-by-hop adjacency SIDs when clear. | ||||
| * RESERVED1: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED1: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * MTID: Indicates the multi-topology identifier of the IGP topology | * MTID: Indicates the multi-topology identifier of the IGP topology | |||
| that is preferred to be used when the path is set up. When the | that is preferred to be used when the path is set up. When the | |||
| T-flag is set then the path is strictly using the specified | T-flag is set then the path is strictly using the specified | |||
| topology SIDs only. | topology SIDs only. | |||
| * Algorithm: Indicates the algorithm that is preferred to be used | * Algorithm: Indicates the algorithm that is preferred to be used | |||
| skipping to change at page 22, line 4 ¶ | skipping to change at page 22, line 18 ¶ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Request-Flags | Status-Flags | RESERVED | | | Request-Flags | Status-Flags | RESERVED | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Disjoint Group Identifier (variable) // | | Disjoint Group Identifier (variable) // | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| * Type: 1211 | * Type: 1211 | |||
| * Length: Variable. Minimum of 8 octets. | * Length: Variable. Minimum of 8 octets. | |||
| * Request Flags: one octet to indicate the level of disjointness | * Request Flags: one octet to indicate the level of disjointness | |||
| requested as specified in the form of flags. The following flags | requested as specified in the form of flags. The following flags | |||
| are defined and the other bits MUST be cleared by the originator | are defined and the other bits MUST be cleared by the originator | |||
| and MUST be ignored by a receiver. | and MUST be ignored by a receiver. | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |S|N|L|F|I| | | |S|N|L|F|I| | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - S-Flag: Indicates that SRLG disjointness is requested when set | - S-Flag: Indicates that SRLG disjointness is requested when set | |||
| and indicates that SRLG disjointness is not requested when | ||||
| clear. | ||||
| - N-Flag: Indicates that node disjointness is requested when set | - N-Flag: Indicates that node disjointness is requested when set | |||
| and indicates that node disjointness is not requested when | ||||
| clear. | ||||
| - L-Flag: Indicates that link disjointness is requested when set | - L-Flag: Indicates that link disjointness is requested when set | |||
| and indicates that the link disjointness is not requested when | ||||
| clear. | ||||
| - F-Flag: Indicates that the computation may fallback to a lower | - F-Flag: Indicates that the computation may fallback to a lower | |||
| level of disjointness amongst the ones requested when all | level of disjointness amongst the ones requested when all | |||
| cannot be achieved when set | cannot be achieved when set and indicates that fallback to a | |||
| lower level of disjointness is not allowed when clear. | ||||
| - I-Flag: Indicates that the computation may fallback to the | - I-Flag: Indicates that the computation may fallback to the | |||
| default best path (e.g. IGP path) in case of none of the | default best path (e.g. IGP path) in case of none of the | |||
| desired disjointness can be achieved when set | desired disjointness can be achieved when set and indicates | |||
| that fallback to the default best path is not allowed when | ||||
| clear. | ||||
| * Status Flags: one octet to indicate the level of disjointness that | * Status Flags: one octet to indicate the level of disjointness that | |||
| has been achieved by the computation as specified in the form of | has been achieved by the computation as specified in the form of | |||
| flags. The following flags are defined and the other bits MUST be | flags. The following flags are defined and the other bits MUST be | |||
| cleared by the originator and MUST be ignored by a receiver. | cleared by the originator and MUST be ignored by a receiver. | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |S|N|L|F|I|X| | | |S|N|L|F|I|X| | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - S-Flag: Indicates that SRLG disjointness is achieved when set | - S-Flag: Indicates that SRLG disjointness is achieved when set | |||
| and indicates that SRLG disjointness is not achieved when | ||||
| clear. | ||||
| - N-Flag: Indicates that node disjointness is achieved when set | - N-Flag: Indicates that node disjointness is achieved when set | |||
| and indicates that node disjointness was not achieved when | ||||
| clear. | ||||
| - L-Flag: Indicates that link disjointness is achieved when set | - L-Flag: Indicates that link disjointness is achieved when set | |||
| and indicates that link disjointness was not achieved when | ||||
| clear. | ||||
| - F-Flag: Indicates that the computation has fallen back to a | - F-Flag: Indicates that the computation has fallen back to a | |||
| lower level of disjointness than requested when set | lower level of disjointness than requested when set and | |||
| indicates that there has been no fallback to a lower level of | ||||
| disjointness when clear. | ||||
| - I-Flag: Indicates that the computation has fallen back to the | - I-Flag: Indicates that the computation has fallen back to the | |||
| best path (e.g. IGP path) and disjointness has not been | best path (e.g. IGP path) and disjointness has not been | |||
| achieved when set | achieved when set and indicates that there has been no fallback | |||
| to best path when clear. | ||||
| - X-Flag : Indicates that the disjointness constraint could not | - X-Flag : Indicates that the disjointness constraint could not | |||
| be achieved and hence path has been invalidated when set | be achieved and hence path has been invalidated when set and | |||
| indicates that the path has not been invalidated due to unmet | ||||
| disjointness constraints when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Disjointness Group Identifier: 4-octet value that is the group | * Disjointness Group Identifier: 4-octet value that is the group | |||
| identifier for a set of disjoint paths. A PCEP Association Object | identifier for a set of disjoint paths. A PCEP Association Object | |||
| [RFC8697] (including its optional TLVs) MAY also be advertised to | [RFC8697] (including its optional TLVs) MAY also be advertised to | |||
| convey the disjoint group identifier. | convey the disjoint group identifier. | |||
| 5.6.5. SR Bidirectional Group Constraint Sub-TLV | 5.6.5. SR Bidirectional Group Constraint Sub-TLV | |||
| skipping to change at page 24, line 23 ¶ | skipping to change at page 25, line 10 ¶ | |||
| |R|C| | | |R|C| | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - R-Flag: Indicates that this CP of the SR Policy forms the | - R-Flag: Indicates that this CP of the SR Policy forms the | |||
| reverse path when the R-Flag is set. If the R-Flag is clear, | reverse path when the R-Flag is set. If the R-Flag is clear, | |||
| this CP forms the forward path. | this CP forms the forward path. | |||
| - C-Flag: Indicates that the bidirectional path is co-routed when | - C-Flag: Indicates that the bidirectional path is co-routed when | |||
| set | set and indicates that the bidirectional path is not co-routed | |||
| when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Bidirectional Group Identifier: 4-octet value that is the group | * Bidirectional Group Identifier: 4-octet value that is the group | |||
| identifier for a set of bidirectional paths. A PCEP Association | identifier for a set of bidirectional paths. A PCEP Association | |||
| Object [RFC8697] (including its optional TLVs) MAY also be | Object [RFC8697] (including its optional TLVs) MAY also be | |||
| advertised to convey the bidirectional group identifier. | advertised to convey the bidirectional group identifier. The PCEP | |||
| Association Object MUST NOT be encoded and this sub-TLV skipped | ||||
| along with an error log, if the object size is such that the | ||||
| update for a single SR Policy CP NLRI would exceed the supported | ||||
| BGP message size by the implementation. Refer section 5.3 of | ||||
| [RFC9552] for discussion on implications of encoding large sets of | ||||
| information into BGP-LS. | ||||
| 5.6.6. SR Metric Constraint Sub-TLV | 5.6.6. SR Metric Constraint Sub-TLV | |||
| The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR CP | The SR Metric Constraint sub-TLV is an optional sub-TLV of the SR CP | |||
| Constraints TLV that is used to report the optimization metric of the | Constraints TLV that is used to report the optimization metric of the | |||
| CP. For a dynamic path computation, it is used to report the | CP. For a dynamic path computation, it is used to report the | |||
| optimization metric used along with its parameters. For an explicit | optimization metric used along with its parameters. For an explicit | |||
| path, this sub-TLV MAY be used to report the metric margin or bound | path, this sub-TLV MAY be used to report the metric margin or bound | |||
| to be used for validation (i.e., the path is invalidated if the | to be used for validation (i.e., the path is invalidated if the | |||
| metric is beyond specified values). Multiple instances of this sub- | metric is beyond specified values). Multiple instances of this sub- | |||
| skipping to change at page 25, line 40 ¶ | skipping to change at page 26, line 26 ¶ | |||
| MUST be ignored by a receiver. | MUST be ignored by a receiver. | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |O|M|A|B| | | |O|M|A|B| | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - O-Flag: Indicates that this is the optimization metric being | - O-Flag: Indicates that this is the optimization metric being | |||
| reported for a dynamic CP when set. This bit MUST NOT be set | reported for a dynamic CP when set and indicates that the | |||
| in more than one instance of this TLV for a given CP | metric is not the optimization metric when clear. This bit | |||
| advertisement. | MUST NOT be set in more than one instance of this TLV for a | |||
| given CP advertisement. | ||||
| - M-Flag: Indicates that the metric margin allowed is specified | - M-Flag: Indicates that the metric margin allowed is specified | |||
| when set. | when set and indicates that metric margin allowed is not | |||
| specified when clear. | ||||
| - A-Flag: Indicates that the metric margin is specified as an | - A-Flag: Indicates that the metric margin is specified as an | |||
| absolute value when set and is expressed as a percentage of the | absolute value when set and is expressed as a percentage of the | |||
| minimum metric when clear. | minimum metric when clear. | |||
| - B-Flag: Indicates that the metric bound allowed for the path is | - B-Flag: Indicates that the metric bound allowed for the path is | |||
| specified when set. | specified when set and indicates that metric bound is not | |||
| specified when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Metric Margin: 4-octet value which indicates the metric margin | * Metric Margin: 4-octet value which indicates the metric margin | |||
| when the M-flag is set. The metric margin is specified as either | when the M-flag is set. The metric margin is specified as either | |||
| an absolute value or as a percentage of the minimum computed path | an absolute value or as a percentage of the minimum computed path | |||
| metric based on the A-flag. The metric margin loosens the | metric based on the A-flag. The metric margin loosens the | |||
| criteria for minimum metric path calculation up to the specified | criteria for minimum metric path calculation up to the specified | |||
| metric to accommodate for other factors such as bandwidth | metric to accommodate for other factors such as bandwidth | |||
| skipping to change at page 27, line 28 ¶ | skipping to change at page 28, line 24 ¶ | |||
| set and indicates it is comprised of SR/MPLS labels when clear. | set and indicates it is comprised of SR/MPLS labels when clear. | |||
| - E-Flag: Indicates that SID-List is associated with an explicit | - E-Flag: Indicates that SID-List is associated with an explicit | |||
| candidate path when set and with a dynamic candidate path when | candidate path when set and with a dynamic candidate path when | |||
| clear. All segment lists of a given candidate path MUST be | clear. All segment lists of a given candidate path MUST be | |||
| either explicit or dynamic and in case of inconsistency, the | either explicit or dynamic and in case of inconsistency, the | |||
| receiver MAY consider them all to be dynamic. | receiver MAY consider them all to be dynamic. | |||
| - C-Flag: Indicates that SID-List has been computed for a dynamic | - C-Flag: Indicates that SID-List has been computed for a dynamic | |||
| path when set. It is always reported as set for explicit | path when set. It is always reported as set for explicit | |||
| paths. | paths. When clear, it indicates that the SID-List has not been | |||
| computed for a dynamic path. | ||||
| - V-Flag: Indicates the SID-List has passed verification or its | - V-Flag: Indicates the SID-List has passed verification or its | |||
| verification was not required when set and failed verification | verification was not required when set and failed verification | |||
| when clear. | when clear. | |||
| - R-Flag: Indicates that the first Segment has been resolved when | - R-Flag: Indicates that the first Segment has been resolved when | |||
| set and failed resolution when clear. | set and failed resolution when clear. | |||
| - F-Flag: Indicates that the computation for the dynamic path | - F-Flag: Indicates that the computation for the dynamic path | |||
| failed when set and succeeded (or not required in case of | failed when set and succeeded (or not required in case of | |||
| explicit path) when clear | explicit path) when clear. | |||
| - A-Flag: Indicates that all the SIDs in the SID-List belong to | - A-Flag: Indicates that all the SIDs in the SID-List belong to | |||
| the specified algorithm when set. | the specified algorithm when set and indicates that not all the | |||
| SIDs belong to the specified algorithm when clear. | ||||
| - T-Flag: Indicates that all the SIDs in the SID-List belong to | - T-Flag: Indicates that all the SIDs in the SID-List belong to | |||
| the specified topology (identified by the multi-topology ID) | the specified topology (identified by the multi-topology ID) | |||
| when set. | when set and indicates that not all the SIDs belong to the | |||
| specified topology when clear. | ||||
| - M-Flag: Indicates that the SID-list has been removed from the | - M-Flag: Indicates that the SID-list has been removed from the | |||
| forwarding plane due to fault detection by a monitoring | forwarding plane due to fault detection by a monitoring | |||
| mechanism (e.g. BFD) when set and indicates no fault detected | mechanism (e.g. BFD) when set and indicates no fault detected | |||
| or monitoring is not being done when clear. | or monitoring is not being done when clear. | |||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * MTID: 2 octets that indicates the multi-topology identifier of the | * MTID: 2 octets that indicates the multi-topology identifier of the | |||
| skipping to change at page 29, line 35 ¶ | skipping to change at page 30, line 35 ¶ | |||
| * Segment Type: 1 octet which indicates the type of segment. | * Segment Type: 1 octet which indicates the type of segment. | |||
| Initial values are specified by this document (see Section 5.8.1 | Initial values are specified by this document (see Section 5.8.1 | |||
| for details). Additional segment types are possible, but out of | for details). Additional segment types are possible, but out of | |||
| scope for this document. | scope for this document. | |||
| * RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be | * RESERVED: 1 octet. MUST be set to 0 by the originator and MUST be | |||
| ignored by a receiver. | ignored by a receiver. | |||
| * Flags: 2-octet field that indicates attribute and status of the | * Flags: 2-octet field that indicates attribute and status of the | |||
| Segment and its SID. The following bit positions are defined and | Segment and its SID. The following bit positions are defined and | |||
| the semantics are described in detail in [RFC9256]. Other bits | the semantics are described in section 5 of [RFC9256]. Other bits | |||
| MUST be cleared by the originator and MUST be ignored by a | MUST be cleared by the originator and MUST be ignored by a | |||
| receiver. | receiver. | |||
| 0 1 | 0 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |S|E|V|R|A| | | |S|E|V|R|A| | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| skipping to change at page 38, line 45 ¶ | skipping to change at page 39, line 45 ¶ | |||
| MUST be ignored by a receiver. | MUST be ignored by a receiver. | |||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |M|A|B|V| | | |M|A|B|V| | | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| - M-Flag: Indicates that the metric margin allowed for this path | - M-Flag: Indicates that the metric margin allowed for this path | |||
| computation is specified when set | computation is specified when set and indicates that metric | |||
| margin allowed is not specified when clear. | ||||
| - A-Flag: Indicates that the metric margin is specified as an | - A-Flag: Indicates that the metric margin is specified as an | |||
| absolute value when set and is expressed as a percentage of the | absolute value when set and is expressed as a percentage of the | |||
| minimum metric when clear. | minimum metric when clear. | |||
| - B-Flag: Indicates that the metric bound allowed for the path is | - B-Flag: Indicates that the metric bound allowed for the path is | |||
| specified when set. | specified when set and indicates that metric bound is not | |||
| specified when clear. | ||||
| - V-Flag: Indicates that the metric value computed is being | - V-Flag: Indicates that the metric value computed is being | |||
| reported when set. | reported when set and indicates that the computed metric value | |||
| is not being reported when clear. | ||||
| * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | * RESERVED: 2 octets. MUST be set to 0 by the originator and MUST | |||
| be ignored by a receiver. | be ignored by a receiver. | |||
| * Metric Margin: 4-octet value which indicates the metric margin | * Metric Margin: 4-octet value which indicates the metric margin | |||
| value when the M-flag is set. The metric margin is specified as | value when the M-flag is set. The metric margin is specified as | |||
| either an absolute value or as a percentage of the minimum | either an absolute value or as a percentage of the minimum | |||
| computed path metric based on the A-flag. The metric margin | computed path metric based on the A-flag. The metric margin | |||
| loosens the criteria for minimum metric path calculation up to the | loosens the criteria for minimum metric path calculation up to the | |||
| specified metric to accomodate for other factors such as bandwidth | specified metric to accomodate for other factors such as bandwidth | |||
| End of changes. 56 change blocks. | ||||
| 80 lines changed or deleted | 146 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||