draft-ietf-idr-segment-routing-te-policy-08.txt   draft-ietf-idr-segment-routing-te-policy-09.txt 
Network Working Group S. Previdi Network Working Group S. Previdi
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: May 21, 2020 K. Talaulikar, Ed. Expires: November 29, 2020 K. Talaulikar, Ed.
Cisco Systems Cisco Systems
P. Mattes P. Mattes
Microsoft Microsoft
E. Rosen E. Rosen
Juniper Networks Juniper Networks
D. Jain D. Jain
S. Lin S. Lin
Google Google
November 18, 2019 May 28, 2020
Advertising Segment Routing Policies in BGP Advertising Segment Routing Policies in BGP
draft-ietf-idr-segment-routing-te-policy-08 draft-ietf-idr-segment-routing-te-policy-09
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 (SR) Policy. An SR advertise a candidate path of a Segment Routing (SR) Policy. An SR
Policy is a set of candidate paths, each consisting of one or more Policy is a set of candidate paths, each 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 48 skipping to change at page 1, line 48
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 May 21, 2020. This Internet-Draft will expire on November 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 5
2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 5
2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7 2.2. SR Policy and Tunnel Encapsulation Attribute . . . . . . 7
2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8
2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 8 2.4. SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . . . 9
2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9
2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 9 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10
2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11
2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 24 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 24
2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 25 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 25
2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 26 2.4.6. Policy Candidate Path Name Sub-TLV . . . . . . . . . 26
3. Color Extended Community . . . . . . . . . . . . . . . . . . 27 3. Color Extended Community . . . . . . . . . . . . . . . . . . 27
4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 27 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 27
4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 27 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 28
4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 28 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 28
4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 28 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 28
4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 29 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 29
4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 29 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 29
4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 29 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 30
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 30 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. Existing Registry: Subsequent Address Family Identifiers 6.1. Existing Registry: Subsequent Address Family Identifiers
(SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 31 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 32
6.2. Existing Registry: BGP Tunnel Encapsulation Attribute 6.2. Existing Registry: BGP Tunnel Encapsulation Attribute
Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 31 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Existing Registry: BGP Tunnel Encapsulation Attribute 6.3. Existing Registry: BGP Tunnel Encapsulation Attribute
sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 32 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 32 6.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 32
6.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 32 6.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 33
6.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 33 6.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 33
6.7. New Registry: Color Extended Community Field . . . . . . 33 6.7. New Registry: Color Extended Community Field . . . . . . 34
6.8. Guidance for Designated Experts . . . . . . . . . . . . . 33 6.8. Guidance for Designated Experts . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.2. Informational References . . . . . . . . . . . . . . . . 37 10.2. Informational References . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Segment Routing (SR) [RFC8402] allows a headend node to steer a Segment Routing (SR) [RFC8402] allows a headend node to steer a
packet flow along any path. Intermediate per-flow states are packet flow along any path. Intermediate per-flow states are
eliminated thanks to source routing. eliminated thanks to source routing.
The headend node is said to steer a flow into a SR Policy. The headend node is said to steer a flow into a SR Policy.
The header of a packet steered in an SR Policy is augmented with the The header of a packet steered in an SR Policy is augmented with the
skipping to change at page 6, line 18 skipping to change at page 6, line 18
| Distinguisher | 4 octets | Distinguisher | 4 octets
+------------------+ +------------------+
| Policy Color | 4 octets | Policy Color | 4 octets
+------------------+ +------------------+
| Endpoint | 4 or 16 octets | Endpoint | 4 or 16 octets
+------------------+ +------------------+
where: where:
o NLRI Length: 1 octet of length expressed in bits as defined in o NLRI Length: 1 octet of length expressed in bits as defined in
[RFC4760]. When AFI = 1 value MUST be 12 and when AFI = 2 value [RFC4760]. When AFI = 1 value MUST be 96 and when AFI = 2 value
MUST be 24. MUST be 192.
o Distinguisher: 4-octet value uniquely identifying the policy in o Distinguisher: 4-octet value uniquely identifying the policy in
the context of <color, endpoint> tuple. The distinguisher has no the context of <color, endpoint> tuple. The distinguisher has no
semantic value and is solely used by the SR Policy originator to semantic value and is solely used by the SR Policy originator to
make unique (from an NLRI perspective) multiple candidate paths of make unique (from an NLRI perspective) multiple candidate paths of
the same SR Policy. the same SR Policy.
o Policy Color: 4-octet value identifying (with the endpoint) the o Policy Color: 4-octet value identifying (with the endpoint) the
policy. The color is used to match the color of the destination policy. The color is used to match the color of the destination
prefixes to steer traffic into the SR Policy as specified in prefixes to steer traffic into the SR Policy as specified in
skipping to change at page 7, line 25 skipping to change at page 7, line 25
words, this document leverages the existing BGP propagation and words, this document leverages the existing BGP propagation and
bestpath selection rules. Details of the procedures are described in bestpath selection rules. Details of the procedures are described in
Section 4. Section 4.
It has to be noted that if several candidate paths of the same SR It has to be noted that if several candidate paths of the same SR
Policy (endpoint, color) are signaled via BGP to a head-end, it is Policy (endpoint, color) are signaled via BGP to a head-end, it is
RECOMMENDED that each NLRI use a different distinguisher. If BGP has RECOMMENDED that each NLRI use a different distinguisher. If BGP has
installed into the BGP table two advertisements whose respective installed into the BGP table two advertisements whose respective
NLRIs have the same color and endpoint, but different distinguishers, NLRIs have the same color and endpoint, but different distinguishers,
both advertisements are passed to the SRPM as different candidate both advertisements are passed to the SRPM as different candidate
paths along with their respective originator information as described paths along with their respective originator information (i.e. ASN
in section 2.4 of [I-D.ietf-spring-segment-routing-policy]. and BGP Router-ID) as described in section 2.4 of
[I-D.ietf-spring-segment-routing-policy]. The ASN would be the ASN
of origin and the BGP Router-ID is determined in the following order:
o From the Route Origin Community [RFC4360] if present and carrying
an IP Address
o As the BGP Originator ID [RFC4456] if present
o As the BGP Router-ID of the peer from which the update was
received as a last resort.
2.2. SR Policy and Tunnel Encapsulation Attribute 2.2. SR Policy and Tunnel Encapsulation Attribute
The content of the SR Policy is encoded in the Tunnel Encapsulation The content of the SR Policy is encoded in the Tunnel Encapsulation
Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel- Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-
Type called SR Policy Type with codepoint 15. Type called SR Policy Type with codepoint 15.
The SR Policy Encoding structure is as follows: The SR Policy Encoding structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
skipping to change at page 8, line 18 skipping to change at page 8, line 35
[I-D.ietf-idr-tunnel-encaps]. [I-D.ietf-idr-tunnel-encaps].
o Tunnel-Type is set to 15. o Tunnel-Type is set to 15.
o Preference, Binding SID, Priority, Policy Name, ENLP, Segment- o Preference, Binding SID, Priority, Policy Name, ENLP, Segment-
List, Weight and Segment sub-TLVs are defined in this document. List, Weight and Segment sub-TLVs are defined in this document.
o Additional sub-TLVs may be defined in the future. o Additional sub-TLVs may be defined in the future.
A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV
of type "SR Policy". If more than one TLV of type "SR Policy" of type "SR Policy".
appears, the update is considered malformed and the "treat-as-
withdraw" strategy of [RFC7606] is applied.
2.3. Remote Endpoint and Color 2.3. Remote Endpoint and Color
The Remote Endpoint and Color sub-TLVs, as defined in The Remote Endpoint and Color sub-TLVs, as defined in
[I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy
encodings. encodings.
The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation
Attribute are not used for SR Policy encodings and therefore their Attribute are not used for SR Policy encodings and therefore their
value is irrelevant in the context of the SR Policy SAFI NLRI. If value is irrelevant in the context of the SR Policy SAFI NLRI. If
skipping to change at page 17, line 29 skipping to change at page 17, line 42
o Type: 5. o Type: 5.
o Length is 14 when the SR-MPLS SID is present else is 10. o Length is 14 when the SR-MPLS SID is present else is 10.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets of interface index as defined in o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. [RFC8664].
o IPv4 Node Address: a 4 octet IPv4 address representing a node. o IPv4 Node Address: a 4 octet IPv4 address representing a node.
o SR-MPLS SID: optional, 4 octet field containing label, TC, S and o SR-MPLS SID: optional, 4 octet field containing label, TC, S and
TTL as defined in Section 2.4.3.2.1. TTL as defined in Section 2.4.3.2.1.
2.4.3.2.6. Type F: IPv4 Local and Remote addresses with optional SID 2.4.3.2.6. Type F: IPv4 Local and Remote addresses with optional SID
The Type F Segment Sub-TLV encodes an adjacency local address, an The Type F Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address and an optional SR-MPLS SID. The format is adjacency remote address and an optional SR-MPLS SID. The format is
skipping to change at page 19, line 33 skipping to change at page 19, line 33
o Type: 7 o Type: 7
o Length is 46 when the SR-MPLS SID is present else is 42. o Length is 46 when the SR-MPLS SID is present else is 42.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets of interface index as defined in o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. [RFC8664].
o IPv6 Local Node Address: a 16 octet IPv6 address. o IPv6 Local Node Address: a 16 octet IPv6 address.
o Remote Interface ID: 4 octets of interface index as defined in o Remote Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. The value MAY be set to zero when [RFC8664]. The value MAY be set to zero when the local node
the local node address and interface identifiers are sufficient to address and interface identifiers are sufficient to describe the
describe the link. link.
o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY
be set to zero when the local node address and interface be set to zero when the local node address and interface
identifiers are sufficient to describe the link. identifiers are sufficient to describe the link.
o SR-MPLS SID: optional, 4 octet field containing label, TC, S and o SR-MPLS SID: optional, 4 octet field containing label, TC, S and
TTL as defined in Section 2.4.3.2.1. TTL as defined in Section 2.4.3.2.1.
2.4.3.2.8. Type H: IPv6 Local and Remote addresses with optional SID 2.4.3.2.8. Type H: IPv6 Local and Remote addresses with optional SID
for SR MPLS for SR MPLS
skipping to change at page 22, line 33 skipping to change at page 22, line 33
o Type: 11. o Type: 11.
o Length is 58 when the SRv6 SID is present else is 42. o Length is 58 when the SRv6 SID is present else is 42.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12. o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on o RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets of interface index as defined in o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. [RFC8664].
o IPv6 Local Node Address: a 16 octet IPv6 address. o IPv6 Local Node Address: a 16 octet IPv6 address.
o Remote Interface ID: 4 octets of interface index as defined in o Remote Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. The value MAY be set to zero when [RFC8664]. The value MAY be set to zero when the local node
the local node address and interface identifiers are sufficient to address and interface identifiers are sufficient to describe the
describe the link. link.
o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY o IPv6 Remote Node Address: a 16 octet IPv6 address. The value MAY
be set to zero when the local node address and interface be set to zero when the local node address and interface
identifiers are sufficient to describe the link. identifiers are sufficient to describe the link.
o SRv6 SID: optional, 16 octet IPv6 address. o SRv6 SID: optional, 16 octet IPv6 address.
2.4.3.2.11. Type K: IPv6 Local and Remote addresses for SRv6 with 2.4.3.2.11. Type K: IPv6 Local and Remote addresses for SRv6 with
optional SID optional SID
skipping to change at page 26, line 27 skipping to change at page 26, line 27
Type: 15 Type: 15
Length: 2. Length: 2.
Priority: a 1-octet value. Priority: a 1-octet value.
RESERVED: 1 octet of reserved bits. SHOULD be set to zero on RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
2.4.6. Policy Name Sub-TLV 2.4.6. Policy Candidate Path Name Sub-TLV
An operator MAY set the Policy Name sub-TLV to attach a symbolic name An operator MAY set the Policy Candidate Path Name sub-TLV to attach
to the SR Policy candidate path. a symbolic name to the SR Policy candidate path.
Usage of Policy Name sub-TLV is described in section 2 in Usage of Policy Candidate Path Name sub-TLV is described in section
[I-D.ietf-spring-segment-routing-policy]. 2.6 in [I-D.ietf-spring-segment-routing-policy].
The Policy Name sub-TLV may exceed 255 bytes length due to long The Policy Candidate Path Name sub-TLV may exceed 255 bytes length
policy name. Therefore a 2-octet length is required. According to due to long policy name. Therefore a 2-octet length is required.
[I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-
defines the size of the length field. Therefore, for the Policy Name TLV codepoint defines the size of the length field. Therefore, for
sub-TLV a code point of 128 or higher is used. the Policy Candidate Path Name sub-TLV a code point of 128 or higher
is used.
The Policy Name sub-TLV is optional and it MUST NOT appear more than It is RECOMMENDED that the size of the symbolic name be limited to
once in the SR Policy TLV. 255 bytes. Implementations MAY choose to truncate long names to 255
bytes when signaling via BGP.
The Policy Name sub-TLV has following format: The Policy Candidate Path Name sub-TLV is optional and it MUST NOT
appear more than once in the SR Policy TLV.
The Policy Candidate Path Name sub-TLV has following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Policy Name // // Policy Candidate Path Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
Type: 129. Type: 129.
Length: Variable. Length: Variable.
RESERVED: 1 octet of reserved bits. SHOULD be set to zero on RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
Policy Name: Symbolic name for the policy. It SHOULD be a string Policy Candidate Path Name: Symbolic name for the SR Policy
of printable ASCII characters, without a NULL terminator. candidate path without a NULL terminator as specified in section
2.6 of [I-D.ietf-spring-segment-routing-policy].
3. Color Extended Community 3. Color Extended 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 SR Policy, two bits from the RESERVED field (as the traffic into an SR Policy, two bits from the RESERVED field (as
defined in [I-D.ietf-idr-tunnel-encaps]) is used as follows: defined in [I-D.ietf-idr-tunnel-encaps]) are used as follows:
1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C O| RESERVED | |C O| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where CO bits are defined as the "Color-Only" bits. where CO bits are defined as the "Color-Only" bits.
[I-D.ietf-spring-segment-routing-policy] defines the influence of [I-D.ietf-spring-segment-routing-policy] defines the influence of
these bits on the automated steering of BGP Payload traffic onto SR these bits on the automated steering of BGP Payload traffic onto SR
skipping to change at page 28, line 40 skipping to change at page 28, line 46
When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST When a BGP speaker receives an SR Policy NLRI from a neighbor it MUST
first determine if it's acceptable. The following rules apply: first determine if it's acceptable. The following rules apply:
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). endpoint).
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 specification receives an SR format or both. If a router supporting this specification
policy update with no route-target extended communities and no receives an SR Policy update with no route-target extended
NO_ADVERTISE community, the update MUST be considered as communities and no NO_ADVERTISE community, the update MUST be
malformed. considered as malformed.
o The Tunnel Encapsulation Attribute MUST be attached to the BGP o The Tunnel Encapsulation Attribute MUST be attached to the BGP
Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint Update and MUST have a Tunnel Type TLV set to SR Policy (codepoint
is 15). is 15).
A router that receives an SR Policy update that is not valid A router that receives an SR Policy update that is not valid
according to these criteria MUST treat the update as malformed and according to these criteria MUST treat the update as malformed and
the SR Policy candidate path MUST NOT be passed to the SRPM. the SR Policy candidate path MUST NOT be passed to the SRPM.
4.2.2. Usable SR Policy NLRI 4.2.2. Usable SR Policy NLRI
skipping to change at page 29, line 23 skipping to change at page 29, line 31
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 the BGP Identifier of the receiver for the update target MUST match the BGP Identifier of the receiver for the update
to be considered usable. The BGP Identifier is defined in [RFC4271] to be considered usable. The BGP Identifier is defined in [RFC4271]
as a 4 octet IPv4 address. Therefore, the route-target extended as a 4 octet IPv4 address. Therefore, the route-target extended
community MUST be of the same format. community MUST be of the same format.
If one or more route-targets are present and none matches the local If one or more route-targets are present and none matches the local
BGP Identifier, then, while the SR Policy NLRI is acceptable, it is BGP Identifier, then, while the SR Policy NLRI is acceptable, it is
not usable on the receiver node. not usable on the receiver node.
When the SR Policy tunnel type includes any sub-TLV that is
unrecognized or unsupported, the update SHOULD NOT be considered
usable. An implementation MAY provide an option for ignoring
unsupported sub-TLVs.
4.2.3. Passing a usable SR Policy NLRI to the SRPM 4.2.3. Passing a usable SR Policy NLRI to the SRPM
Once BGP on the receiving node has determined that the SR Policy NLRI Once BGP on the receiving node has determined that the SR Policy NLRI
is usable, it passes the SR Policy candidate path to the SRPM. Note is usable, it passes the SR Policy candidate path to the SRPM. Note
that, along with the candidate path details, BGP also passes the that, along with the candidate path details, BGP also passes the
originator information for breaking ties in the candidate path originator information for breaking ties in the candidate path
selection process as described in section 2.4 in selection process as described in section 2.4 in
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
When an update for an SR Policy NLRI results in it's becoming
unusable, BGP MUST delete it's corresponding SR Policy candidate path
from the SRPM.
The SRPM applies the rules defined in section 2 in The SRPM applies the rules defined in section 2 in
[I-D.ietf-spring-segment-routing-policy] to determine whether the SR [I-D.ietf-spring-segment-routing-policy] to determine whether the SR
Policy candidate path is valid and to select the best candidate path Policy candidate path is valid and to select the best candidate path
among the valid ones for a given SR Policy. among the valid ones for a given SR Policy.
4.2.4. Propagation of an SR Policy 4.2.4. Propagation of an SR Policy
SR Policy NLRIs that have been determined acceptable and valid can be SR Policy NLRIs that have been determined acceptable and valid can be
evaluated for propagation, even the ones that are not usable. evaluated for propagation, even the ones that are not usable.
skipping to change at page 30, line 39 skipping to change at page 31, line 6
perform 'session reset' when the session is only being used for SR perform 'session reset' when the session is only being used for SR
Policy or when it 'AFI/SAFI disable' action is not possible. Policy or when it 'AFI/SAFI disable' action is not possible.
The validation of the TLVs/sub-TLVs introduced in this document and The validation of the TLVs/sub-TLVs introduced in this document and
defined in their respective sub-sections of Section 2.4 MUST be defined in their respective sub-sections of Section 2.4 MUST be
performed to determine if they are malformed or invalid. The performed to determine if they are malformed or invalid. The
validation of the Tunnel Encapsulation Attribute itself and the other validation of the Tunnel Encapsulation Attribute itself and the other
TLVs/sub-TLVs specified in [I-D.ietf-idr-tunnel-encaps] MUST be done TLVs/sub-TLVs specified in [I-D.ietf-idr-tunnel-encaps] MUST be done
as described in that document. In case of any error detected, either as described in that document. In case of any error detected, either
at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"
strategy of [RFC7606] MUST be applied. This is because an SR Policy strategy MUST be applied. This is because an SR Policy update
update without a valid Tunnel Encapsulation Attribute (comprising of without a valid Tunnel Encapsulation Attribute (comprising of all
all valid TLVs/sub-TLVs) is not usable. valid TLVs/sub-TLVs) is not usable.
An SR Policy update that is determined to be not acceptable, and
therefore malformed, based on rules described in Section 4.2.1 MUST
be handled by the "treat-as-withdraw" strategy.
The validation of the individual fields of the TLVs/sub-TLVs defined The validation of the individual fields of the TLVs/sub-TLVs defined
in Section 2.4 are beyond the scope of BGP as they are handled by the in Section 2.4 are beyond the scope of BGP as they are handled by the
SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP SRPM as described in the individual TLV/sub-TLV sub-sections. A BGP
implementation MUST NOT perform semantic verification of such fields implementation MUST NOT perform semantic verification of such fields
nor consider the SR Policy update to be invalid or not acceptable/ nor consider the SR Policy update to be invalid or not acceptable/
usable on the basis of such a validation. usable on the basis of such a validation.
An implementation SHOULD log an error for any errors found during the An implementation SHOULD log an error for any errors found during the
above validation for further analysis. above validation for further analysis.
skipping to change at page 32, line 18 skipping to change at page 32, line 39
Encapsulation Attribute sub-TLVs" that has been assigned codepoints Encapsulation Attribute sub-TLVs" that has been assigned codepoints
by IANA as follows: by IANA as follows:
Codepoint Description Reference Codepoint Description Reference
------------------------------------------------------ ------------------------------------------------------
12 Preference sub-TLV This document 12 Preference sub-TLV This document
13 Binding SID sub-TLV This document 13 Binding SID sub-TLV This document
128 Segment List sub-TLV This document 128 Segment List sub-TLV This document
14 ENLP sub-TLV This document 14 ENLP sub-TLV This document
15 Priority sub-TLV This document 15 Priority sub-TLV This document
129 Policy Name sub-TLV This document 129 Policy CP Name sub-TLV This document
6.4. New Registry: SR Policy List Sub-TLVs 6.4. New Registry: SR Policy List Sub-TLVs
This document requests creation of a new registry called "SR Policy This document requests creation of a new registry called "SR Policy
List Sub-TLVs". The allocation policy of this registry is List Sub-TLVs". The allocation policy of this registry is
"Specification Required" according to [RFC8126]. "Specification Required" according to [RFC8126].
Following initial Sub-TLV codepoints are assigned by this document: Following initial Sub-TLV codepoints are assigned by this document:
Value Description Reference Value Description Reference
skipping to change at page 34, line 45 skipping to change at page 35, line 24
not automatic and require configuration; thus, it is the not automatic and require configuration; thus, it is the
responsibility of the network operator to ensure that only trusted responsibility of the network operator to ensure that only trusted
nodes (that include both routers and controller applications) within nodes (that include both routers and controller applications) within
the SR domain are configured to receive such information. the SR domain are configured to receive such information.
8. Acknowledgments 8. Acknowledgments
The authors of this document would like to thank Shyam Sethuram, John The authors of this document would like to thank Shyam Sethuram, John
Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene, Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene,
Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal,
Jakob Heitz and Viral Patel for their comments and review of this Jakob Heitz, Viral Patel, Peng Shaofu and Cheng Li for their comments
document. and review of this document.
9. Contributors 9. Contributors
Arjun Sreekantiah Arjun Sreekantiah
Cisco Systems Cisco Systems
US US
Email: asreekan@cisco.com Email: asreekan@cisco.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
US US
skipping to change at page 35, line 40 skipping to change at page 36, line 16
US US
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), September 2019. (work in progress), December 2019.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress),
March 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-03 (work in progress), ietf-spring-segment-routing-policy-07 (work in progress),
May 2019. May 2020.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
skipping to change at page 37, line 5 skipping to change at page 37, line 24
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
10.2. Informational References 10.2. Informational References
[I-D.filsfils-spring-sr-policy-considerations] [I-D.filsfils-spring-sr-policy-considerations]
Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and
P. Mattes, "SR Policy Implementation and Deployment P. Mattes, "SR Policy Implementation and Deployment
Considerations", draft-filsfils-spring-sr-policy- Considerations", draft-filsfils-spring-sr-policy-
considerations-04 (work in progress), October 2019. considerations-05 (work in progress), April 2020.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[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,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
 End of changes. 45 change blocks. 
74 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/