< draft-ietf-idr-bgp-prefix-sid-13.txt   draft-ietf-idr-bgp-prefix-sid-14.txt >
IDR S. Previdi, Ed. IDR S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: August 9, 2018 Cisco Systems Expires: August 11, 2018 Cisco Systems
A. Sreekantiah A. Sreekantiah
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
February 5, 2018 February 7, 2018
Segment Routing Prefix SID extensions for BGP Segment Routing Prefix SID extensions for BGP
draft-ietf-idr-bgp-prefix-sid-13 draft-ietf-idr-bgp-prefix-sid-14
Abstract Abstract
Segment Routing (SR) architecture allows a node to steer a packet Segment Routing (SR) architecture allows a node to steer a packet
flow through any topological path and service chain by leveraging flow through any topological path and service chain by leveraging
source routing. The ingress node prepends an SR header to a packet source routing. The ingress node prepends an SR header to a packet
containing a set of segment identifiers (SID). Each SID represents a containing a set of segment identifiers (SID). Each SID represents a
topological or a service-based instruction. Per-flow state is topological or a service-based instruction. Per-flow state is
maintained only on the ingress node of the SR domain. maintained only on the ingress node of the SR domain.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 http://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 August 9, 2018. This Internet-Draft will expire on August 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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 3, line 20 skipping to change at page 3, line 20
as "go to prefix P following shortest path" or a service instruction as "go to prefix P following shortest path" or a service instruction
(e.g., "pass through deep packet inspection"). Other types of (e.g., "pass through deep packet inspection"). Other types of
segments may be defined in the future. segments may be defined in the future.
A segment is identified through a Segment Identifier (SID). A segment is identified through a Segment Identifier (SID).
Typically, the ingress node of the SR domain prepends an SR header Typically, the ingress node of the SR domain prepends an SR header
containing segments identifiers (SIDs) to an incoming packet. containing segments identifiers (SIDs) to an incoming packet.
As described in [I-D.ietf-spring-segment-routing], when SR is applied As described in [I-D.ietf-spring-segment-routing], when SR is applied
to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the
SID consists of a label while when SR is applied to the IPv6 SID consists of a label, while when SR is applied to the IPv6
dataplane the SID consists of an IPv6 address. dataplane the SID consists of an IPv6 address.
A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment
attached to a BGP prefix. A BGP Prefix-SID is always a global SID attached to a BGP prefix. A BGP Prefix-SID is always a global SID
([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e.,
the set of Autonomous Systems under a common administration and the set of Autonomous Systems under a common administration and
control and where SR is used) and identifies an instruction to control and where SR is used) and identifies an instruction to
forward the packet over the ECMP-aware best-path computed by BGP to forward the packet over the ECMP-aware best-path computed by BGP to
the related prefix. The BGP Prefix-SID is the identifier of the BGP the related prefix. The BGP Prefix-SID is the identifier of the BGP
prefix segment. In this document, we always refer to the BGP segment prefix segment. In this document, we always refer to the BGP segment
skipping to change at page 10, line 15 skipping to change at page 10, line 15
The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY
contain the Originator SRGB TLV. A BGP Prefix-SID attribute received contain the Originator SRGB TLV. A BGP Prefix-SID attribute received
without a Label-Index TLV MUST be considered as "unacceptable" by the without a Label-Index TLV MUST be considered as "unacceptable" by the
receiving speaker. receiving speaker.
If multiple prefixes are received with the same label index value, If multiple prefixes are received with the same label index value,
all these prefixes MUST have their BGP Prefix-SID attribute all these prefixes MUST have their BGP Prefix-SID attribute
considered as "unacceptable" by the receiving speaker. considered as "unacceptable" by the receiving speaker.
When a BGP speaker receives a path from a neighbor with an acceptable When a BGP speaker receives a path from a neighbor with an acceptable
BGP Prefix-SID attribute, it MUST program the derived label as the BGP Prefix-SID attribute and that path is selected as the best path,
local label for the prefix in its MPLS dataplane. In case of an it SHOULD program the derived label as the local label for the prefix
error, a BGP speaker MUST follow to the error handling rules in its MPLS dataplane. In case of an error, a BGP speaker MUST
specified in Section 6. A BGP speaker SHOULD log an error for follow to the error handling rules specified in Section 6. A BGP
further analysis. speaker SHOULD log an error for further analysis.
When a BGP speaker receives a path from a neighbor with an When a BGP speaker receives a path from a neighbor with an
unacceptable BGP Prefix-SID attribute or when a BGP speaker receives unacceptable BGP Prefix-SID attribute or when a BGP speaker receives
a path from a neighbor with a BGP Prefix-SID attribute but is unable a path from a neighbor with a BGP Prefix-SID attribute but is unable
to process it (it does not have the capability or local policy to process it (it does not have the capability or local policy
disables the capability), it MUST treat the path as if it came disables the capability), it MUST treat the path as if it came
without a BGP Prefix-SID attribute. For the purposes of local label without a BGP Prefix-SID attribute. For the purposes of local label
allocation, a BGP speaker MUST assign a local (also called dynamic) allocation, a BGP speaker MUST assign a local (also called dynamic)
label (non-SRGB) for such a prefix as per classic Multiprotocol BGP label (non-SRGB) for such a prefix as per classic Multiprotocol BGP
labeled IPv4/IPv6 Unicast ([RFC8277]) operation. A BGP speaker labeled IPv4/IPv6 Unicast ([RFC8277]) operation. A BGP speaker
skipping to change at page 11, line 6 skipping to change at page 11, line 6
When an SR IPv6 BGP speaker receives an IPv6 Unicast BGP Update with When an SR IPv6 BGP speaker receives an IPv6 Unicast BGP Update with
a prefix having the BGP Prefix-SID attribute attached, it checks a prefix having the BGP Prefix-SID attribute attached, it checks
whether the IPv6 SID TLV is present. If present and chosen as the whether the IPv6 SID TLV is present. If present and chosen as the
best path, the prefix is installed into the Segment Routing IPv6 best path, the prefix is installed into the Segment Routing IPv6
dataplane as described in [I-D.ietf-spring-segment-routing]. dataplane as described in [I-D.ietf-spring-segment-routing].
The Label-Index and Originator SRGB TLVs MUST be ignored on The Label-Index and Originator SRGB TLVs MUST be ignored on
reception. For future extensibility, no TLVs are required for the reception. For future extensibility, no TLVs are required for the
BGP IPv6 unicast address family. However, a BGP Prefix-SID attribute BGP IPv6 unicast address family. However, a BGP Prefix-SID attribute
corresponding to the BGP IPv6 address family without an IPv6 SID TLV corresponding to the BGP IPv6 address family without an IPv6 SID TLV
MUST be ignored. SHOULD be ignored.
5. Advertising BGP Prefix-SID Attribute 5. Advertising BGP Prefix-SID Attribute
The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
(IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In
order to prevent distribution of the BGP Prefix-SID attribute beyond order to prevent distribution of the BGP Prefix-SID attribute beyond
its intended scope of applicability, attribute filtering SHOULD be its intended scope of applicability, attribute filtering SHOULD be
deployed. deployed to remove the BGP Prefix-SID attribute at the adminstrative
boundary of the segment routing domain.
A BGP speaker that advertises a path received from one of its A BGP speaker that advertises a path received from one of its
neighbors SHOULD advertise the BGP Prefix-SID received with the path neighbors SHOULD advertise the BGP Prefix-SID received with the path
without modification, as long as the BGP Prefix-SID was acceptable. without modification, as long as the BGP Prefix-SID was acceptable.
If the path did not come with a BGP Prefix-SID attribute, the speaker If the path did not come with a BGP Prefix-SID attribute, the speaker
MAY attach a BGP Prefix-SID to the path if configured to do so. The MAY attach a BGP Prefix-SID to the path if configured to do so. The
content of the TLVs present in the BGP Prefix-SID is determined by content of the TLVs present in the BGP Prefix-SID is determined by
the configuration. the configuration.
5.1. MPLS Dataplane: Labeled Unicast 5.1. MPLS Dataplane: Labeled Unicast
skipping to change at page 12, line 8 skipping to change at page 12, line 8
In all cases, the label field of the advertised NLRI ([RFC8277], In all cases, the label field of the advertised NLRI ([RFC8277],
[RFC4364]) MUST be set to the local/incoming label programmed in the [RFC4364]) MUST be set to the local/incoming label programmed in the
MPLS dataplane for the given advertised prefix. If the prefix is MPLS dataplane for the given advertised prefix. If the prefix is
associated with one of the BGP speaker's interfaces, this is the associated with one of the BGP speaker's interfaces, this is the
usual MPLS label (such as the Implicit or Explicit NULL label). usual MPLS label (such as the Implicit or Explicit NULL label).
5.2. IPv6 Dataplane 5.2. IPv6 Dataplane
A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID
attribute MAY include the IPv6 SID TLV. attribute SHOULD include the IPv6 SID TLV.
6. Error Handling of BGP Prefix-SID Attribute 6. Error Handling of BGP Prefix-SID Attribute
When a BGP Speaker receives a BGP Update message containing a When a BGP Speaker receives a BGP Update message containing a
malformed or unacceptable BGP Prefix-SID attribute attached to a malformed or unacceptable BGP Prefix-SID attribute attached to a
Labeled IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the Labeled IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the
received BGP Prefix-SID attributes and not advertise it to other BGP received BGP Prefix-SID attributes and not advertise it to other BGP
peers. This is equivalent to the "Attribute discard" action peers. This is equivalent to the "Attribute discard" action
specified in [RFC7606]. When discarding an attribute, a BGP speaker specified in [RFC7606]. When discarding an attribute, a BGP speaker
SHOULD log an error for further analysis. SHOULD log an error for further analysis.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
case, the BGP Prefix-SID advertisement is applicable to the inter-AS case, the BGP Prefix-SID advertisement is applicable to the inter-AS
context, i.e., EBGP, while it is confined to a single administrative context, i.e., EBGP, while it is confined to a single administrative
domain. domain.
9. Security Considerations 9. Security Considerations
This document introduces a BGP attribute (BGP Prefix-SID) which This document introduces a BGP attribute (BGP Prefix-SID) which
inherits the security considerations expressed in: [RFC4271], inherits the security considerations expressed in: [RFC4271],
[RFC8277], and [I-D.ietf-spring-segment-routing]. [RFC8277], and [I-D.ietf-spring-segment-routing].
When advertised using BGPsec as described in [RFC8205], the BGP
Prefix-SID attribute doesn't impose any unique security
considerations.
It should be noted that, as described in Section 8, this document It should be noted that, as described in Section 8, this document
refers to a deployment model where all nodes are under the single refers to a deployment model where all nodes are under the single
administrative domain. In this context, we assume that the operator administrative domain. In this context, we assume that the operator
doesn't want to leak any information related to internal prefixes and doesn't want to leak any information related to internal prefixes and
topology outside of the administrative domain. The internal topology outside of the administrative domain. The internal
information includes the BGP Prefix-SID. In order to prevent such information includes the BGP Prefix-SID. In order to prevent such
leaking, the standard BGP mechanisms (filters) are applied at the leaking, the standard BGP mechanisms (filters) are applied at the
boundary of the SR/administrative domain. boundary of the SR/administrative domain.
To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
(DDoS) attack due to excessive BGP updates with an unacceptable BGP
Prefix-SID attribute, message rate-limiting as well as suppression of
duplicate messages SHOULD be deployed.
10. Contributors 10. Contributors
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
US US
Email: Keyur@arrcus.com Email: Keyur@arrcus.com
Saikat Ray Saikat Ray
Unaffiliated Unaffiliated
skipping to change at page 14, line 49 skipping to change at page 15, line 12
The authors would like to thank Satya Mohanty for his contribution to The authors would like to thank Satya Mohanty for his contribution to
this document. this document.
The authors would like to thank Alvaro Retana for substantive The authors would like to thank Alvaro Retana for substantive
comments as part of the Routing AD review. comments as part of the Routing AD review.
The authors would like to thank Shyam Sethuram for comments and The authors would like to thank Shyam Sethuram for comments and
discussion of TLV processing and validation. discussion of TLV processing and validation.
The authors would like to thank Peter Yee, Tony Przygienda, Mirja The authors would like to thank Peter Yee, Tony Przygienda, Mirja
Kuehlewind, and Alexey Melnikov for IETF last call directorate and Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, and
IESG reviews. Warren Kumari for IETF Last Call directorate and IESG reviews.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
skipping to change at page 15, line 49 skipping to change at page 16, line 14
[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,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[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>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-idr-bgp-ls-segment-routing-ext] [I-D.ietf-idr-bgp-ls-segment-routing-ext]
Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
and M. Chen, "BGP Link-State extensions for Segment and M. Chen, "BGP Link-State extensions for Segment
Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04
 End of changes. 13 change blocks. 
15 lines changed or deleted 29 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/