| draft-ietf-idr-segment-routing-te-policy-00.txt | draft-ietf-idr-segment-routing-te-policy-01.txt | |||
|---|---|---|---|---|
| Network Working Group S. Previdi, Ed. | Network Working Group S. Previdi, Ed. | |||
| Internet-Draft C. Filsfils | Internet-Draft C. Filsfils | |||
| Intended status: Standards Track Cisco Systems, Inc. | Intended status: Standards Track Cisco Systems, Inc. | |||
| Expires: January 21, 2018 P. Mattes | Expires: June 16, 2018 P. Mattes | |||
| Microsoft | Microsoft | |||
| E. Rosen | E. Rosen | |||
| Juniper Networks | Juniper Networks | |||
| S. Lin | S. Lin | |||
| July 20, 2017 | December 13, 2017 | |||
| Advertising Segment Routing Policies in BGP | Advertising Segment Routing Policies in BGP | |||
| draft-ietf-idr-segment-routing-te-policy-00 | draft-ietf-idr-segment-routing-te-policy-01 | |||
| Abstract | Abstract | |||
| This document defines a new BGP SAFI with a new NLRI in order to | This document defines a new BGP SAFI with a new NLRI in order to | |||
| advertise a candidate path of a Segment Routing Policy (SR Policy). | advertise a candidate path of a Segment Routing Policy (SR Policy). | |||
| An SR Policy is a set of candidate paths consisting of one or more | An SR Policy is a set of candidate paths consisting of one or more | |||
| segment lists. The headend of an SR Policy may learn multiple | segment lists. The headend of an SR Policy may learn multiple | |||
| candidate paths for an SR Policy. Candidate paths may be learned via | candidate paths for an SR Policy. Candidate paths may be learned via | |||
| a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. | a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. | |||
| This document specifies the way in which BGP may be used to | This document specifies the way in which BGP may be used to | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| Encapsulation Attribute are defined. | Encapsulation Attribute are defined. | |||
| 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 http://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 January 21, 2018. | This Internet-Draft will expire on June 16, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
| 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5 | 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5 | 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5 | |||
| 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7 | 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7 | |||
| 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 | 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 | |||
| 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 8 | 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 8 | |||
| 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 8 | 2.4.1. Preference sub-TLV . . . . . . . . . . . . . . . . . 8 | |||
| 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 9 | 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 9 | |||
| 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 | 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 | |||
| 3. Extended Color Community . . . . . . . . . . . . . . . . . . 21 | 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 21 | |||
| 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 21 | 3. Extended Color Community . . . . . . . . . . . . . . . . . . 22 | |||
| 4.1. Configuration and Advertisement of SR TE Policies . . . . 22 | 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 23 | |||
| 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 22 | 4.1. Configuration and Advertisement of SR TE Policies . . . . 23 | |||
| 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 22 | 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 23 | |||
| 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 23 | 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 23 | |||
| 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 24 | 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 24 | |||
| 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 24 | 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 25 | |||
| 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 24 | 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 25 | |||
| 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 25 | |||
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | ||||
| 8.1. Existing Registry: Subsequent Address Family Identifiers | 8.1. Existing Registry: Subsequent Address Family Identifiers | |||
| (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 26 | (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute | 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute | |||
| Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 26 | Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute | 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute | |||
| sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 27 | sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 27 | 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 28 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | ||||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 10.2. Informational References . . . . . . . . . . . . . . . . 28 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | 10.2. Informational References . . . . . . . . . . . . . . . . 30 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
| 1. Introduction | 1. Introduction | |||
| Segment Routing (SR) allows a headend node to steer a packet flow | Segment Routing (SR) allows a headend node to steer a packet flow | |||
| along any path. Intermediate per-flow states are eliminated thanks | along any path. Intermediate per-flow states are eliminated thanks | |||
| to source routing [I-D.ietf-spring-segment-routing]. | to source routing [I-D.ietf-spring-segment-routing]. | |||
| The headend node is said to steer a flow into an Segment Routing | The headend node is said to steer a flow into an Segment Routing | |||
| Policy (SR Policy). | Policy (SR Policy). | |||
| skipping to change at page 8, line 48 ¶ | skipping to change at page 8, line 48 ¶ | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | Flags | RESERVED | | | Type | Length | Flags | RESERVED | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Preference (4 octets) | | | Preference (4 octets) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| o Type: TBD3 (to be assigned by IANA from the "BGP Tunnel | o Type: 12 | |||
| Encapsulation Attribute sub-TLVs" registry). | ||||
| o Length: 6. | o Length: 6. | |||
| o Flags: 1 octet of flags. None are defined at this stage. Flags | o Flags: 1 octet of flags. None are defined at this stage. Flags | |||
| SHOULD be set to zero on transmission and MUST be ignored on | SHOULD be set to zero on transmission and MUST be ignored on | |||
| receipt. | receipt. | |||
| o RESERVED: 1 octet of reserved bits. SHOULD be unset on | o RESERVED: 1 octet of reserved bits. SHOULD be unset on | |||
| transmission and MUST be ignored on receipt. | transmission and MUST be ignored on receipt. | |||
| skipping to change at page 9, line 33 ¶ | skipping to change at page 9, line 33 ¶ | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | Flags | RESERVED | | | Type | Length | Flags | RESERVED | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Binding SID (variable, optional) | | | Binding SID (variable, optional) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| o Type: TBD4 (to be assigned by IANA from the "BGP Tunnel | o Type: 13 | |||
| Encapsulation Attribute sub-TLVs" registry). | ||||
| o Length: specifies the length of the value field not including Type | o Length: specifies the length of the value field not including Type | |||
| and Length fields. Can be 2 or 6 or 18. | and Length fields. Can be 2 or 6 or 18. | |||
| o Flags: 1 octet of flags. None are defined at this stage. Flags | o Flags: 1 octet of flags. None are defined at this stage. Flags | |||
| SHOULD be set to zero on transmission and MUST be ignored on | SHOULD be set to zero on transmission and MUST be ignored on | |||
| receipt. | receipt. | |||
| o RESERVED: 1 octet of reserved bits. SHOULD be unset on | o RESERVED: 1 octet of reserved bits. SHOULD be unset on | |||
| transmission and MUST be ignored on receipt. | transmission and MUST be ignored on receipt. | |||
| o Binding SID: if length is 2, then no Binding SID is present. If | o Binding SID: if length is 2, then no Binding SID is present. | |||
| length is 6 then the Binding SID contains a 4-octet SID. If | ||||
| length is 18 then the Binding SID contains a 16-octet IPv6 SID. | o If length is 6 then the Binding SID contains a 4-octet SID. Below | |||
| format is used to encode the SID. TC, S, TTL(Total of 12bits) are | ||||
| RESERVED and SHOULD be set to Zero and MUST be ignored. | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Label | TC |S| TTL | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| If length is 18 then the Binding SID contains a 16-octet IPv6 SID. | ||||
| 2.4.3. Segment List Sub-TLV | 2.4.3. Segment List Sub-TLV | |||
| The Segment List TLV encodes a single explicit path towards the | The Segment List TLV encodes a single explicit path towards the | |||
| endpoint. The Segment List sub-TLV includes the elements of the | endpoint. The Segment List sub-TLV includes the elements of the | |||
| paths (i.e.: segments) as well as an optional Weight TLV. | paths (i.e.: segments) as well as an optional Weight TLV. | |||
| The Segment List sub-TLV may exceed 255 bytes length due to large | The Segment List sub-TLV may exceed 255 bytes length due to large | |||
| number of segments. Therefore a 2-octet length is required. | number of segments. Therefore a 2-octet length is required. | |||
| According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- | According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at page 10, line 44 ¶ | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | RESERVED | | | Type | Length | RESERVED | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| // sub-TLVs // | // sub-TLVs // | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| o Type: TBD5 (to be assigned by IANA from the "BGP Tunnel | o Type: 128. | |||
| Encapsulation Attribute sub-TLVs" registry). | ||||
| o Length: the total length (not including the Type and Length | o Length: the total length (not including the Type and Length | |||
| fields) of the sub-TLVs encoded within the Segment List sub-TLV. | fields) of the sub-TLVs encoded within the Segment List sub-TLV. | |||
| o RESERVED: 1 octet of reserved bits. SHOULD be unset on | o RESERVED: 1 octet of reserved bits. SHOULD be unset on | |||
| transmission and MUST be ignored on receipt. | transmission and MUST be ignored on receipt. | |||
| o sub-TLVs: | o sub-TLVs: | |||
| * An optional single Weight sub-TLV. | * An optional single Weight sub-TLV. | |||
| skipping to change at page 21, line 27 ¶ | skipping to change at page 21, line 27 ¶ | |||
| o If length is 34, then only the IPv6 Local and Remote addresses are | o If length is 34, then only the IPv6 Local and Remote addresses are | |||
| present. | present. | |||
| o If length is 38, then the IPv6 Local address, IPv4 Remote address | o If length is 38, then the IPv6 Local address, IPv4 Remote address | |||
| and the MPLS SID are present. | and the MPLS SID are present. | |||
| o If length is 50, then the IPv6 Local address, IPv4 Remote address | o If length is 50, then the IPv6 Local address, IPv4 Remote address | |||
| and the IPv6 SID are present. | and the IPv6 SID are present. | |||
| 2.4.4. Explicit NULL Label Policy Sub-TLV | ||||
| In order to steer an unlabeled IP packet into an SR policy, it is | ||||
| necessary to create a label stack for that packet, and to push one or | ||||
| more labels onto that stack. | ||||
| The Explicit NULL Label Policy sub-TLV is used to indicate whether an | ||||
| Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP | ||||
| packet before any other labels. | ||||
| If an Explicit NULL Label Policy Sub-TLV is not present, the decision | ||||
| of whether to push an Explicit NULL label on a given packet is a | ||||
| matter of local policy. | ||||
| The contents of this sub-TLV are used by the SRTE | ||||
| process[I-D.filsfils-spring-segment-routing-policy] | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type | Length | Flags | RESERVED | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | ENLP | | ||||
| +-+-+-+-+-+-+-+-+ | ||||
| Where: | ||||
| Type: TBD (to be assigned by IANA from the registry "SR Policy | ||||
| List Sub-TLVs" defined in this document). | ||||
| Length: 3. | ||||
| Flags: 1 octet of flags. None are defined at this stage. Flags | ||||
| SHOULD be set to zero on transmission and MUST be ignored on | ||||
| receipt. | ||||
| RESERVED: 1 octet of reserved bits. SHOULD be unset on | ||||
| transmission and MUST be ignored on receipt. | ||||
| ELNP(Explicit NULL Label Policy): Indicates whether Explicit NULL | ||||
| labels are to be pushed on unlabled IP packets that are being | ||||
| steered into a given SR policy. This field has one of the | ||||
| following 4 values: | ||||
| 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 | ||||
| packet, but do not push an IPv6 Explicit NULL label on an | ||||
| unlabeled IPv6 packet. | ||||
| 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 | ||||
| packet, but do not push an IPv4 Explicit NULL label on an | ||||
| unlabeled IPv4 packet. | ||||
| 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 | ||||
| packet, and push an IPv6 Explicit NULL label on an unlabeled | ||||
| IPv6 packet. | ||||
| 4: Do not push an Explicit NULL label. | ||||
| The policy signaled in this Sub-TLV MAY be overridden by local | ||||
| policy. | ||||
| 3. Extended Color Community | 3. Extended Color Community | |||
| The Color Extended Community as defined in | The Color Extended Community as defined in | |||
| [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. | [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. | |||
| When the Color Extended Community is used for the purpose of steering | When the Color Extended Community is used for the purpose of steering | |||
| the traffic into an SRTE policy, the RESERVED field (as defined in | the traffic into an SRTE policy, the RESERVED field (as defined in | |||
| [I-D.ietf-idr-tunnel-encaps] is changed as follows: | [I-D.ietf-idr-tunnel-encaps] is changed as follows: | |||
| 1 | 1 | |||
| skipping to change at page 22, line 43 ¶ | skipping to change at page 24, line 5 ¶ | |||
| it's first acceptable, then it determines if it is usable. | it's first acceptable, then it determines if it is usable. | |||
| 4.2.1. Acceptance of an SR Policy NLRI | 4.2.1. Acceptance of an SR Policy NLRI | |||
| When a BGP speaker receives an SR Policy NLRI from a neighbor it has | When a BGP speaker receives an SR Policy NLRI from a neighbor it has | |||
| to determine if it's acceptable. The following applies: | to determine if it's acceptable. The following applies: | |||
| o The SR Policy NLRI MUST include a distinguisher, color and | o The SR Policy NLRI MUST include a distinguisher, color and | |||
| endpoint field which implies that the length of the NLRI MUST be | endpoint field which implies that the length of the NLRI MUST be | |||
| either 12 or 24 octets (depending on the address family of the | either 12 or 24 octets (depending on the address family of the | |||
| endpoint). If the NLRI is not one of the legal lengths, a router | endpoint). | |||
| supporting this document and that imports the route MUST consider | ||||
| it to be malformed and MUST apply the "treat-as-withdraw" strategy | ||||
| of [RFC7606]. | ||||
| o The SR Policy update MUST have either the NO_ADVERTISE community | o The SR Policy update MUST have either the NO_ADVERTISE community | |||
| or at least one route-target extended community in IPv4-address | or at least one route-target extended community in IPv4-address | |||
| format. If a router supporting this document receives an SR | format. If a router supporting this document receives an SR | |||
| policy update with no route-target extended communities and no | policy update with no route-target extended communities and no | |||
| NO_ADVERTISE community, the update MUST NOT be sent to the SRTE | NO_ADVERTISE community, the update MUST NOT be sent to the SRTE | |||
| process. Furthermore, it SHOULD be considered to be malformed, | process. Furthermore, it SHOULD be considered to be malformed, | |||
| and the "treat-as-withdraw" strategy of [RFC7606] applied. | and the "treat-as-withdraw" strategy of [RFC7606] applied. | |||
| o The Tunnel Encapsulation Attribute MUST be attached to the BGP | o The Tunnel Encapsulation Attribute MUST be attached to the BGP | |||
| skipping to change at page 23, line 36 ¶ | skipping to change at page 24, line 43 ¶ | |||
| the Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR | the Endpoint of the SR Policy SAFI NLRI. If they don't match, the SR | |||
| Policy advertisement MUST be considered as unacceptable. If present, | Policy advertisement MUST be considered as unacceptable. If present, | |||
| the Color sub-TLV MUST match the Policy Color of the SR Policy SAFI | the Color sub-TLV MUST match the Policy Color of the SR Policy SAFI | |||
| NLRI. If they don't match, the SR Policy advertisement MUST be | NLRI. If they don't match, the SR Policy advertisement MUST be | |||
| considered as unacceptable. | considered as unacceptable. | |||
| A unacceptable SR Policy update that has a valid NLRI portion with | A unacceptable SR Policy update that has a valid NLRI portion with | |||
| invalid attribute portion MUST be considered as a withdraw of the SR | invalid attribute portion MUST be considered as a withdraw of the SR | |||
| Policy. | Policy. | |||
| A unacceptable SR Policy update that has an invalid NLRI portion MUST | ||||
| trigger a reset of the BGP session. | ||||
| 4.2.2. Usable SR Policy NLRI | 4.2.2. Usable SR Policy NLRI | |||
| If one or more route-targets are present, then at least one route- | If one or more route-targets are present, then at least one route- | |||
| target MUST match one of the BGP Identifiers of the receiver in order | target MUST match one of the BGP Identifiers of the receiver in order | |||
| for the update to be considered usable. The BGP Identifier is | for the update to be considered usable. The BGP Identifier is | |||
| defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- | defined in [RFC4271] as a 4 octet IPv4 address. Therefore the route- | |||
| target extended community MUST be of the same format. | target extended community MUST be of the same format. | |||
| If one or more route-targets are present and no one matches any of | If one or more route-targets are present and no one matches any of | |||
| the local BGP Identifiers, then, while the SR Policy NLRI is | the local BGP Identifiers, then, while the SR Policy NLRI is | |||
| skipping to change at page 25, line 28 ¶ | skipping to change at page 26, line 37 ¶ | |||
| US | US | |||
| Email: msiva@cisco.com | Email: msiva@cisco.com | |||
| Imtiyaz Mohammad | Imtiyaz Mohammad | |||
| Arista Networks | Arista Networks | |||
| India | India | |||
| Email: imtiyaz@arista.com | Email: imtiyaz@arista.com | |||
| Gaurav Dawra | ||||
| Cisco Systems | ||||
| US | ||||
| Email: gdawra@cisco.com | ||||
| 6. Acknowledgments | 6. Acknowledgments | |||
| The authors of this document would like to thank Shyam Sethuram and | The authors of this document would like to thank Shyam Sethuram and | |||
| John Scudder for their comments and review of this document. | John Scudder for their comments and review of this document. | |||
| 7. Implementation Status | 7. Implementation Status | |||
| Note to RFC Editor: Please remove this section prior to publication, | Note to RFC Editor: Please remove this section prior to publication, | |||
| as well as the reference to RFC 7942. | as well as the reference to RFC 7942. | |||
| skipping to change at page 27, line 16 ¶ | skipping to change at page 28, line 31 ¶ | |||
| -------------------------------------------------- | -------------------------------------------------- | |||
| 15 SR Policy Type This document | 15 SR Policy Type This document | |||
| 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs | 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs | |||
| This document defines new sub-TLVs in the registry "BGP Tunnel | This document defines new sub-TLVs in the registry "BGP Tunnel | |||
| Encapsulation Attribute sub-TLVs" to be assigned by IANA: | Encapsulation Attribute sub-TLVs" to be assigned by IANA: | |||
| Codepoint Description Reference | Codepoint Description Reference | |||
| ------------------------------------------------------ | ------------------------------------------------------ | |||
| TBD3 Preference sub-TLV This document | 12 Preference sub-TLV This document | |||
| TBD4 Binding SID sub-TLV This document | 13 Binding SID sub-TLV This document | |||
| TBD5 Segment List sub-TLV This document | 128 Segment List sub-TLV This document | |||
| 8.4. New Registry: SR Policy List Sub-TLVs | 8.4. New Registry: SR Policy List Sub-TLVs | |||
| This document defines a new registry called "SR Policy List Sub- | This document defines a new registry called "SR Policy List Sub- | |||
| TLVs". The allocation policy of this registry is "First Come First | TLVs". The allocation policy of this registry is "First Come First | |||
| Served (FCFS)" according to [RFC8126]. | Served (FCFS)" according to [RFC8126]. | |||
| Following Sub-TLV codepoints are defined: | Following Sub-TLV codepoints are defined: | |||
| Value Description Reference | Value Description Reference | |||
| skipping to change at page 28, line 8 ¶ | skipping to change at page 29, line 33 ¶ | |||
| 10.1. Normative References | 10.1. Normative References | |||
| [I-D.ietf-idr-tunnel-encaps] | [I-D.ietf-idr-tunnel-encaps] | |||
| Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel | Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel | |||
| Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 | Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 | |||
| (work in progress), July 2017. | (work in progress), July 2017. | |||
| [I-D.ietf-pce-segment-routing] | [I-D.ietf-pce-segment-routing] | |||
| Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | |||
| and J. Hardwick, "PCEP Extensions for Segment Routing", | and J. Hardwick, "PCEP Extensions for Segment Routing", | |||
| draft-ietf-pce-segment-routing-09 (work in progress), | draft-ietf-pce-segment-routing-11 (work in progress), | |||
| April 2017. | November 2017. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <http://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | ||||
| Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | ||||
| Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, | ||||
| <https://www.rfc-editor.org/info/rfc3032>. | ||||
| [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | |||
| Border Gateway Protocol 4 (BGP-4)", RFC 4271, | Border Gateway Protocol 4 (BGP-4)", RFC 4271, | |||
| DOI 10.17487/RFC4271, January 2006, | DOI 10.17487/RFC4271, January 2006, | |||
| <http://www.rfc-editor.org/info/rfc4271>. | <https://www.rfc-editor.org/info/rfc4271>. | |||
| [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
| Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | |||
| February 2006, <http://www.rfc-editor.org/info/rfc4360>. | February 2006, <https://www.rfc-editor.org/info/rfc4360>. | |||
| [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | |||
| "Multiprotocol Extensions for BGP-4", RFC 4760, | "Multiprotocol Extensions for BGP-4", RFC 4760, | |||
| DOI 10.17487/RFC4760, January 2007, | DOI 10.17487/RFC4760, January 2007, | |||
| <http://www.rfc-editor.org/info/rfc4760>. | <https://www.rfc-editor.org/info/rfc4760>. | |||
| [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., | [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., | |||
| and D. McPherson, "Dissemination of Flow Specification | and D. McPherson, "Dissemination of Flow Specification | |||
| Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, | Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, | |||
| <http://www.rfc-editor.org/info/rfc5575>. | <https://www.rfc-editor.org/info/rfc5575>. | |||
| [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. | [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. | |||
| Patel, "Revised Error Handling for BGP UPDATE Messages", | Patel, "Revised Error Handling for BGP UPDATE Messages", | |||
| RFC 7606, DOI 10.17487/RFC7606, August 2015, | RFC 7606, DOI 10.17487/RFC7606, August 2015, | |||
| <http://www.rfc-editor.org/info/rfc7606>. | <https://www.rfc-editor.org/info/rfc7606>. | |||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <http://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| 10.2. Informational References | 10.2. Informational References | |||
| [I-D.filsfils-spring-segment-routing-policy] | [I-D.filsfils-spring-segment-routing-policy] | |||
| Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, | Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, | |||
| F., Lin, S., bogdanov@google.com, b., Horneffer, M., | F., Hegde, S., Lin, S., bogdanov@google.com, b., | |||
| Steinberg, D., Decraene, B., and S. Litkowski, "Segment | Horneffer, M., Steinberg, D., Decraene, B., and S. | |||
| Routing Policy for Traffic Engineering", draft-filsfils- | Litkowski, "Segment Routing Policy for Traffic | |||
| spring-segment-routing-policy-01 (work in progress), July | Engineering", draft-filsfils-spring-segment-routing- | |||
| 2017. | policy-03 (work in progress), October 2017. | |||
| [I-D.ietf-6man-segment-routing-header] | [I-D.ietf-6man-segment-routing-header] | |||
| Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., | Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., | |||
| daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., | daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., | |||
| Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, | Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, | |||
| T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, | T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, | |||
| "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- | "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- | |||
| segment-routing-header-06 (work in progress), March 2017. | segment-routing-header-07 (work in progress), July 2017. | |||
| [I-D.ietf-idr-flowspec-redirect-ip] | [I-D.ietf-idr-flowspec-redirect-ip] | |||
| Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., | Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., | |||
| Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to | Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to | |||
| IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work | IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work | |||
| in progress), February 2015. | in progress), February 2015. | |||
| [I-D.ietf-spring-segment-routing] | [I-D.ietf-spring-segment-routing] | |||
| Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., | |||
| and R. Shakir, "Segment Routing Architecture", draft-ietf- | Litkowski, S., and R. Shakir, "Segment Routing | |||
| spring-segment-routing-12 (work in progress), June 2017. | Architecture", draft-ietf-spring-segment-routing-13 (work | |||
| in progress), October 2017. | ||||
| [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route | [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route | |||
| Reflection: An Alternative to Full Mesh Internal BGP | Reflection: An Alternative to Full Mesh Internal BGP | |||
| (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, | (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, | |||
| <http://www.rfc-editor.org/info/rfc4456>. | <https://www.rfc-editor.org/info/rfc4456>. | |||
| [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | |||
| Code: The Implementation Status Section", BCP 205, | Code: The Implementation Status Section", BCP 205, | |||
| RFC 7942, DOI 10.17487/RFC7942, July 2016, | RFC 7942, DOI 10.17487/RFC7942, July 2016, | |||
| <http://www.rfc-editor.org/info/rfc7942>. | <https://www.rfc-editor.org/info/rfc7942>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Stefano Previdi (editor) | Stefano Previdi (editor) | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| IT | IT | |||
| Email: stefano@previdi.net | Email: stefano@previdi.net | |||
| Clarence Filsfils | Clarence Filsfils | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| Brussels | Brussels | |||
| BE | BE | |||
| Email: cfilsfil@cisco.com | Email: cfilsfil@cisco.com | |||
| Paul Mattes | Paul Mattes | |||
| Microsoft | Microsoft | |||
| One Microsoft Way | One Microsoft Way | |||
| End of changes. 33 change blocks. | ||||
| 67 lines changed or deleted | 144 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||