BGP-LS Extensions for Inter-AS TE using EPE based mechanisms

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 segments allows to enforce a flow through any topological path or service function while maintaining per-flow state only at the ingress node of the SR domain. As there is no per-path state in the network, the bandwidth management for the paths is expected to be handled by a centralized entity which has a complete view of: 1. Up-to-date topology of the network 2. Resources, States and Attributes of links and nodes of the network 3. Run-time utilization/availability of resources The BGP Link-State extensions provide mechanisms whereby link-state and TE information can be propagated n a network and a consumer of such BGP LS updates may build topology, provide bandwidth calendering and other traffic engineering services. The centralized entity can be such a consumer (also referred to as controller). In the case of multi-AS networks, the controller needs to learn the per-AS network information and the inter-AS link information thus arriving at a consolidated Traffic Engineering Database which can be used to compute end-to-end Traffic Engineering Path. The controller can learn the topology, link-state and TE information from each of the AS networks either by participating in their IGPs or by listening to BGP LS updates . Similar information about the inter-AS links can be learnt via BGP-LS EPE along with extensions defined in this documet.

The controller learns TE attributes of all the links, including the inter-AS links and uses the attributes to compute constrained paths. The controller should be able to correlate the inter-AS links for bidirectional connectivity from both ASes.

+----------+ |Controller| +----------+ | |----------| +---------+ +------+ | | | | | H B------D G | | +---/| AS 2 |\ +------+ | |/ +------+ \ | |---L/8 A AS1 C---+ \| | | |\\ \ +------+ /| AS 4 |---M/8 | | \\ +-E |/ +------+ | X | \\ | K | | +===F AS 3 | +---------+ +------+ The reference diagram from represents multiple Autonomous Systems connected to each other. When the Multiple ASes belong to same operator and are organised into separate domains for operational purposes, it is advantageous to support Traffic-Engineering across the ASes including the inter-AS links. The controller has visibility of all of the ASes by means of IGP topology exported via BGP-LS , or other means. In addition, the inter-AS links and the labels associated with the inter-AS links are exported via . The controller needs to correlate the information acquired from all of the ASes, including the inter-AS links in order to get a view of the unified topology so that it can build end-to-end Traffic-Engineered paths.

section 3.6 describes mechanisms to provide Fast Reroute (FRR) protection for the EPE Labels. The BGP-LS EPE describes "B" bit to indicate that a PeerNodeSID or PeerAdjSID is eligible for backup. However, it does not specify what is the behaviour when the failure kicks-in. The controller needs to know which links are used for protection so that admission control and failure simulation can be done effectively and appropriate inter-AS links used for path construction. This document defines a new flag "F" in the Peering SIDs TLV to indicate a SID as an FRR SID. With the "F" flag set, the protection for any peering SID can be specified using another PeerAdjSID, PeerNodeSID or PeerSetSID to the controller. If the protection is achieved by fallback to local IP lookup, FRR SID SHOULD not be advertised. The link(s) represented by the FRR SID will carry the traffic when there is a failure. These SIDs are included as an FRR SIDs in the peerAdjSID, PeerNodeSID and PeerSetSID advertisements.

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L|B|P|F|Rsvd | +-+-+-+-+-+-+-+-+ * F-Flag: FRR Label Flag: If set, the peer SID where the FRR Label appears is using backup links represented by FRR Label.

In any eBGP deployment, the peering session can be either single-hop of multi-hop. For single-hop eBGP sessions, the peering address is that of the directly attached interface to which the session is pinned down. For multi-hop eBGP session, the peering adress is reachable over more than one interface and that the peering session is not pinned down to any of the directly attached interfaces. A Peer Node Segment is a segment describing a peer, including the SID (PeerNodeSID) allocated to it. The link descriptors for the PeerNodeSID include the addresses used by the BGP session encoded using TLVs as defined in . Since the eBGP session can be either single-hop or multi-hop, the IP address used by BGP session as local/neigbour is not sufficient to identify the underlaying interface(s). Also, the controller needs to know the links associated with the PeerNodeSID, to be able derive TE link attributes. This can be achieved by including the interface local and remote addresses in the Link attributes in PeerNodeSID NLRI. PeerAdjSID MUST be advertised for each inter-AS link for the purposes of inter-AS TE. The PeerAdjSID should contain link TE attributes such as bandwidth, admin-group etc. The PeerAdjSID should also contain the local and remote interface IPv4/IPv6 addresses which is used for correlating the links. PeerNodeSID SHOULD contain the additional attribute of link local address which is used by the controller to find corresponding PeerAdjSID and hence the corresponding link TE attributes. A peerAdj segment carries mandatory link descriptors as local and remote link id. Remote link id of the neighboring ASBR is not readily available. suggests to carry the value '0' for the remote link id. The Controller needs to associate the links in both directions to effectively handle failure notifications and for this purpose a unque remote link is necessary. The remote link ID cannot be manually configured on the router as the link-ids generally change over router reboot etc and hence manual configuration is operationally very difficult to manage. This document mandates advertisement of local and remote iterface addresses for the inetr-AS TE purposes. The Unnumbered interface is not in the scope of this document.

+-----------+---------------------+--------------+------------------+ | TLV Code | Description | IS-IS TLV | Reference | | Point | | /Sub-TLV | (RFC/Section) | +-----------+---------------------+--------------+------------------+ | 259 | IPv4 Local interface| 22/6 | [RFC5305]/3.2 | | | Address | | | | 261 | IPv6 Local interface| 22/12 | [RFC6119]/4.2 | | | Address | | | +-------------------------------------------------------------------+

The below diagram represents two ASBR routers and inter-AS links between them. The inter-AS links could be connected via switches L1 and L2 as shown in the diagram or via Point-to-point links A2->B2, A3->B3 as shown in the diagram below. In the below example, lets assume peerNodeSID 1 is configured to use peerAdjSID 10002 then PeerNodeSID 1 will have the B bit set which means the PeerNodeSID 1 is eligible for backup. Label 10002 is added to the PeerNodeSID with a "F" bit set, which means 10002 is a backup for PeerNodeSID 1.

+------------------------------------------------------------------+ | PeerNodeSID PeerAdjSID | | | |+-+----------------------------+ +-+-----------------------------+| ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| ||R|Link Descr: lo1:lo1 | |R|Link Descr LinkLocRmtID: 1:0 || ||I| | |I|Link IP (mandatory): A1:B1|| |+-+----------------------------+ +-+-----------------------------+| ||A|Link IP (new): A1:B1 | |A|PeerAdjSID: 10001 || ||T|Link IP (new): A2:B2 | |T|SRLG || ||T|PeerNodeSID: 1 | |T|affinity group || ||R|PeerSetSID (optional) | |R|MaxB/W || |+-+----------------------------+ +-+-----------------------------+| |+-+----------------------------+ +-+-----------------------------+| ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| ||R|Link Descr: lo2:lo2 | |R|Link Descr LinkLocRmtID: 2:0 || ||I| | |I|Link IP (mandatory): A2:B2|| |+-+----------------------------+ +-+-----------------------------+| ||A|Link IP (new): A1:B1 | |A|PeerAdjSID: 10002 || ||T|Link IP (new): A3:B3 | |T|SRLG || ||T|PeerNodeSID: 2 | |T|affinity group || ||R|PeerSetSID (optional) | |R|MaxB/W || || | | | |Unused B/W || |+-+----------------------------+ +-+-----------------------------+| |+-+----------------------------+ +-+-----------------------------+| ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| ||R|Link Descr: A3:B3 | |R|Link Descr LinkLocRmtID: 2:0 || ||I| | |I|Link IP (mandatory): A3:B3|| |+-+----------------------------+ +-+-----------------------------+| || |PeerNodeSID: 3 | |A|PeerAdjSID: 10103 || ||A|SRLG | |T|SRLG || ||T|affinity group | |T|affinity group || ||T|MaxB/W | |R|MaxB/W || ||R|Unused B/W | | |Unused B/W || || |... | | | || |+-+----------------------------+ +-+-----------------------------+| +------------------------------------------------------------------+ ^ BGP-LS EPE | +----------> w/ InerDomain -------+ | extensions | | +---------------------------------mh-eBGP--------------------+ | | | | | +-----------------------------mh-eBGP----------------+ | | | | | | +--+---+-----+ static lo1 --> +-----+ +-----+ +-----+---+--+ | v v | static lo2 --> | L2 | | L2 | | v v | | lo1 lo2 A1*------------------| swt |--->| swt |----*B1 lo2 lo1 | | | +-----+ +-----+ | | | | | | | | | | | RtR A | static lo1 --> | RtR B | | A2*----------------------------------------*B2 | | | | | | | static lo2 --> | | | A3*----------------------------------------*B3 | | | | | +-----------+^ ^+-----------+ | | | | +-------------------eBGP-----------------+

The extension proposed in this document is backward compatible with procedures described in and

TBD

No new TLV code points are needed.

Thanks to Julian Lucek and Rafal Jan Szarecki for careful review and suggestions.