Prefix-SID extensions for BGP-LU

Recent Datacenter routing designs are modeled like shown in Figure . Rather than using an IGP plus internal BGP (iBGP), an IGP-less design is favored for disseminating routing information. See for rationale and detailed information why and how to do so. Today BGP-LU is used both as an intra-AS and inter-AS routing protocol. Because of the IGP-less routing paradigm topology information gets lost. Particularly the ability to direct traffic to a specific node and hence the ability to do construct explicit paths denominated by a set of nodes for traffic-engineering is of interest. BGP-LU today may advertise a MPLS transport path between Autonomous Systems. This document describes extensions to the BGP-LU protocol such that in addition to the advertised MPLS label-switched paths (LSP) all potential MPLS label-switched paths of any given node in the Data Center are exposed to ingress nodes. The protocol extensions In this document are in full compliance with the MPLS Architecture documented in .

+------+ +------+ | | | | | |--| | Tier-1 / AS 651xx | | | | +------+ +------+ | | | | +---------+ | | +----------+ | +-------+--+------+--+-------+ | | | | | | | | | +----+ +----+ +----+ +----+ | | | | | | | | | |-----| | | |-----| | Tier-2 / AS 652xx | | | | | | | | +----+ +----+ +----+ +----+ | | | | | | | | | +-----+ | | +-----+ | +-| |-+ +-| |-+ Tier-3 / AS 653xx +-----+ +-----+ | | | | | | <- Servers -> <- Servers -> Servers / AS 65534

The specifications for Segment Routing ( and ) provide extensions for setting up hop-by-hop shortest path routed MPLS LSPs. The used Protocol semantics are: Domain-wide Index Local Label-Base Local Label Range advertised by any router in an IGP domain. This not only sets up MPLS sink-trees to each egress router in a domain, but also allows to steer traffic using stacks of node labels. The chosen protocol semantics are essentially a compression scheme to advertise all MPLS SPT paths in a domain. The ability to do explicit path routing based on stacked labels, constructed at the Hypervisors/Servers, without running conventional TE-protocols like for example RSVP-TE is a lightweight way to scale the Data Center Fabric. In order to support deployments of Segment Routing across routing protocol boundaries it is required to keep a common set of semantics across all routing protocols. This document specifies BGP-LU extensions to be able to address Node-SIDs across routing-protocol boundaries.

Depending on the Sophistication of the MPLS stack at the Hypervisor / Server there are various levels of considerations for deployment.

In case a restart of the first-hop router needs to be performed there may be some forwarding state churn at the Hypervisor / Server. It would be desirable that upon control-plane restart the Network node uses the same label-allocations than in the previous incarnation. Unfortunately none of the BGP graceful restart extensions allows to re-aquire previous incarnations label-mapping state from the network. Therefore a restarting node will be allocating FECs to labels in temporal incoming order. This degrades to pseudo-random, non-predictable label allocations. It is desirable that a BGP-LU implementation allocates the labels in a deterministic way, such that temporal control-plane loss does not impact forwarding between the Hypervisor / Server and the network. A BGP-LU Prefix SID speaking networking node MUST therefore implement a MPLS label-allocation strategy which produces a deterministic, local allocated label-block for all of its Prefix SIDs. For example an Implementation MAY statically allocate a Label Base of 800000 and a block-size of 16000 labels and delegate that label block exclusively to BGP-LU Prefix SID allocations, such that the same label-base is being used across control-plane restarts.

In this case the Hypervisor / Server has a "client-only" BGP-LU stack in order to interface to the network. This is the most distributed way of building label switched paths across the network. As soon as there is a reachability change then all of the Hypervisors / Servers get notified instantly. There is almost no time-lag for updating servers due to the inherent PUSH model of the BGP Protocol. Most of the implementation complexity of a BGP implementation comes from the BGP Update generation subsystem. For a client-only BGP implementation this is fortunately negligible as typically one or two (for redundancy reasons) BGP sessions are required. So the BGP Update Generation complexity stays limited.

The Labeled ARP Protocol may be used as a lightweight alternative to the BGP-LU protocol. Labeled ARP is a soft-state protocol and therefore needs special consideration for e.g Refresh-timers, Labels in the network etc. needs to be taken. Yet it is a distributed variant of LSP state propagation and hence re-acts immediately to network topology changes / label to FEC changes.

Static labels do not need a control-plane sessions between Hypervisors / Servers and the network. The assumption is that an external controller transfers the routing/label information into the Hypervisor / Server. The main disadvantage of that model is that the update process is not distributed and hence a controller needs to have excellent horizontal scaling abilities in order to update order of 100K routes/labels to order of 100K servers.

In order to facilitate dense packing of Network nodes and Node labels to a deterministic label-range like described in a new Protocol extension called the "BGP Prefix SID Attribute" is proposed. The BGP Prefix SID is a new optional, transitive BGP path attribute. The attribute type code for BGP Prefix SID attribute is to be assigned by IANA. The value field of the BGP Prefix SID attribute is defined here to be a set of elements encoded as "Type/Length/Value" (i.e., a set of TLVs). Each such TLV is encoded as shown in Figure .

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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: A single octet encoding the TLV Type. Unrecognized Types are preserved and propagated. In order to compare NLRIs with unknown TLVs all TLVs MUST be ordered in ascending order by TLV Type. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending order of the TLV value within the TLVs with the same type. All TLVs that are not specified as mandatory are considered optional. Length: Two octets encoding the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is not padded to four-octet alignment. Value: A field containing zero or more octets. The following TLV types are defined in this document: Type Name 1 Label Index 2 Label Base 3 Label Range Use of other TLV types is outside the scope of this document.

Type: 1 Length: 4 Value: Label Index Only one Label Index TLV per Prefix SID Attribute is allowed.

Type: 2 Length: 3 Value: Label Base One or more occurences of the Label Base TLV are allowed. A Label Base TLV MUST be followed by a Label Range TLV.

Type: 3 Length: 3 Value: Label Range One or more occurences of the Label Range TLV are allowed. A Label Range TLV MUST be preceeded by a Label Range TLV.

Many thanks to TBD for their detailed review and insightful comments.

This document requests a code point from the BGP Path Attributes registry named 'Prefix SID' This document requests creation of a new registry for BGP Prefix SID TLVs. Value 0 is reserved. The maximum value is 255. The registry will be initialized as shown in . Allocations within the registry will require documentation of the proposed use of the allocated value (=Specification required) and approval by the Designated Expert assigned by the IESG (see ).

This document does not introduce any change in terms of BGP security.