draft-ietf-idr-segment-routing-te-policy-10.txt   draft-ietf-idr-segment-routing-te-policy-11.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 6, 2021 K. Talaulikar, Ed. Expires: May 17, 2021 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 2, 2020 November 13, 2020
Advertising Segment Routing Policies in BGP Advertising Segment Routing Policies in BGP
draft-ietf-idr-segment-routing-te-policy-10 draft-ietf-idr-segment-routing-te-policy-11
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 6, 2021. This Internet-Draft will expire on May 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 6 2. SR Policy Encoding . . . . . . . . . . . . . . . . . . . . . 6
2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 6 2.1. SR Policy SAFI and NLRI . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 2.4.2. Binding SID Sub-TLV . . . . . . . . . . . . . . . . . 10
2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11 2.4.3. SRv6 Binding SID Sub-TLV . . . . . . . . . . . . . . 11
2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13 2.4.4. Segment List Sub-TLV . . . . . . . . . . . . . . . . 13
2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27 2.4.5. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 28
2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29 2.4.6. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 29
2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30 2.4.7. Policy Candidate Path Name Sub-TLV . . . . . . . . . 30
2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31 2.4.8. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 31
3. Color Extended Community . . . . . . . . . . . . . . . . . . 31 3. Color Extended Community . . . . . . . . . . . . . . . . . . 31
4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 32 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 32
4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 32 4.1. Advertisement of SR Policies . . . . . . . . . . . . . . 32
4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 32 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 32
4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 33
4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 33 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 33
4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34 4.2.3. Passing a usable SR Policy NLRI to the SRPM . . . . . 34
skipping to change at page 4, line 20 skipping to change at page 4, line 20
This document specifies the way to use BGP to distribute one or more This document specifies the way to use BGP to distribute one or more
of the candidate paths of an SR Policy to the headend of that policy. of the candidate paths of an SR Policy to the headend of that policy.
The document describes the functionality that provided by BGP and, as The document describes the functionality that provided by BGP and, as
appropriate, provides references for the functionality which is appropriate, provides references for the functionality which is
outside the scope of BGP (i.e. resides within SRPM on the headend outside the scope of BGP (i.e. resides within SRPM on the headend
node). node).
This document specifies a way of representing SR Policy candidate This document specifies a way of representing SR Policy candidate
paths in BGP UPDATE messages. BGP can then be used to propagate the paths in BGP UPDATE messages. BGP can then be used to propagate the
SR Policy candidate paths to the headend nodes in the network. The SR Policy candidate paths to the headend nodes in the network. The
usual BGP rules for BGP propagation and "bestpath selection" are usual BGP rules for BGP propagation and best-path selection are used.
used. At the headend of a specific policy, this will result in one At the headend of a specific policy, this will result in one or more
or more candidate paths being installed into the "BGP table". These candidate paths being installed into the "BGP table". These paths
paths are then passed to the SRPM. The SRPM may compare them to are then passed to the SRPM. The SRPM may compare them to candidate
candidate paths learned via other mechanisms, and will choose one or paths learned via other mechanisms, and will choose one or more paths
more paths to be installed in the data plane. BGP itself does not to be installed in the data plane. BGP itself does not install SR
install SR Policy candidate paths into the data plane. Policy candidate paths into the data plane.
This document defines a new BGP address family (SAFI). In UPDATE This document defines a new BGP address family (SAFI). In UPDATE
messages of that address family, the NLRI identifies an SR Policy messages of that address family, the NLRI identifies an SR Policy
Candidate Path, and the attributes encode the segment lists and other Candidate Path, and the attributes encode the segment lists and other
details of that SR Policy Candidate Path. details of that SR Policy Candidate Path.
While for simplicity we may write that BGP advertises an SR Policy, While for simplicity we may write that BGP advertises an SR Policy,
it has to be understood that BGP advertises a candidate path of an SR it has to be understood that BGP advertises a candidate path of an SR
policy and that this SR Policy might have several other candidate policy and that this SR Policy might have several other candidate
paths provided via BGP (via an NLRI with a different distinguisher as paths provided via BGP (via an NLRI with a different distinguisher as
skipping to change at page 6, line 51 skipping to change at page 6, line 51
o Endpoint: identifies the endpoint of a policy. The Endpoint may o Endpoint: identifies the endpoint of a policy. The Endpoint may
represent a single node or a set of nodes (e.g., an anycast represent a single node or a set of nodes (e.g., an anycast
address). The Endpoint is an IPv4 (4-octet) address or an IPv6 address). The Endpoint is an IPv4 (4-octet) address or an IPv6
(16-octet) address according to the AFI of the NLRI. (16-octet) address according to the AFI of the NLRI.
The color and endpoint are used to automate the steering of BGP The color and endpoint are used to automate the steering of BGP
Payload prefixes on SR Policy as described in Payload prefixes on SR Policy as described in
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
The NLRI containing the SR Policy candidate path is carried in a BGP The NLRI containing the SR Policy candidate path is carried in a BGP
UPDATE message [RFC4271] using BGP multiprotocol extensions [RFC4760] UPDATE message [RFC4271] using BGP multi-protocol extensions
with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73. [RFC4760] with an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of 73.
An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI
attribute with the SR Policy SAFI MUST also carry the BGP mandatory attribute with the SR Policy SAFI MUST also carry the BGP mandatory
attributes. In addition, the BGP update message MAY also contain any attributes. In addition, the BGP update message MAY also contain any
of the BGP optional attributes. of the BGP optional attributes.
The next-hop network address field in SR Policy SAFI (73) updates may The next-hop network address field in SR Policy SAFI (73) updates may
be either a 4 octet IPv4 address or a 16 octet IPv6 address, be either a 4 octet IPv4 address or a 16 octet IPv6 address,
independent of the SR Policy AFI. The length field of the next-hop independent of the SR Policy AFI. The length field of the next-hop
address specifies the next-hop address family. If the next-hop address specifies the next-hop address family. If the next-hop
length is 4, then the next-hop is an IPv4 address; if the next-hop length is 4, then the next-hop is an IPv4 address; if the next-hop
length is 16, then it is a global IPv6 address; and if the next-hop length is 16, then it is a global IPv6 address; and if the next-hop
length is 32, then it has a global IPv6 address followed by a link- length is 32, then it has a global IPv6 address followed by a link-
local IPv6 address. The setting of the next-hop field and its local IPv6 address. The setting of the next-hop field and its
attendant processing is governed by standard BGP procedures as attendant processing is governed by standard BGP procedures as
described in section 3 in [RFC4760]. described in section 3 in [RFC4760].
It is important to note that any BGP speaker receiving a BGP message It is important to note that any BGP speaker receiving a BGP message
with an SR Policy NLRI, will process it only if the NLRI is among the with an SR Policy NLRI, will process it only if the NLRI is among the
best paths as per the BGP best path selection algorithm. In other best-paths as per the BGP best-path selection algorithm. In other
words, this document leverages the existing BGP propagation and words, this document leverages the existing BGP propagation and best-
bestpath selection rules. Details of the procedures are described in path 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 (i.e. ASN paths along with their respective originator information (i.e. ASN
and BGP Router-ID) as described in section 2.4 of and BGP Router-ID) as described in section 2.4 of
skipping to change at page 9, line 19 skipping to change at page 9, line 19
Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority,
Policy Name, Policy Candidate Path Name and Explicit NULL Label Policy Name, Policy Candidate Path Name and Explicit NULL Label
Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute Policy are the new sub-TLVs of the BGP Tunnel Encapsulation Attribute
[I-D.ietf-idr-tunnel-encaps] being defined in this section. [I-D.ietf-idr-tunnel-encaps] being defined in this section.
Weight and Segment are sub-TLVs of the new Segment-List sub-TLV Weight and Segment are sub-TLVs of the new Segment-List sub-TLV
mentioned above. mentioned above.
None of the sub-TLVs defined in the following sub-sections have any None of the sub-TLVs defined in the following sub-sections have any
effect on the BGP bestpath selection or propagation procedures. effect on the BGP best-path selection or propagation procedures.
These sub-TLVs are not used by BGP and are instead passed on to SRPM These sub-TLVs are not used by BGP and are instead passed on to SRPM
as SR Policy Candidate Path information for further processing as SR Policy Candidate Path information for further processing
described in [I-D.ietf-spring-segment-routing-policy] . described in [I-D.ietf-spring-segment-routing-policy] .
2.4.1. Preference Sub-TLV 2.4.1. Preference Sub-TLV
The Preference sub-TLV is used to carry the preference of the SR The Preference sub-TLV is used to carry the preference of the SR
Policy candidate path. The contents of this sub-TLV are used by the Policy candidate path. The contents of this sub-TLV are used by the
SRPM as described in section 2.7 in SRPM as described in section 2.7 in
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
skipping to change at page 27, line 25 skipping to change at page 27, line 25
ignored. ignored.
2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure 2.4.4.2.13. SRv6 SID Endpoint Behavior and Structure
The Segment Types sub-TLVs described above MAY contain the SRv6 The Segment Types sub-TLVs described above MAY contain the SRv6
Endpoint Behavior and SID Structure Endpoint Behavior and SID Structure
[I-D.ietf-spring-srv6-network-programming] encoding as described [I-D.ietf-spring-srv6-network-programming] encoding as described
below: below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | LB Length | LN Length | | Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Endpoint Behavior: 2 octets. The SRv6 Endpoint Behavior code Endpoint Behavior: 2 octets. The SRv6 Endpoint Behavior code
point for this SRv6 SID as defined in section 9.2 of point for this SRv6 SID as defined in section 9.2 of
[I-D.ietf-spring-srv6-network-programming]. When set with the [I-D.ietf-spring-srv6-network-programming]. When set with the
value 0, the choice of SRv6 Endpoint Behavior is left to the value 0, the choice of SRv6 Endpoint Behavior is left to the
headend. headend.
LB Length: 1 octet. SRv6 SID Locator Block length in bits. Reserved: 2 octet of reserved bits. SHOULD be set to zero on
transmission and MUST be ignored on receipt.
LN Length: 1 octet. SRv6 SID Locator Node length in bits. Locator Block Length: 1 octet. SRv6 SID Locator Block length in
bits.
Locator Node Length: 1 octet. SRv6 SID Locator Node length in
bits.
Function Length: 1 octet. SRv6 SID Function length in bits. Function Length: 1 octet. SRv6 SID Function length in bits.
Argument Length: 1 octet. SRv6 SID Arguments length in bits. Argument Length: 1 octet. SRv6 SID Arguments length in bits.
The total of the locator block, locator node, function and argument
lengths MUST be less than or equal to 128.
2.4.5. Explicit NULL Label Policy Sub-TLV 2.4.5. Explicit NULL Label Policy Sub-TLV
In order to steer an unlabeled IP packet into an SR policy, it is 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 necessary to create a label stack for that packet, and to push one or
more labels onto that stack. more labels onto that stack.
The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate
whether an Explicit NULL Label [RFC3032] must be pushed on an whether an Explicit NULL Label [RFC3032] must be pushed on an
unlabeled IP packet before any other labels. unlabeled IP packet before any other labels.
skipping to change at page 41, line 29 skipping to change at page 41, line 29
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., Sangli, S., and J. Scudder, "The BGP Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
encaps-19 (work in progress), September 2020. encaps-20 (work in progress), November 2020.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress), ietf-spring-segment-routing-policy-09 (work in progress),
November 2020. November 2020.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
 End of changes. 15 change blocks. 
24 lines changed or deleted 32 lines changed or added

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