draft-ietf-idr-bgpls-segment-routing-epe-15.txt   draft-ietf-idr-bgpls-segment-routing-epe-16.txt 
Inter-Domain Routing S. Previdi, Ed. Inter-Domain Routing S. Previdi, Ed.
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track C. Filsfils Intended status: Standards Track K. Talaulikar
Expires: September 6, 2018 Cisco Systems, Inc. Expires: April 18, 2019 C. Filsfils
Cisco Systems, Inc.
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
S. Ray S. Ray
Individual Contributor Individual Contributor
J. Dong J. Dong
Huawei Technologies Huawei Technologies
March 5, 2018 October 15, 2018
BGP-LS extensions for Segment Routing BGP Egress Peer Engineering BGP-LS extensions for Segment Routing BGP Egress Peer Engineering
draft-ietf-idr-bgpls-segment-routing-epe-15 draft-ietf-idr-bgpls-segment-routing-epe-16
Abstract Abstract
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any prepending the packet with an SR header. A segment can represent any
instruction, topological or service-based. SR allows to enforce a instruction, topological or service-based. SR segments allow
flow through any topological path and service chain while maintaining steering a flow through any topological path and service chain while
per-flow state only at the ingress node of the SR domain. maintaining per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires minor
extension to the existing link-state routing protocols.
This document outline a BGP-LS extension for exporting BGP peering This document describes an extension to BGP Link State (BGP-LS) for
node topology information (including its peers, interfaces and advertisement of BGP Peering Segments along with their BGP peering
peering ASs) in a way that is exploitable in order to compute node information so that efficient BGP Egress Peer Engineering (EPE)
efficient BGP Peering Engineering policies and strategies. policies and strategies can be computed based on Segment Routing.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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
skipping to change at page 2, line 12 skipping to change at page 2, line 10
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 September 6, 2018. This Internet-Draft will expire on April 18, 2019.
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
(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 34 skipping to change at page 2, line 32
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
2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4
3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4
4. Link NLRI for BGP-EPE Connectivity Description . . . . . . . 5 4. BGP-LS NLRI for BGP . . . . . . . . . . . . . . . . . . . . . 5
4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 6 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 6
4.2. Mandatory BGP-EPE Node Descriptors . . . . . . . . . . . 6 4.2. Mandatory BGP Node Descriptors . . . . . . . . . . . . . 6
4.3. Optional BGP-EPE Node Descriptors . . . . . . . . . . . . 7 4.3. Optional BGP Node Descriptors . . . . . . . . . . . . . . 7
4.4. Link Attributes . . . . . . . . . . . . . . . . . . . . . 7 5. BGP-LS Attributes for BGP Peering Segments . . . . . . . . . 7
5. Peer-Node and Peer-Adj SIDs . . . . . . . . . . . . . . . . . 9
5.1. Peer-Node-SID . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Peer-Node-SID . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Peer-Adj-SID . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Peer-Adj-SID . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Peer-Set-SID . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Peer-Set-SID . . . . . . . . . . . . . . . . . . . . . . 12
6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12
6.2. Peer-Node-SID for Node D . . . . . . . . . . . . . . . . 14 6.2. Peer-Node-SID for Node D . . . . . . . . . . . . . . . . 14
6.3. Peer-Node-SID for Node F . . . . . . . . . . . . . . . . 15 6.3. Peer-Node-SID for Node F . . . . . . . . . . . . . . . . 15
6.4. Peer-Node-SID for Node E . . . . . . . . . . . . . . . . 15 6.4. Peer-Node-SID for Node E . . . . . . . . . . . . . . . . 15
6.5. Peer-Adj-SID for Node E, Link 1 . . . . . . . . . . . . . 15 6.5. Peer-Adj-SID for Node E, Link 1 . . . . . . . . . . . . . 16
6.6. Peer-Adj-SID for Node E, Link 2 . . . . . . . . . . . . . 16 6.6. Peer-Adj-SID for Node E, Link 2 . . . . . . . . . . . . . 16
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 18
8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 18
9. Manageability Considerations . . . . . . . . . . . . . . . . 18 9. Manageability Considerations . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header with segment identifiers prepending the packet with an SR header with segment identifiers
(SID). A SID can represent any instruction, topological or service- (SID). A SID can represent any instruction, topological or service-
based. SR allows to enforce a flow through any topological path and based. SR segments allows to enforce a flow through any topological
service chain while maintaining per-flow state only at the ingress path or service function while maintaining per-flow state only at the
node of the SR domain. ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS The SR architecture [RFC8402] defines three types of BGP Peering
dataplane with no change on the forwarding plane. It requires minor Segments that may be instantiated at a BGP node:
extension to the existing link-state routing protocols.
This document outline a BGP-LS extension for exporting BGP peering o Peer Node Segment (Peer-Node-SID) : instruction to steer to a
node topology information (including its peers, interfaces and specific peer node
peering ASs) in a way that is exploitable in order to compute
efficient BGP Egress Peer Engineering (BGP-EPE) policies and
strategies.
This document defines the BGP-LS extensions required to support the o Peer Adjacency Segment (Peer-Adj-SID) : instruction to steer over
Peer Node SID describing the BGP session between two nodes, the Peer a specific local interface towards a specific peer node
Adjacency SID describing the link (one or more) that is used by the
BGP session and the Peer Set SID describing an arbitrary set of
sessions or links between the local BGP node and its peers. These
SIDs represent the segments defined in
[I-D.ietf-spring-segment-routing-central-epe].
While an egress point topology usually refers to eBGP sessions o Peer Set Segment (Peer-Set-SID) : instruction to load-balance to a
between external peers, there's nothing in the extensions defined in set of specific peer nodes
this document that would prevent the use of these extensions in the
context of iBGP sessions. SR can be directly applied to either an MPLS dataplane (SR/MPLS) with
no change on the forwarding plane or to a modified IPv6 forwarding
plane (SRv6).
This document describes extensions to the Link State NLRI and the
BGP-LS Attribute defined for BGP-LS [RFC7752] for advertising BGP
peering segments from a BGP node along with its peering topology
information (i.e. its peers, interfaces, and peering ASs) to enable
computation of efficient BGP Egress Peer Engineering (BGP-EPE)
policies and strategies using the SR/MPLS dataplane. The
corresponding extensions for SRv6 are specified in
[I-D.dawra-idr-bgpls-srv6-ext].
One use-case for these BGP Peering Segments is to enable computation
of SR paths that enable Central BGP-EPE as described in
[I-D.ietf-spring-segment-routing-central-epe]. This use-case
comprises of a centralized controller that learns the BGP Peering
SIDs via BGP-LS and then uses this information to program a SR policy
[I-D.ietf-spring-segment-routing-policy] at any node in the domain to
perform traffic steering via a specific BGP egress node to a specific
EBGP peer(s) optionally also over a specific interface.
This document introduces a new BGP protocol type for BGP-LS NLRI and
defines new BGP-LS Node and Link description TLVs to facilitate
advertising BGP-LS Link NLRI that represent the BGP peering topology.
Further, it specifies the BGP-LS Attribute TLVs for advertisement of
the BGP Peering Segments (i.e. Peer Node SID, Peer Adjacency SID,
and Peer Set SID) to be advertised in the same BGP-LS Link NLRI.
2. Segment Routing Documents 2. Segment Routing Documents
The main reference for this document is the SR architecture defined The main reference is the SR architecture defined in [RFC8402].
in [I-D.ietf-spring-segment-routing].
The Segment Routing BGP Egress Peer Engineering (BGP-EPE) The SR BGP-EPE architecture and use-case is described in
architecture is described in
[I-D.ietf-spring-segment-routing-central-epe]. [I-D.ietf-spring-segment-routing-central-epe].
3. BGP Peering Segments 3. BGP Peering Segments
As defined in [I-D.ietf-spring-segment-routing-central-epe], a BGP- As described in [I-D.ietf-spring-segment-routing-central-epe], a BGP-
EPE enabled Egress PE node MAY advertise SIDs corresponding to its EPE enabled Egress PE node MAY advertise SIDs corresponding to its
attached peers. These SIDs are called BGP peering segments or BGP attached peers. These SIDs are called BGP peering segments or BGP
Peering SIDs. In case of eBGP, they enable the expression of source- Peering SIDs. In case of EBGP, they enable the expression of source-
routed inter-domain paths. routed inter-domain paths.
An ingress border router of an AS may compose a list of SIDs to steer An ingress border router of an AS may compose a list of SIDs to steer
a flow along a selected path within the AS, towards a selected egress a flow along a selected path within the AS, towards a selected egress
border router C of the AS and through a specific peer. At minimum, a border router C of the AS, and to a specific EBGP peer. At minimum,
BGP-EPE policy applied at an ingress PE involves two SIDs: the Node a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node
SID of the chosen egress PE and then the BGP Peering SID for the SID of the chosen egress PE and then the BGP Peering SID for the
chosen egress PE peer or peering interface. chosen egress PE peer or peering interface.
This document defines the BGP-LS extensions for the BGP-EPE Peering
SIDs:
o Peer Node Segment (Peer-Node-SID)
o Peer Adjacency Segment (Peer-Adj-SID)
o Peer Set Segment (Peer-Set-SID)
that have been defined in
[I-D.ietf-spring-segment-routing-central-epe].
Each BGP session MUST be described by a Peer Node SID. The Each BGP session MUST be described by a Peer Node SID. The
description of the BGP session MAY be augmented by additional description of the BGP session MAY be augmented by additional Peer
Adjacency SIDs. Finally, each Peer Node SID and Peer Adjacency SID Adjacency SIDs. Finally, multiple Peer Node SIDs or Peer Adjacency
MAY be part of the same group/set so to be able to group EPE SIDs MAY be part of the same group/set in order to group EPE
resources under a common Peer-Set SID. resources under a common Peer-Set SID.
Therefore, when the extensions defined in this document are applied When the extensions defined in this document are applied to the EPE
to the use case defined in use-case defined in [I-D.ietf-spring-segment-routing-central-epe],
[I-D.ietf-spring-segment-routing-central-epe]: then the following BGP Peering SIDs need to be instantiated on a BGP
router for each of its BGP peer sessions that are enabled for EPE:
o One Peer-Node-SID MUST be present. o One Peer-Node-SID MUST be instantiated to describe the BGP peer
session.
o One or more Peer-Adj-SID MAY be present. o One or more Peer-Adj-SID MAY be instantiated corresponding to the
underlying link(s) to the directly connected BGP peer session.
o Each of the Peer-Node-SID Peer-Adj-SID MAY use the same Peer-Set- o A Peer-Set-SID MAY be instantiated and additionally associated and
SID. shared between one or more Peer-Node-SIDs or Peer-Adj-SIDs.
While an egress point topology usually refers to eBGP sessions While an egress point in a topology usually refers to EBGP sessions
between external peers, there's nothing in the extensions defined in between external peers, there's nothing in the extensions defined in
this document that would prevent the use of these extensions in the this document that would prevent the use of these extensions in the
context of iBGP sessions. context of IBGP sessions. However, unlike EBGP sessions which are
generally between directly connected BGP routers which are also along
the traffic forwarding path, IBGP peer sessions may be setup to BGP
routers which are not in the forwarding path. As such, when the IBGP
design includes sessions with route-reflectors, a BGP router SHOULD
NOT instantiate a BGP Peering SID for those sessions to peer nodes
which are not in the forwarding path since the purpose of BGP Peering
SID is to steer traffic to that specific peers. Thus, the
applicability for IBGP peering may be limited to only those
deployments where the IBGP peer is also along with forwarding data
path. Further details and the use-cases of BGP Peering SIDs and
their BGP-LS extensions to IBGP deployments are beyond the scope of
this document.
4. Link NLRI for BGP-EPE Connectivity Description The BGP Peering SIDs instantiated as described above are then
advertised via BGP-LS Link NLRI as described in the sections below.
This section describes the NLRI used for describing the connectivity 4. BGP-LS NLRI for BGP
of the BGP Egress router. The connectivity is based on links and
remote peers/ASs and therefore the existing Link NLRI Type (defined This section describes the BGP-LS NLRI encodings that describe the
in [RFC7752]) is used. A new Protocol-ID is used: BGP (codepoint 7 BGP peering and link connectivity between BGP routers.
assigned by IANA (Section 8) from the registry "BGP-LS Protocol-
IDs"). This document specifies the advertisement of BGP peering topology
information via BGP-LS NLRI which requires use of a new BGP protocol
identifier.
Protocol-ID : BGP (codepoint 7 assigned by IANA Section 8 from the
registry "BGP-LS Protocol-IDs")
The use of a new Protocol-ID allows separation and differentiation The use of a new Protocol-ID allows separation and differentiation
between the NLRIs carrying BGP-EPE descriptors from the NLRIs between the BGP-LS NLRI carrying BGP information from the NLRI
carrying IGP link-state information as defined in [RFC7752]. The carrying IGP link-state information as defined in [RFC7752].
Link NLRI Type uses descriptors and attributes already defined in
[RFC7752] in addition to new TLVs defined in the following sections
of this document.
The extensions defined in this document apply to both internal and The BGP Peering information along with their Peering Segments are
external BGP-LS EPE advertisements. advertised using BGP-LS Link NLRI with the protocol ID set to BGP.
The BGP-LS Link NLRI uses the descriptor TLVs and BGP-LS Attribute
TLVs as defined in [RFC7752]. In order to correctly describe BGP
nodes, new TLVs are defined in this section.
[RFC7752] defines Link NLRI Type is as follows: [RFC7752] defines Link NLRI Type is as follows:
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Protocol-ID | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
| (64 bits) | | (64 bits) |
skipping to change at page 6, line 7 skipping to change at page 6, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors // // Remote Node Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors // // Link Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Descriptors and Link Descriptors are defined in [RFC7752]. Node Descriptors and Link Descriptors are defined in [RFC7752].
4.1. BGP Router ID and Member ASN 4.1. BGP Router ID and Member ASN
Two new Node Descriptors Sub-TLVs are defined in this document: Two new Node Descriptors TLVs are defined in this document:
o BGP Router Identifier (BGP Router-ID): o BGP Router Identifier (BGP Router-ID):
Type: 516 (assigned by IANA (Section 8) from the registry "BGP- Type: 516 (assigned by IANA Section 8 from the registry "BGP-LS
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs"). Attribute TLVs").
Length: 4 octets Length: 4 octets
Value: 4 octet unsigned integer representing the BGP Identifier Value: 4 octet unsigned non-zero integer representing the BGP
as defined in [RFC4271] and [RFC6286]. Identifier as defined in [RFC4271] and [RFC6286].
o Confederation Member ASN (Member-ASN) o Confederation Member ASN (Member-ASN)
Type: 517 (assigned by IANA (Section 8) from the registry "BGP- Type: 517 (assigned by IANA Section 8 from the registry "BGP-LS
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs"). Attribute TLVs").
Length: 4 octets Length: 4 octets
Value: 4 octet unsigned integer representing the Member ASN Value: 4 octet unsigned non-zero integer representing the
inside the Confederation.[RFC5065]. Member ASN inside the Confederation [RFC5065].
4.2. Mandatory BGP-EPE Node Descriptors 4.2. Mandatory BGP Node Descriptors
The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI The following Node Descriptors TLVs MUST be included in BGP-LS NLRI
as Local Node Descriptors: as Local Node Descriptors when distributing BGP information:
o BGP Router-ID, which contains the BGP Identifier of the local BGP- o BGP Router-ID, which contains a valid BGP Identifier of the local
EPE capable node. BGP node.
o Autonomous System Number, which contains the local ASN or local o Autonomous System Number, which contains the ASN or confederation
confederation identifier (ASN) if confederations are used. identifier (ASN), if confederations are used, of the local BGP
node.
It has to be noted that [RFC6286] (section 2.1) requires the BGP Note that [RFC6286] (section 2.1) requires the BGP identifier
identifier (router-id) to be unique within an Autonomous System. (router-id) to be unique within an Autonomous System and non-zero.
Therefore, the <ASN, BGP Router-ID> tuple is globally unique. Therefore, the <ASN, BGP Router-ID> tuple is globally unique.
The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI The following Node Descriptors TLVs MUST be included in BGP-LS Link
as Remote Node Descriptors: NLRI as Remote Node Descriptors when distributing BGP information:
o BGP Router-ID, which contains the BGP Identifier of the peer node. o BGP Router-ID, which contains the valid BGP Identifier of the peer
BGP node.
o Autonomous System Number, which contains the peer ASN or the peer o Autonomous System Number, which contains the ASN or the
confederation identifier (ASN), if confederations are used. confederation identifier (ASN), if confederations are used, of the
peer BGP node.
4.3. Optional BGP-EPE Node Descriptors 4.3. Optional BGP Node Descriptors
The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI The following Node Descriptors TLVs MAY be included in BGP-LS NLRI as
as Local Node Descriptors: Local Node Descriptors when distributing BGP information:
o Member-ASN, which contains the ASN of the confederation member o Member-ASN, which contains the ASN of the confederation member, if
(when BGP confederations are used). BGP confederations are used, of the local BGP node.
o Node Descriptors as defined in [RFC7752]. o Node Descriptors as defined in [RFC7752].
The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI The following Node Descriptors TLVs MAY be included in BGP-LS Link
as Remote Node Descriptors: NLRI as Remote Node Descriptors when distributing BGP information:
o Member-ASN, which contains the ASN of the confederation member o Member-ASN, which contains the ASN of the confederation member, if
(when BGP confederations are used). BGP confederations are used, of the peer BGP node.
o Node Descriptors as defined in defined in [RFC7752]. o Node Descriptors as defined in defined in [RFC7752].
4.4. Link Attributes 5. BGP-LS Attributes for BGP Peering Segments
The following BGP-LS Link attributes TLVs are used with the Link This section defines the BGP-LS Attributes corresponding to the
NLRI: following BGP Peer Segment SIDs:
Peer Node Segment Identifier (Peer-Node-SID)
Peer Adjacency Segment Identifier (Peer-Adj-SID)
Peer Set Segment Identifier (Peer-Set-SID)
The following new BGP-LS Link attributes TLVs are defined for use
with BGP-LS Link NLRI for advertising BGP Peering SIDs:
+----------+---------------------------+----------+ +----------+---------------------------+----------+
| TLV Code | Description | Length | | TLV Code | Description | Length |
| Point | | | | Point | | |
+----------+---------------------------+----------+ +----------+---------------------------+----------+
| 1101 | Peer Node Segment | variable | | 1101 | Peer Node Segment | variable |
| | Identifier (Peer-Node-SID)| | | | Identifier (Peer-Node-SID)| |
| 1102 | Peer Adjacency Segment | variable | | 1102 | Peer Adjacency Segment | variable |
| | Identifier (Peer-Adj-SID) | | | | Identifier (Peer-Adj-SID) | |
| 1103 | Peer Set Segment | variable | | 1103 | Peer Set Segment | variable |
| | Identifier (Peer-Set-SID) | | | | Identifier (Peer-Set-SID) | |
+----------+---------------------------+----------+ +----------+---------------------------+----------+
Figure 1: BGP-LS TLV code points for BGP-EPE Figure 1: BGP-LS TLV code points for BGP-EPE
Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format Peer-Node-SID, Peer-Adj-SID, and Peer-Set-SID have all the same
defined here below: format defined here below:
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 2 Figure 2
o Type: 1101 or 1102 or 1103 (assigned by IANA (Section 8) from the o Type: 1101, 1102 or 1103 (assigned by IANA (Section 8) from the
registry "BGP-LS Node Descriptor, Link Descriptor, Prefix registry "BGP-LS Node Descriptor, Link Descriptor, Prefix
Descriptor, and Attribute TLVs"). Descriptor, and Attribute TLVs").
o Length: variable. o Length: variable.
o Flags: one octet of flags used when advertising a Peer-Adj-SID o Flags: one octet of flags with the following definition:
(Peer-Node and Peer-Set SIDs don't have flags defined). The
following Peer-Adj-SID flags have been defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L|B|P| | |V|L|B|P| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
* V-Flag: Value flag. If set, then the SID carries a label * V-Flag: Value flag. If set, then the SID carries a label
value. By default the flag is SET. value. By default the flag is SET.
skipping to change at page 9, line 7 skipping to change at page 9, line 30
* P-Flag: Persistent Flag: If set, the SID is persistently * P-Flag: Persistent Flag: If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router allocated, i.e., the SID value remains consistent across router
restart and session/interface flap. restart and session/interface flap.
* Other bits: MUST be zero when originated and ignored when * Other bits: MUST be zero when originated and ignored when
received. received.
o Weight: 1 octet. The value represents the weight of the SID for o Weight: 1 octet. The value represents the weight of the SID for
the purpose of load balancing. An example use of the weight is the purpose of load balancing. An example use of the weight is
described in [I-D.ietf-spring-segment-routing]. described in [RFC8402].
o SID/Index/Label. According to the TLV length and to the V and L o SID/Index/Label. According to the TLV length and to the V and L
flags settings, it contains either: flags settings, it contains either:
* A 3 octet local label where the 20 rightmost bits are used for * A 3 octet local label where the 20 rightmost bits are used for
encoding the label value. In this case the V and L flags MUST encoding the label value. In this case, the V and L flags MUST
be set. be SET.
* A 4 octet index defining the offset in the SRGB (Segment * A 4 octet index defining the offset in the SRGB (Segment
Routing Global Block as defined in Routing Global Block as defined in [RFC8402] advertised by this
[I-D.ietf-spring-segment-routing] advertised by this router. router. In this case, the SRGB MUST be advertised using the
In this case, the SRGB MUST be advertised using the extensions extensions defined in
defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. [I-D.ietf-idr-bgp-ls-segment-routing-ext].
The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- The values of the Peer-Node-SID, Peer-Adj-SID, and Peer-Set-SID Sub-
TLVs SHOULD be persistent across router restart. TLVs SHOULD be persistent across router restart.
The Peer-Node-SID MUST be present when BGP-LS is used for the use The Peer-Node-SID TLV MUST be included in the BGP-LS Attribute for
case described in [I-D.ietf-spring-segment-routing-central-epe] and the BGP-LS Link NLRI when advertising BGP peering information for the
MAY be omitted for other use cases. use case described in [I-D.ietf-spring-segment-routing-central-epe]
and MAY be omitted for other use cases.
The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS The Peer-Adj-SID and Peer-Set-SID TLVs MAY be included in the BGP-LS
is used for the use case described in Attribute for the BGP-LS Link NLRI when advertising BGP peering
information for the use case described in
[I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for
other use cases. other use cases.
In addition, BGP-LS Node and Link Attributes, as defined in [RFC7752] Additional BGP-LS Link Attribute TLVs, as defined in [RFC7752] MAY be
MAY be inserted in order to advertise the characteristics of the included with the BGP-LS Link NLRI in order to advertise the
link. characteristics of the peering link.
5. Peer-Node and Peer-Adj SIDs
In this section the following SIDs are defined:
Peer Node Segment Identifier (Peer-Node-SID)
Peer Adjacency Segment Identifier (Peer-Adj-SID)
Peer Set Segment Identifier (Peer-Set-SID)
The Peer-Node, Peer-Adj and Peer-Set SIDs can be either a local or a
global (depending on the setting of the V and L flags defined in
Figure 2.
5.1. Peer-Node-SID 5.1. Peer-Node-SID
The Peer-Node-SID describes the BGP session peer (neighbor). It MUST The Peer-Node-SID TLV includes a SID associated with the BGP peer
be present when describing a BGP-EPE topology as defined in node that is described by a BGP-LS Link NLRI as specified in
[I-D.ietf-spring-segment-routing-central-epe]. The Peer-Node-SID is Section 4.
encoded within the BGP-LS Link NLRI specified in Section 4.
The Peer-Node-SID, at the BGP node advertising it, has the following The Peer-Node-SID, at the BGP node advertising it, has the following
semantic: semantics:
o SR header operation: NEXT (as defined in o SR header operation: NEXT (as defined in [RFC8402]).
[I-D.ietf-spring-segment-routing]).
o Next-Hop: the connected peering node to which the segment is o Next-Hop: the connected peering node to which the segment is
related. associated.
The Peer-Node-SID is advertised with a Link NLRI, where:
o Local Node Descriptors contains The Peer-Node-SID is advertised with a BGP-LS Link NLRI, where:
* Local BGP Router-ID of the BGP-EPE enabled egress PE. o Local Node Descriptors include:
* Local ASN. * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE.
o Remote Node Descriptors contains * Local ASN (TLV 512).
* Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP o Remote Node Descriptors include:
session).
* Peer ASN. * Peer BGP Router-ID (TLV 516) (i.e.: the peer BGP ID used in the
BGP session)
o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the * Peer ASN (TLV 512).
addresses used by the BGP session:
* IPv4 Interface Address (Sub-TLV 259) contains the BGP session o Link Descriptors include the addresses used by the BGP session
IPv4 local address. encoded using TLVs as defined in [RFC7752]:
* IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session * IPv4 Interface Address (TLV 259) contains the BGP session IPv4
IPv4 peer address. local address.
* IPv6 Interface Address (Sub-TLV 261) contains the BGP session * IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4
IPv6 local address. peer address.
* IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session * IPv6 Interface Address (TLV 261) contains the BGP session IPv6
IPv6 peer address. local address.
o Link Attribute contains the Peer-Node-SID TLV as defined in * IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6
Section 4.4. peer address.
o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY o Link Attribute TLVs include the Peer-Node-SID TLV as defined in
be inserted in order to advertise the characteristics of the link. Figure 2.
5.2. Peer-Adj-SID 5.2. Peer-Adj-SID
The Peer-Adj-SID TLV includes a SID associated with the underlying
link to the BGP peer node that is described by a BGP-LS Link NLRI as
specified in Section 4.
The Peer-Adj-SID, at the BGP node advertising it, has the following The Peer-Adj-SID, at the BGP node advertising it, has the following
semantic: semantics:
o SR header operation: NEXT (as defined in o SR header operation: NEXT (as defined in [RFC8402]).
[I-D.ietf-spring-segment-routing]).
o Next-Hop: the interface peer address. o Next-Hop: the interface peer address.
The Peer-Adj-SID is advertised with a Link NLRI, where: The Peer-Adj-SID is advertised with a BGP-LS Link NLRI, where:
o Local Node Descriptors contains o Local Node Descriptors include:
* Local BGP Router-ID of the BGP-EPE enabled egress PE. * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE.
* Local ASN. * Local ASN (TLV 512).
o Remote Node Descriptors contains o Remote Node Descriptors include:
* Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP * Peer BGP Router-ID (TLV 516) (i.e. the peer BGP ID used in the
session). BGP session).
* Peer ASN. * Peer ASN (TLV 512).
o Link Descriptors Sub-TLVs, as defined in [RFC7752], MUST contain o Link Descriptors MUST include the following TLV, as defined in
the following TLVs: [RFC7752]:
* Link Local/Remote Identifiers (Sub-TLV 258) contains the * Link Local/Remote Identifiers (TLV 258) contains the 4-octet
4-octet Link Local Identifier followed by the 4-octet value 0 Link Local Identifier followed by the 4-octet Link Remote
indicating the Link Remote Identifier in unknown [RFC5307]. Identifier [RFC5307]. The value 0 is used by default when the
link remote identifier is unknown.
o In addition, Link Descriptors Sub-TLVs, as defined in [RFC7752], o Additional Link Descriptors TLVs, as defined in [RFC7752], MAY
MAY contain the following TLVs: also be included to describe the addresses corresponding to the
link between the BGP routers:
* IPv4 Interface Address (Sub-TLV 259) contains the address of * IPv4 Interface Address (Sub-TLV 259) contains the address of
the local interface through which the BGP session is the local interface through which the BGP session is
established. established.
* IPv6 Interface Address (Sub-TLV 261) contains the address of * IPv6 Interface Address (Sub-TLV 261) contains the address of
the local interface through which the BGP session is the local interface through which the BGP session is
established. established.
* IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address
of the peer interface used by the BGP session. of the peer interface used by the BGP session.
* IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address
of the peer interface used by the BGP session. of the peer interface used by the BGP session.
o Link attribute used with the Peer-Adj-SID contains the TLV as o Link Attribute TLVs include the Peer-Adj-SID TLV as defined in
defined in Section 4.4. Figure 2.
In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY be
inserted in order to advertise the characteristics of the link.
5.3. Peer-Set-SID 5.3. Peer-Set-SID
The Peer-Set-SID TLV includes a SID that is shared amongst BGP peer
nodes or the underlying links that are described by BGP-LS Link NLRI
as specified in Section 4.
The Peer-Set-SID, at the BGP node advertising it, has the following The Peer-Set-SID, at the BGP node advertising it, has the following
semantic: semantics:
o SR header operation: NEXT (as defined in o SR header operation: NEXT (as defined in [RFC8402]).
[I-D.ietf-spring-segment-routing]).
o Next-Hop: load balance across any connected interface to any peer o Next-Hop: load balance across any connected interface to any peer
in the related set. in the associated peer set.
The Peer-Set-SID is advertised within a Link NLRI (describing a Peer
Node Segment or a Peer Adjacency segment) as a BGP-LS attribute.
The Link Attribute contains the Peer-Set-SID TLV, defined in The Peer-Set-SID TLV containing the same SID value (encoded as
Section 4.4 identifying the set of which the Peer-Node-SID or Peer- defined in Figure 2) is included in the BGP-LS Attribute for all of
Adj-SID is a member. the BGP-LS Link NLRI corresponding to the Peer Node or Peer Adjacency
segments associated with the peer set.
6. Illustration 6. Illustration
6.1. Reference Diagram 6.1. Reference Diagram
The following reference diagram is used throughout this document. The following reference diagram is used throughout this section. The
The solution is illustrated for IPv6 with MPLS-based SIDs and the solution is illustrated for IPv6 with MPLS-based SIDs and the BGP-EPE
BGP-EPE topology is based on eBGP sessions between external peers. topology is based on EBGP sessions between external peers.
This illustration is non-normative text provided as an example for
implementers and describes the BGP-LS advertisements for the Central
EPE use-case.
As stated in Section 3, the solution illustrated hereafter is equally As stated in Section 3, the solution illustrated hereafter is equally
applicable to an iBGP session topology. In other words, the solution applicable to an IBGP session topology. In other words, the solution
also applies to the case where C, D, F, and E are in the same AS and also applies to the case where C, D, F, and E are in the same AS and
run iBGP sessions between each other. run IBGP sessions between each other.
+------+ +------+
| | | |
+---D H +---D H
+---------+ / | AS 2 |\ +------+ +---------+ / | AS 2 |\ +------+
| X |/ +------+ \ | Z |---L/8 | X |/ +------+ \ | Z |---L/8
A C---+ \| | A C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8 | |\\ \ +------+ /| AS 4 |---M/8
| AS1 | \\ +-F |/ +------+ | AS1 | \\ +-F |/ +------+
| | \\ | G | | \\ | G
skipping to change at page 13, line 39 skipping to change at page 13, line 44
o C's IP address of upper interface to E: 2001:db8:ce1::c/64, E's o C's IP address of upper interface to E: 2001:db8:ce1::c/64, E's
interface: 2001:db8:ce1::e interface: 2001:db8:ce1::e
o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0
o C's IP address of lower interface to E: 2001:db8:ce2::c, E's o C's IP address of lower interface to E: 2001:db8:ce2::c, E's
interface: 2001:db8:ce2::e interface: 2001:db8:ce2::e
o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0
o Loopback of E used for eBGP multi-hop peering to C: o Loopback of E used for EBGP multi-hop peering to C:
2001:db8:e::e/128 2001:db8:e::e/128
o C's loopback is 2001:db8:c::c/128 with SID 64 o C's loopback is 2001:db8:c::c/128 with SID 64
BGP Router-IDs are C, D, F and E. BGP Router-IDs are C, D, F and E.
o C's BGP Router-ID: 192.0.2.3 o C's BGP Router-ID: 192.0.2.3
o D's BGP Router-ID: 192.0.2.4 o D's BGP Router-ID: 192.0.2.4
o E's BGP Router-ID: 192.0.2.5 o E's BGP Router-ID: 192.0.2.5
o F's BGP Router-ID: 192.0.2.6 o F's BGP Router-ID: 192.0.2.6
C's BGP peering: C's BGP peering:
o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) o Single-hop EBGP peering with neighbor 2001:db8:cd::d (D)
o Single-hop eBGP peering with neighbor 2001:db8:cf::f (F) o Single-hop EBGP peering with neighbor 2001:db8:cf::f (F)
o Multi-hop eBGP peering with E on ip address 2001:db8:e::e (E) o Multi-hop EBGP peering with E on ip address 2001:db8:e::e (E)
C's resolution of the multi-hop eBGP session to E: C's resolution of the multi-hop EBGP session to E:
o Static route 2001:db8:e::e/128 via 2001:db8:ce1::e o Static route 2001:db8:e::e/128 via 2001:db8:ce1::e
o Static route 2001:db8:e::e/128 via 2001:db8:ce2::e o Static route 2001:db8:e::e/128 via 2001:db8:ce2::e
Node C configuration is such that: Node C configuration is such that:
o A Peer-Node-SID is allocated to each peer (D, F and E). o A Peer-Node-SID is allocated to each peer (D, F and E).
o An Peer-Adj-SID is defined for each recursing interface to a o An Peer-Adj-SID is defined for each recursing interface to a
multi-hop peer (CE upper and lower interfaces). multi-hop peer (CE upper and lower interfaces).
o A Peer-Set-SID is defined to include all peers in AS3 (peers F and o A Peer-Set-SID is defined to include all peers in AS3 (peers F and
E). E).
The Link NLRI Type is used in order to encode C's connectivity. The A BGP-LS Link NLRI is used in order to encode C's connectivity. The
Link NLRI uses the Protocol-ID for BGP value 7 assigned by IANA. Link NLRI uses the Protocol-ID for BGP (value 7) as assigned by IANA.
Once the BGP-LS update is originated by C, it may be advertised to Once the BGP-LS update is originated by C, it may be advertised to
internal (iBGP) as well as external (eBGP) neighbors supporting the internal (IBGP) as well as external (EBGP) neighbors supporting the
BGP-LS EPE extensions defined in this document. BGP-LS EPE extensions defined in this document. Note that the BGP-LS
sessions may be completely separate and different from the normal BGP
routing sessions described above - e.g. to a central EPE controller.
6.2. Peer-Node-SID for Node D 6.2. Peer-Node-SID for Node D
Descriptors: Descriptor TLVs used in the BGP-LS Link NLRI:
o Local Node Descriptors (BGP Router-ID, local ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP Router-ID, local ASN): 192.0.2.3, AS1
o Remote Node Descriptors (BGP Router-ID, peer ASN): 192.0.2.4, AS2 o Remote Node Descriptors (BGP Router-ID, peer ASN): 192.0.2.4, AS2
o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6
neighbor address): 2001:db8:cd::c, 2001:db8:cd::d neighbor address): 2001:db8:cd::c, 2001:db8:cd::d
Attributes: Link Attribute TLVs used in the BGP-LS Attribute associated with the
BGP-LS Link NLRI above:
o Peer-Node-SID: 1012 o Peer-Node-SID: 1012
o Link Attributes: see section 3.3.2 of [RFC7752] o Other Link Attributes: see section 3.3.2 of [RFC7752]
6.3. Peer-Node-SID for Node F 6.3. Peer-Node-SID for Node F
Descriptors: Descriptor TLVs used in the BGP-LS Link NLRI:
o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1
o Remote Node Descriptors (BGP Router-ID ASN): 192.0.2.6, AS3 o Remote Node Descriptors (BGP Router-ID ASN): 192.0.2.6, AS3
o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6
peer address): 2001:db8:cf::c, 2001:db8:cf::f peer address): 2001:db8:cf::c, 2001:db8:cf::f
Attributes: Link Attribute TLVs used in the BGP-LS Attribute associated with the
BGP-LS Link NLRI above:
o Peer-Node-SID: 1022 o Peer-Node-SID: 1022
o Peer-Set-SID: 1060 o Peer-Set-SID: 1060
o Link Attributes: see section 3.3.2 of [RFC7752] o Other Link Attributes: see section 3.3.2 of [RFC7752]
6.4. Peer-Node-SID for Node E 6.4. Peer-Node-SID for Node E
Descriptors: Descriptor TLVs used in the BGP-LS Link NLRI:
o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1
o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3
o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6
peer address): 2001:db8:c::c, 2001:db8:e::e peer address): 2001:db8:c::c, 2001:db8:e::e
Attributes: Link Attribute TLVs used in the BGP-LS Attribute associated with the
BGP-LS Link NLRI above:
o Peer-Node-SID: 1052 o Peer-Node-SID: 1052
o Peer-Set-SID: 1060 o Peer-Set-SID: 1060
6.5. Peer-Adj-SID for Node E, Link 1 6.5. Peer-Adj-SID for Node E, Link 1
Descriptors: Descriptor TLVs used in the BGP-LS Link NLRI:
o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1
o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3
o Link Descriptors (local interface identifier, IPv6 peer interface o Link Descriptors (local interface identifier, IPv6 peer interface
address): 0.0.0.1.0.0.0.0 , 2001:db8:ce1::e address): 0.0.0.1.0.0.0.0 , 2001:db8:ce1::e
Attributes: Link Attribute TLVs used in the BGP-LS Attribute associated with the
BGP-LS Link NLRI above:
o Peer-Adj-SID: 1032 o Peer-Adj-SID: 1032
o LinkAttributes: see section 3.3.2 of [RFC7752] o Other Link Attributes: see section 3.3.2 of [RFC7752]
6.6. Peer-Adj-SID for Node E, Link 2 6.6. Peer-Adj-SID for Node E, Link 2
Descriptors: Descriptor TLVs used in the BGP-LS Link NLRI:
o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1
o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3
o Link Descriptors (local interface identifier, IPv6 peer interface o Link Descriptors (local interface identifier, IPv6 peer interface
address): 0.0.0.2.0.0.0.0 , 2001:db8:ce2::e address): 0.0.0.2.0.0.0.0 , 2001:db8:ce2::e
Attributes: Link Attribute TLVs used in the BGP-LS Attribute associated with the
BGP-LS Link NLRI above:
o Peer-Adj-SID: 1042 o Peer-Adj-SID: 1042
o LinkAttributes: see section 3.3.2 of [RFC7752] o Other Link Attributes: see section 3.3.2 of [RFC7752]
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.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
skipping to change at page 17, line 18 skipping to change at page 17, line 33
| Codepoint | Description | | Codepoint | Description |
+---------------------------------------+ +---------------------------------------+
| 7 | Protocol-ID BGP | | 7 | Protocol-ID BGP |
| 516 | BGP Router-ID | | 516 | BGP Router-ID |
| 517 | BGP Confederation Member | | 517 | BGP Confederation Member |
| 1101 | Peer-Node-SID | | 1101 | Peer-Node-SID |
| 1102 | Peer-Adj-SID | | 1102 | Peer-Adj-SID |
| 1103 | Peer-Set-SID | | 1103 | Peer-Set-SID |
+------------+--------------------------+ +------------+--------------------------+
IANA has now confirmed the assignment of the above coidepoints. IANA has now confirmed the assignment of the above codepoints. See
SeeSection 8. Section 8.
8. IANA Considerations 8. IANA Considerations
This document defines: This document defines:
A new Protocol-ID: BGP. The codepoint is from the "BGP-LS A new Protocol-ID: BGP. The codepoint is from the "BGP-LS
Protocol-IDs" registry. Protocol-IDs" registry.
Two new TLVs: BGP-Router-ID and BGP Confederation Member. The Two new TLVs: BGP-Router-ID and BGP Confederation Member. The
codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, codepoints are in the "BGP-LS Node Descriptor, Link Descriptor,
skipping to change at page 18, line 11 skipping to change at page 18, line 27
This document defines 5 new TLVs in the registry "BGP-LS Node This document defines 5 new TLVs in the registry "BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs":
o Two new node descriptor TLVs o Two new node descriptor TLVs
o Three new link attribute TLVs o Three new link attribute TLVs
All the new 5 codepoints are in the same registry: "BGP-LS Node All the new 5 codepoints are in the same registry: "BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs".
However, the registry is organized in ranges (node descriptors, link
descriptors, node attributes, link attributes).
The following new Node Descriptors TLVs are defined: The following new Node Descriptors TLVs are defined:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Codepoint | Description | Status | | Codepoint | Description | Status |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 516 | BGP Router-ID | Assigned by IANA | | 516 | BGP Router-ID | Assigned by IANA |
| 517 | BGP Confederation Member | Assigned by IANA | | 517 | BGP Confederation Member | Assigned by IANA |
+------------+----------------------------------------------+ +------------+----------------------------------------------+
skipping to change at page 18, line 35 skipping to change at page 18, line 49
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Codepoint | Description | Status | | Codepoint | Description | Status |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| 1101 | Peer-Node-SID | Assigned by IANA | | 1101 | Peer-Node-SID | Assigned by IANA |
| 1102 | Peer-Adj-SID | Assigned by IANA | | 1102 | Peer-Adj-SID | Assigned by IANA |
| 1103 | Peer-Set-SID | Assigned by IANA | | 1103 | Peer-Set-SID | Assigned by IANA |
+------------+----------------------------------------------+ +------------+----------------------------------------------+
9. Manageability Considerations 9. Manageability Considerations
The BGP-LS ([RFC7752]) extensions that are described in this document The new protocol extensions introduced herein augment the existing
consist of additional BGP-LS descriptors and TLVs that will follow IGP topology information BGP-LS distribution [RFC7752] by adding
the same manageability functions of BGP-LS, described in [RFC7752]. support for distribution of BGP peering topology information. As
such, the Manageability Considerations section of [RFC7752] applies
to these new extensions as well.
The operator MUST be capable of configuring, enabling, disabling the Specifically, the malformed NLRI attribute tests for syntactic checks
advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer- in the Fault Management section of [RFC7752] now apply to the TLVs
Set-SID as well as to control which information is advertised to for the BGP-LS NLRI TLVs defined in this document. The semantic or
which internal or external peer. This is not different from what is content checking for the TLVs specified in this document and their
required by a BGP speaker in terms of information origination and association with the BGP-LS NLRI types or their associated BGP-LS
advertisement. In addition, the advertisement of EPE information Attributes is left to the consumer of the BGP-LS information (e.g. an
MUST conform to standard BGP advertisement and propagation rules application or a controller) and not the BGP protocol.
(iBGP, eBGP, Route-Reflectors, Confederations).
10. Security Considerations The operator MUST be provided with the options of configuring,
enabling, and disabling the advertisement of each of the Peer-Node-
SID, Peer-Adj-SID, and Peer-Set-SID as well as control of which
information is advertised to which internal or external peer. This
is not different from what is required by a BGP speaker in terms of
information origination and advertisement.
[RFC7752] defines BGP-LS NLRIs to which the extensions defined in BGP Peering Segments are associated with the normal BGP routing
this document apply. peering sessions. However, the BGP peering information along with
these Peering Segments themselves are advertised via a distinct BGP-
LS peering session. It is expected that this isolation as described
in [RFC7752] is followed when advertising BGP peering topology
information via BGP-LS.
The Security Section of [RFC7752] also applies to: BGP-EPE functionality enables the capability for instantiation of an
SR path for traffic engineering a flow via an egress BGP router to a
specific peer, bypassing the normal BGP best path routing for that
flow and any routing policies implemented in BGP on that egress BGP
router. As with any traffic engineering solution, the controller or
application implementing the policy needs to ensure that there is no
looping or mis-routing of traffic.
o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 10. Security Considerations
Confederation-Member;
o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- [RFC7752] defines BGP-LS NLRI to which the extensions defined in this
Set-SID. document apply. The Security Considerations section of [RFC7752]
also applies to these extensions.
The extensions defined in this document do not introduce any BGP-EPE enables engineering of traffic when leaving the
additional security aspects of BGP-LS. administrative domain via an egress BGP router. Therefore precaution
is necessary to ensure that the BGP peering information collected via
BGP-LS is limited to specific controllers or applications in a secure
manner. By default, Segment Routing operates within a trusted domain
(refer Security Considerations section in [RFC8402] for more detail)
and its security considerations also apply to BGP Peering Segments.
The BGP-EPE policies are expected to be used entirely within this
trusted SR domain (e.g. between multiple AS/domains within a single
provider network).
The isolation of BGP-LS peering sessions is also required to ensure
that BGP-LS topology information (including the newly added BGP
peering topology) is not advertised to an external BGP peering
session outside an administrative domain.
11. Contributors 11. Contributors
Mach (Guoyi) Chen Mach (Guoyi) Chen
Huawei Technologies Huawei Technologies
China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Acee Lindem Acee Lindem
Cisco Systems Inc. Cisco Systems Inc.
US US
Email: acee@cisco.com Email: acee@cisco.com
Ketan Talaulikar
Cisco Systems Inc.
India
Email: ketant@cisco.com
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Jakob Heitz, Howard Yang, Hannes The authors would like to thank Jakob Heitz, Howard Yang, Hannes
Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their
feedback and comments. feedback and comments. The authors would also like to thank Susan
Hares for her substantial contributions in improving the clarity of
the document during her shepherd's review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 20, line 29 skipping to change at page 21, line 14
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>. <https://www.rfc-editor.org/info/rfc5307>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>. June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
13.2. Informative References 13.2. Informative References
[I-D.dawra-idr-bgpls-srv6-ext]
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and
H. Elmalky, "BGP Link State extensions for IPv6 Segment
Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-04 (work in
progress), September 2018.
[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-09
(work in progress), January 2018. (work in progress), October 2018.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-01 (work in progress), June 2018.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[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,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Individual Individual
Email: stefano@previdi.net Email: stefano@previdi.net
Ketan Talaulikar
Cisco Systems, Inc.
Email: ketant@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
 End of changes. 144 change blocks. 
304 lines changed or deleted 370 lines changed or added

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