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