Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils
Intended status: Standards Track Cisco Systems, Inc.
Expires: June 23, 2018 K. Patel
Arrcus, Inc.
S. Ray
Individual Contributor
J. Dong
Huawei Technologies
December 20, 2017

BGP-LS extensions for Segment Routing BGP Egress Peer Engineering
draft-ietf-idr-bgpls-segment-routing-epe-14

Abstract

Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while 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 node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 23, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header with segment identifiers (SID). A SID can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while 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 node topology information (including its peers, interfaces and 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 Peer Node SID describing the BGP session between two nodes, the Peer 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 between external peers, there's nothing in the extensions defined in this document that would prevent the use of these extensions in the context of iBGP sessions.

2. Segment Routing Documents

The main reference for this document is the SR architecture defined in [I-D.ietf-spring-segment-routing].

The Segment Routing BGP Egress Peer Engineering (BGP-EPE) architecture is described in [I-D.ietf-spring-segment-routing-central-epe].

3. BGP Peering Segments

As defined in [I-D.ietf-spring-segment-routing-central-epe], a BGP-EPE enabled Egress PE node MAY advertise SIDs corresponding to its attached peers. These SIDs are called BGP peering segments or BGP Peering SIDs. In case of eBGP, they enable the expression of source-routed inter-domain paths.

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 border router C of the AS and through a specific peer. At minimum, 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 chosen egress PE peer or peering interface.

This document defines the BGP-LS extensions for the BGP-EPE Peering SIDs: [I-D.ietf-spring-segment-routing-central-epe].

that have been defined in

Each BGP session MUST be described by a Peer Node SID. The description of the BGP session MAY be augmented by additional Adjacency SIDs. Finally, each Peer Node SID and Peer Adjacency SID MAY be part of the same group/set so to be able to group EPE resources under a common Peer-Set SID.

Therefore, when the extensions defined in this document are applied to the use case defined in [I-D.ietf-spring-segment-routing-central-epe]:

While an egress point topology usually refers to eBGP sessions between external peers, there's nothing in the extensions defined in this document that would prevent the use of these extensions in the context of iBGP sessions.

4. Link NLRI for BGP-EPE Connectivity Description

This section describes the NLRI used for describing the connectivity of the BGP Egress router. The connectivity is based on links and remote peers/ASs and therefore the existing Link NLRI Type (defined in [RFC7752]) is used. A new Protocol-ID is used: 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 between the NLRIs carrying BGP-EPE descriptors from the NLRIs carrying IGP link-state information as defined in [RFC7752]. The 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 external BGP-LS EPE advertisements.

 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
+-+-+-+-+-+-+-+-+
|  Protocol-ID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Identifier                          |
|                            (64 bits)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Local Node Descriptors                                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Remote Node Descriptors                                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//      Link Descriptors                                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[RFC7752] defines Link NLRI Type is as follows:

Node Descriptors and Link Descriptors are defined in [RFC7752].

4.1. BGP Router ID and Member ASN

Two new Node Descriptors Sub-TLVs are defined in this document:

4.2. Mandatory BGP-EPE Node Descriptors

The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI as Local Node Descriptors:

It has to be noted that [RFC6286] (section 2.1) requires the BGP identifier (router-id) to be unique within an Autonomous System. Therefore, the <ASN, BGP identifier> tuple is globally unique.

The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI as Remote Node Descriptors:

4.3. Optional BGP-EPE Node Descriptors

The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI as Local Node Descriptors:

The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI as Remote Node Descriptors:

4.4. Link Attributes

The following BGP-LS Link attributes TLVs are used with the Link NLRI:

+----------+---------------------------+----------+
| TLV Code | Description               |   Length |
|  Point   |                           |          |
+----------+---------------------------+----------+
|    1101  | Peer Node Segment         | variable |
|          | Identifier (Peer-Node-SID)|          |
|    1102  | Peer Adjacency Segment    | variable |
|          | Identifier (Peer-Adj-SID) |          |
|    1103  | Peer Set Segment          | variable | 
|          | Identifier (Peer-Set-SID) |          |
+----------+---------------------------+----------+

Figure 1: BGP-LS TLV code points for BGP-EPE

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |     Weight    |             Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

Figure 2

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|           |
+-+-+-+-+-+-+-+-+

where:

Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format defined here below:

The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub-TLVs SHOULD be persistent across router restart.

The Peer-Node-SID MUST be present when BGP-LS is used for the 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 is used for the use case described in [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for other use cases.

In addition, BGP-LS Nodes and Link Attributes, as defined in [RFC7752] MAY be inserted in order to advertise the characteristics of the 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. For example, when BGP-EPE is used in the context of a SR network over the IPv6 dataplane, it is likely the case that the IPv6 addresses used as SIDs will be global.

5.1. Peer-Node-SID

The Peer-Node-SID describes the BGP session peer (neighbor). It MUST be present when describing a BGP-EPE topology as defined in [I-D.ietf-spring-segment-routing-central-epe]. The Peer-Node-SID is encoded within the BGP-LS Link NLRI specified in Section 4.

The Peer-Node-SID, at the BGP node advertising it, has the following semantic:

  Local BGP Router-ID of the BGP-EPE enabled egress PE.
  Local ASN.
  BGP-LS Identifier.
  Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session).
  Peer ASN.

The Peer-Node-SID is advertised with a Link NLRI, where:

5.2. Peer-Adj-SID

The Peer-Adj-SID, at the BGP node advertising it, has the following semantic:

  Local BGP Router-ID of the BGP-EPE enabled egress PE.
  Local ASN.
  BGP-LS Identifier.
  Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session).
  Peer ASN.

The Peer-Adj-SID is advertised with a Link NLRI, where:

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

The Peer-Set-SID, at the BGP node advertising it, has the following semantic:

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 Peer Set Attribute contains the Peer-Set-SID TLV, defined in Section 4.4 identifying the set of which the Peer-Node-SID or Peer-Adj-SID is a member.

6. Illustration

6.1. Reference Diagram

The following reference diagram is used throughout this document. The solution is illustrated for IPv6 with MPLS-based SIDs and the BGP-EPE topology is based on eBGP sessions between external peers.

As stated in Section 3, the solution illustrated hereafter is equally 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 run iBGP sessions between each other.

                 +------+
                 |      |
             +---D      H
+---------+ /    | AS 2 |\  +------+
|    X    |/     +------+ \ |   Z  |---L/8
A         C---+            \|      |
|         |\\  \  +------+ /| AS 4 |---M/8
|   AS1   | \\  +-F      |/ +------+
|         |  \\   |      G
+----P----+   +===E AS 3 |
     |             +--Q---+
     |                |
     +----------------+

Figure 3: Reference Diagram

IP addressing:

BGP Router-IDs are C, D, F and E.

C’s BGP peering:

C’s resolution of the multi-hop eBGP session to E:

Node C configuration is such that:

Local BGP-LS Identifier in router C is set to 10000.

The Link NLRI Type is used in order to encode C's connectivity. The Link NLRI uses the Protocol-ID value (to be assigned by IANA)

Once the BGP-LS update is originated by C, it may be advertised to internal (iBGP) as well as external (eBGP) neighbors supporting the BGP-LS EPE extensions defined in this document.

6.2. Peer-Node-SID for Node D

Descriptors:

Attributes:

6.3. Peer-Node-SID for Node F

Descriptors:

Attributes:

6.4. Peer-Node-SID for Node E

Descriptors:

Attributes:

6.5. Peer-Adj-SID for Node E, Link 1

Descriptors:

Attributes:

6.6. Peer-Adj-SID for Node E, Link 2

Descriptors:

Attributes:

7. Implementation Status

Note to RFC Editor: Please remove this section prior to publication, as well as the reference to RFC 7942.

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

+---------------------------------------+
|  Codepoint | Description              | 
+---------------------------------------+
|       7    | Protocol-ID BGP          | 
|     516    | BGP Router-ID            | 
|     517    | BGP Confederation Member | 
|    1101    | Peer-Node-SID            | 
|    1102    | Peer-Adj-SID             | 
|    1103    | Peer-Set-SID             | 
+------------+--------------------------+

Several early implementations exist and will be reported in detail in a forthcoming version of this document. For purposes of early interoperability testing, when no FCFS code point was available, implementations have made use of the following values:

IANA has now confirmed the assignment of the above coidepoints. SeeSection 8.

8. IANA Considerations

This document defines:

A new Protocol-ID: BGP. The codepoint is from the "BGP-LS Protocol-IDs" registry.
Two new TLVs: BGP-Router-ID and BGP Confederation Member. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.
Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.

8.1. New BGP-LS Protocol-ID

+----------------------------------------------+
|  Codepoint | Description | Status            | 
+----------------------------------------------+
|    7       | BGP         | Assigned by IANA  |
+----------------------------------------------+

This document defines a new value in the registry "BGP-LS Protocol-IDs":

8.2. Node Descriptors and Link Attribute TLVs

This document defines 5 new TLVs in the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs":

All the new 5 codepoints are in the same registry: "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". However, the registry is organized in ranges (node descriptors, link descriptors, node attributes, link attributes).

+-----------------------------------------------------------+
|  Codepoint | Description              | Status            |
+-----------------------------------------------------------+
|    516     | BGP Router-ID            | Assigned by IANA  |
|    517     | BGP Confederation Member | Assigned by IANA  |
+------------+----------------------------------------------+

The following new Node Descriptors TLVs are defined:

+-----------------------------------------------------------+
|  Codepoint | Description              | Status            |
+-----------------------------------------------------------+
|    1101    | Peer-Node-SID            | Assigned by IANA  |
|    1102    | Peer-Adj-SID             | Assigned by IANA  |
|    1103    | Peer-Set-SID             | Assigned by IANA  |
+------------+----------------------------------------------+

The following new Link Attribute TLVs are defined:

9. Manageability Considerations

The BGP-LS ([RFC7752]) extensions that are described in this document consist of additional BGP-LS descriptors and TLVs that will follow the same manageability functions of BGP-LS, described in [RFC7752].

The operator MUST be capable of configuring, enabling, disabling the advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID as well as to control 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. In addition, the advertisement of EPE information MUST conform to standard BGP advertisement and propagation rules (iBGP, eBGP, Route-Reflectors, Confederations).

10. Security Considerations

[RFC7752] defines BGP-LS NLRIs to which the extensions defined in this document apply.

The Security Section of [RFC7752] also applies to:

The extensions defined in this document do not introduce any additional security aspects of BGP-LS.

11. Contributors

Mach (Guoyi) Chen
Huawei Technologies
China

Email: mach.chen@huawei.com
Acee Lindem
Cisco Systems Inc. 
US

Email: acee@cisco.com
Ketan Talaulikar
Cisco Systems Inc. 
India

Email: ketant@cisco.com

12. Acknowledgements

The authors would like to thank Jakob Heitz, Howard Yang, Hannes Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their feedback and comments.

13. 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", Internet-Draft draft-ietf-spring-segment-routing-13, October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006.
[RFC5065] Traina, P., McPherson, D. and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007.
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011.

13.2. Informative References

[I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Psenak, P., Filsfils, C., Gredler, H. and M. Chen, "BGP Link-State extensions for Segment Routing", Internet-Draft draft-ietf-idr-bgp-ls-segment-routing-ext-03, July 2017.
[I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Dawra, G., Aries, E. and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Internet-Draft draft-ietf-spring-segment-routing-central-epe-08, December 2017.
[RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A. and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016.

Authors' Addresses

Stefano Previdi (editor) Cisco Systems, Inc. EMail: stefano@previdi.net
Clarence Filsfils Cisco Systems, Inc. Brussels, BE EMail: cfilsfil@cisco.com
Keyur Patel Arrcus, Inc. EMail: Keyur@arrcus.com
Saikat Ray Individual Contributor EMail: raysaikat@gmail.com
Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing, 100095 China EMail: jie.dong@huawei.com