draft-ietf-idr-bgp-prefix-sid-14.txt   draft-ietf-idr-bgp-prefix-sid-15.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 11, 2018 Cisco Systems Expires: August 16, 2018 Cisco Systems
A. Sreekantiah A. Sreekantiah
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
February 7, 2018 February 12, 2018
Segment Routing Prefix SID extensions for BGP Segment Routing Prefix SID extensions for BGP
draft-ietf-idr-bgp-prefix-sid-14 draft-ietf-idr-bgp-prefix-sid-15
Abstract Abstract
Segment Routing (SR) architecture allows a node to steer a packet The 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.
This document defines an optional, transitive BGP attribute for This document defines an optional, transitive BGP attribute for
announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
information. information.
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 11, 2018. This Internet-Draft will expire on August 16, 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 2, line 36 skipping to change at page 2, line 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . 4 2.1. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . 4
2.2. IPv6 Prefix Segment . . . . . . . . . . . . . . . . . . . 5 2.2. IPv6 Prefix Segment . . . . . . . . . . . . . . . . . . . 5
3. BGP Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 3. BGP Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5
3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6 3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6
3.2. IPv6 SID . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. IPv6 SID . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 7 3.3. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 7
4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 9 4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 9
4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 9 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 9
4.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 10 4.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 11
5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 11 5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 12
5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 11 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 12
5.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 12 5.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 13
6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 12 6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Manageability Considerations . . . . . . . . . . . . . . . . 13 8. Manageability Considerations . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Segment Routing (SR) architecture leverages the source routing The Segment Routing (SR) architecture leverages the source routing
paradigm. A group of inter-connected nodes that use SR forms an SR paradigm. A group of inter-connected nodes that use SR forms an SR
domain. A segment represents either a topological instruction such domain. A segment represents either a topological instruction such
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 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.
skipping to change at page 3, line 39 skipping to change at page 3, line 38
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
by the BGP Prefix-SID. by the BGP Prefix-SID.
This document describes the BGP extension to signal the BGP Prefix- This document describes the BGP extension to signal the BGP Prefix-
SID. Specifically, this document defines a BGP attribute known as SID. Specifically, this document defines a BGP attribute known as
the BGP Prefix-SID attribute and specifies the rules to originate, the BGP Prefix-SID attribute and specifies the rules to originate,
receive, and handle error conditions for the attribute. receive, and handle error conditions for the attribute.
The BGP Prefix-SID attribute defined in this document can be attached The BGP Prefix-SID attribute defined in this document can be attached
to prefixes from AFI/SAFI combinations: to prefixes from Address Family Identifier (AFI)/ Subsequent Address
Family Identifier (SAFI) combinations:
Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]).
Multiprotocol BGP ([RFC4760]) unlabeled IPv6 Unicast. Multiprotocol BGP ([RFC4760]) unlabeled IPv6 Unicast.
Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations
is not defined herein but may be specified in future specifications. is not defined herein but may be specified in future specifications.
[I-D.ietf-spring-segment-routing-msdc] describes example use cases [I-D.ietf-spring-segment-routing-msdc] describes example use cases
where the BGP Prefix-SID is used for the above AFI/SAFI combinations. where the BGP Prefix-SID is used for the above AFI/SAFI combinations.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
required to perform the explicit path computation and to express required to perform the explicit path computation and to express
an explicit path as a list of SIDs. The advertisement of an explicit path as a list of SIDs. The advertisement of
topological information and peer segments (Peer SIDs) is done topological information and peer segments (Peer SIDs) is done
through [I-D.ietf-idr-bgpls-segment-routing-epe]. through [I-D.ietf-idr-bgpls-segment-routing-epe].
If the BGP speakers are not all configured with the same SRGB, and If the BGP speakers are not all configured with the same SRGB, and
if traffic-engineering within the SR domain is required, each node if traffic-engineering within the SR domain is required, each node
may be required to advertise its local SRGB in addition to the may be required to advertise its local SRGB in addition to the
topological information. topological information.
This documents assumes that BGP-LS is the preferred method for This document assumes that BGP-LS is the preferred method for
collecting both peer segments (Peer SIDs) and SRGB information collecting both peer segments (Peer SIDs) and SRGB information
through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and
[I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an
optional alternative for the advertisement of the local SRGB optional alternative for the advertisement of the local SRGB
without the topology nor the peer SIDs, hence without without the topology nor the peer SIDs, hence without
applicability for TE, the Originator SRGB TLV of the prefix-SID applicability for TE, the Originator SRGB TLV of the prefix-SID
attribute is specified in Section 3.3 of this document. attribute is specified in Section 3.3 of this document.
As defined in [I-D.ietf-spring-segment-routing], the label index As defined in [I-D.ietf-spring-segment-routing], the label index
L_I is an offset into the SRGB. Each BGP speaker derives its L_I is an offset into the SRGB. Each BGP speaker derives its
skipping to change at page 9, line 37 skipping to change at page 9, line 37
4. Receiving BGP Prefix-SID Attribute 4. Receiving BGP Prefix-SID Attribute
A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP
neighbor residing outside the boundaries of the SR domain MUST neighbor residing outside the boundaries of the SR domain MUST
discard the attribute unless it is configured to accept the attribute discard the attribute unless it is configured to accept the attribute
from the EBGP neighbor. A BGP speaker SHOULD log an error for from the EBGP neighbor. A BGP speaker SHOULD log an error for
further analysis when discarding an attribute. further analysis when discarding an attribute.
4.1. MPLS Dataplane: Labeled Unicast 4.1. MPLS Dataplane: Labeled Unicast
A Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) session A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6
type is required. Unicast ([RFC8277]) AFI/SAFI is required.
The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY
contain the Originator SRGB TLV. A BGP Prefix-SID attribute received
without a Label-Index TLV MUST be considered as "invalid" by the
receiving speaker.
The label index provides the receiving BGP speaker with guidance as
to the incoming label that SHOULD be assigned by that BGP speaker.
A BGP speaker may be locally configured with an SRGB=[SRGB_Start, A BGP speaker may be locally configured with an SRGB=[SRGB_Start,
SRGB_End]. The preferred method for deriving the SRGB is a matter of SRGB_End]. The preferred method for deriving the SRGB is a matter of
local node configuration. local node configuration.
The mechanisms through which a given label index value is assigned to
a given prefix are outside the scope of this document.
Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the
derived label. A BGP Prefix-SID attribute is designated derived label. A BGP Prefix-SID attribute is designated
"unacceptable" for a speaker M if the derived label value L lies "conflicting" for a speaker M if the derived label value L lies
outside the SRGB configured on M. Otherwise the Label-Index TLV is outside the SRGB configured on M. Otherwise the Label-Index TLV is
designated "acceptable" to speaker M. designated "acceptable" to speaker M.
The mechanisms through which a given label index value is assigned to If multiple different prefixes are received with the same label
a given prefix are outside the scope of this document. index, all these but one of these different prefixes MUST have their
BGP Prefix-SID attribute considered as "conflicting" by the receiving
speaker. Alternately, all the different prefixes with the same label
index MAY be considered "conflicting".
The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY If multiple valid paths for the same prefix are received from
contain the Originator SRGB TLV. A BGP Prefix-SID attribute received multiple BGP speakers or, in the case of [RFC7911], from the same BGP
without a Label-Index TLV MUST be considered as "unacceptable" by the speaker, and the BGP Prefix-SID attributes do not contain the same
receiving speaker. label index, then the label index from the best path BGP Prefix-SID
attribute SHOULD be chosen.
If multiple prefixes are received with the same label index value, When a BGP speaker receives a path from a neighbor with an
all these prefixes MUST have their BGP Prefix-SID attribute "acceptable" BGP Prefix-SID attribute and that path is selected as
considered as "unacceptable" by the receiving speaker. the best path, it SHOULD program the derived label as the label for
the prefix in its local MPLS dataplane.
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 "invalid"
BGP Prefix-SID attribute and that path is selected as the best path, or "conflicting" BGP Prefix-SID attribute or when a BGP speaker
it SHOULD program the derived label as the local label for the prefix receives a path from a neighbor with a BGP Prefix-SID attribute but
in its MPLS dataplane. In case of an error, a BGP speaker MUST is unable to process it (it does not have the capability or local
follow to the error handling rules specified in Section 6. A BGP policy disables the capability), it MUST ignore the BGP Prefix-SID
speaker SHOULD log an error for further analysis. attribute. For the purposes of label allocation, a BGP speaker MUST
assign a local (also called dynamic) label (non-SRGB) for such a
prefix as per classic Multiprotocol BGP labeled IPv4/IPv6 Unicast
([RFC8277]) operation.
When a BGP speaker receives a path from a neighbor with an In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker
unacceptable BGP Prefix-SID attribute or when a BGP speaker receives MUST follow to the error handling rules specified in Section 6. A
a path from a neighbor with a BGP Prefix-SID attribute but is unable BGP speaker SHOULD log an error for further analysis. In the case of
to process it (it does not have the capability or local policy a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT
disables the capability), it MUST treat the path as if it came treat it as error and SHOULD propagate the attribute unchanged. A
without a BGP Prefix-SID attribute. For the purposes of local label BGP Speaker SHOULD log a warning for further analysis, i.e., in the
allocation, a BGP speaker MUST assign a local (also called dynamic) case the conflict is not due to a label index transition.
label (non-SRGB) for such a prefix as per classic Multiprotocol BGP
labeled IPv4/IPv6 Unicast ([RFC8277]) operation. A BGP speaker When a BGP Prefix-SID attribute changes and transitions from
SHOULD log an error for further analysis. "conflicting" to "acceptable", the BGP Prefix-SID attributes for
other prefixes may also transition to "acceptable" as well.
Implementations SHOULD assure all impacted prefixes revert to using
the label indices corresponding to these newly "acceptable" BGP
Prefix-SID attributes.
The outgoing label is always programmed as per classic Multiprotocol The outgoing label is always programmed as per classic Multiprotocol
BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Specifically, a BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Specifically, a
BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a
label NLRI field of Implicit NULL from a neighbor MUST adhere to label NLRI field of Implicit NULL from a neighbor MUST adhere to
standard behavior and program its MPLS dataplane to pop the top label standard behavior and program its MPLS dataplane to pop the top label
when forwarding traffic to the prefix. The label NLRI defines the when forwarding traffic to the prefix. The label NLRI defines the
outbound label that MUST be used by the receiving node. outbound label that MUST be used by the receiving node.
The label index provides the receiving BGP speaker with guidance as
to the incoming label that SHOULD be assigned by that BGP speaker.
4.2. IPv6 Dataplane 4.2. IPv6 Dataplane
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 and "acceptable".
best path, the prefix is installed into the Segment Routing IPv6
dataplane as described in [I-D.ietf-spring-segment-routing]. If multiple different prefixes are received with the same IPv6 SID,
all these but one of these different prefixes MUST have their BGP
Prefix-SID attribute considered as "conflicting" by the receiving
speaker. Alternately, all the different prefixes with the same IPv6
SID MAY be considered "conflicting".
If multiple valid paths for the same prefix are received from
multiple BGP speakers or, in the case of [RFC7911], from the same BGP
speaker, and the BGP Prefix-SID attributes do not contain the same
IPv6 SID, then the IPv6 SID from the best path BGP Prefix-SID
attributes SHOULD be chosen.
If "acceptable" and chosen as the best path, the prefix is installed
into the Segment Routing IPv6 dataplane as described in
[I-D.ietf-spring-segment-routing].
When a BGP speaker receives a path from a neighbor with an "invalid"
or "conflicting" BGP Prefix-SID attribute or when a BGP speaker
receives 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 disables the capability), it MUST ignore the BGP Prefix-SID
attribute and revert to [RFC2545] and [RFC4271]. Consistent with the
MPLS dataplane Section 4.1, a BGP speaker SHOULD log the condition
for further analysis.
When a BGP Prefix-SID attribute changes and transitions from
"conflicting" to "acceptable", the BGP Prefix-SID attributes for
other prefixes may also transition to "acceptable" as well.
Implementations SHOULD assure all impacted prefixes revert to using
the IPv6 SIDs corresponding to these newly "acceptable" BGP Prefix-
SID attributes.
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
SHOULD 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 to remove the BGP Prefix-SID attribute at the adminstrative deployed to remove the BGP Prefix-SID attribute at the administrative
boundary of the segment routing domain. 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.
skipping to change at page 12, line 13 skipping to change at page 13, line 13
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 SHOULD 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 invalid BGP Prefix-SID attribute attached to a Labeled
Labeled IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP
received BGP Prefix-SID attributes and not advertise it to other BGP Prefix-SID attributes and not advertise it to other BGP peers. This
peers. This is equivalent to the "Attribute discard" action is equivalent to the "Attribute discard" action specified in
specified in [RFC7606]. When discarding an attribute, a BGP speaker [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an
SHOULD log an error for further analysis. error for further analysis.
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 an malformed or invalid BGP Prefix-SID attribute attached to an
unlabeled IPv6 unicast prefix [RFC4760], it MUST treat the unlabeled IPv6 unicast prefix [RFC4760], it MUST treat the
advertisement as a withdrawal. This is equivalent to the "Treat-as- advertisement as a withdrawal. This is equivalent to the "Treat-as-
withdraw" action specified in [RFC7606]. This action is required withdraw" action specified in [RFC7606]. This action is required
since simply ignoring the BGP Prefix-SID attribute would modify the since simply ignoring the BGP Prefix-SID attribute would modify the
installed path and the "Attribute discard" option is not applicable installed path and the "Attribute discard" option is not applicable
in this case [RFC7606]. When withdrawing the prefix, a BGP speaker in this case [RFC7606]. When withdrawing the prefix, a BGP speaker
SHOULD log an error for further analysis. SHOULD log an error for further analysis.
Consistent with [RFC7606], only the first occurrence of the BGP Consistent with [RFC7606], only the first occurrence of the BGP
Prefix-SID attribute will be considered and subsequent occurrences Prefix-SID attribute will be considered and subsequent occurrences
skipping to change at page 14, line 16 skipping to change at page 15, line 16
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 When advertised using BGPsec as described in [RFC8205], the BGP
Prefix-SID attribute doesn't impose any unique security Prefix-SID attribute doesn't impose any unique security
considerations. considerations. It should be noted that the BGP Prefix-SID attribute
is not protected by the BGPsec signatures.
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 common BGP mechanisms (filters) are applied at the
boundary of the SR/administrative domain. boundary of the SR/administrative domain. Local BGP attribute
filtering policies and mechanisms are not standardized and,
consequently, beyond the scope of this document.
To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
(DDoS) attack due to excessive BGP updates with an unacceptable BGP (DDoS) attack due to excessive BGP updates with an invalid or
Prefix-SID attribute, message rate-limiting as well as suppression of conflicting BGP Prefix-SID attribute, message rate-limiting as well
duplicate messages SHOULD be deployed. 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
skipping to change at page 15, line 11 skipping to change at page 16, line 16
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 Robert Raszuk for comments and
suggestions regarding the MPLS and IPv6 data plane behavior.
The authors would like to thank Krishna Deevi, Juan Alcaide, Howard
Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID
label indices and BGP add paths.
The authors would like to thank Peter Yee, Tony Przygienda, Mirja The authors would like to thank Peter Yee, Tony Przygienda, Mirja
Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, and Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren
Warren Kumari for IETF Last Call directorate and IESG reviews. Kumari, and Ben Campbell 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 36 skipping to change at page 16, line 49
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-11 data plane", draft-ietf-spring-segment-routing-mpls-11
(work in progress), October 2017. (work in progress), October 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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999, <https://www.rfc-
editor.org/info/rfc2545>.
[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, <https://www.rfc- DOI 10.17487/RFC4271, January 2006, <https://www.rfc-
editor.org/info/rfc4271>. editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[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, <https://www.rfc- DOI 10.17487/RFC4760, January 2007, <https://www.rfc-
editor.org/info/rfc4760>. editor.org/info/rfc4760>.
[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>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, <https://www.rfc-
editor.org/info/rfc7911>.
[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 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 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,
 End of changes. 30 change blocks. 
75 lines changed or deleted 146 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/