idnits 2.17.1 draft-hegde-idr-bgp-ls-epe-inter-as-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-idr-bgpls-segment-routing-epe]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document date (April 19, 2019) is 1826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8402' is defined on line 370, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-18 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-segment-routing-central-epe (ref. 'I-D.ietf-spring-segment-routing-central-epe') ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Hegde 3 Internet-Draft S. Sangli 4 Intended status: Standards Track Juniper Networks Inc. 5 Expires: October 21, 2019 X. Xu 6 Alibaba Inc. 7 April 19, 2019 9 BGP-LS Extensions for Inter-AS TE using EPE based mechanisms 10 draft-hegde-idr-bgp-ls-epe-inter-as-01 12 Abstract 14 In certain network deployments, a single operator has multiple 15 Autonomous Systems(AS) to facilitate ease of management. A multiple 16 AS network design could also be a result of network mergers and 17 acquisitions. In such scenarios, a centralized Inter-domain TE 18 approach could provide most optimal allocation of resources and the 19 most controlled path placement. BGP-LS-EPE 20 [I-D.ietf-idr-bgpls-segment-routing-epe] describes an extension to 21 BGP Link State (BGP-LS) for the advertisement of BGP Peering Segments 22 along with their BGP peering node and inter-AS link information, so 23 that efficient BGP Egress Peer Engineering (EPE) policies and 24 strategies can be computed based on Segment Routing. This document 25 describes extensions to the BGP-LS EPE to enable it to be used for 26 inter-AS Traffic-Engineering (TE) purposes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 21, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Reference Topology . . . . . . . . . . . . . . . . . . . . . 3 69 3. Fast Reroute Label . . . . . . . . . . . . . . . . . . . . . 4 70 4. TE Link attributes of PeerNode SID . . . . . . . . . . . . . 5 71 5. Example Advertisements . . . . . . . . . . . . . . . . . . . 6 72 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 Segment Routing (SR) leverages source routing. A node steers a 84 packet through a controlled set of instructions, called segments, by 85 prepending the packet with an SR header with segment identifiers 86 (SID). A SID can represent any instruction, topological or service- 87 based. SR segments allows to enforce a flow through any topological 88 path or service function while maintaining per-flow state only at the 89 ingress node of the SR domain. 91 As there is no per-path state in the network, the bandwidth 92 management for the paths is expected to be handled by a centralized 93 entity which has a complete view of: 95 1. Up-to-date topology of the network 96 2. Resources, States and Attributes of links and nodes of the 97 network 99 3. Run-time utilization/availability of resources 101 The BGP Link-State extensions provide mechanisms whereby link-state 102 and TE information can be propagated n a network and a consumer of 103 such BGP LS updates may build topology, provide bandwidth calendering 104 and other traffic engineering services. The centralized entity can 105 be such a consumer (also referred to as controller). In the case of 106 multi-AS networks, the controller needs to learn the per-AS network 107 information and the inter-AS link information thus arriving at a 108 consolidated Traffic Engineering Database which can be used to 109 compute end-to-end Traffic Engineering Path. The controller can 110 learn the topology, link-state and TE information from each of the AS 111 networks either by participating in their IGPs or by listening to BGP 112 LS updates [RFC7752]. Similar information about the inter-AS links 113 can be learnt via BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] 114 along with extensions defined in this documet. 116 2. Reference Topology 118 The controller learns TE attributes of all the links, including the 119 inter-AS links and uses the attributes to compute constrained paths. 120 The controller should be able to correlate the inter-AS links for 121 bidirectional connectivity from both ASes. 123 +----------+ 124 |Controller| 125 +----------+ 126 | 127 |----------| 128 +---------+ +------+ 129 | | | | 130 | H B------D G 131 | | +---/| AS 2 |\ +------+ 132 | |/ +------+ \ | |---L/8 133 A AS1 C---+ \| | 134 | |\\ \ +------+ /| AS 4 |---M/8 135 | | \\ +-E |/ +------+ 136 | X | \\ | K 137 | | +===F AS 3 | 138 +---------+ +------+ 140 Figure 1: Reference Diagram 142 The reference diagram from 143 [I-D.ietf-spring-segment-routing-central-epe] represents multiple 144 Autonomous Systems connected to each other. When the Multiple ASes 145 belong to same operator and are organised into separate domains for 146 operational purposes, it is advantageous to support Traffic- 147 Engineering across the ASes including the inter-AS links. The 148 controller has visibility of all of the ASes by means of IGP topology 149 exported via BGP-LS [RFC7752], or other means. In addition, the 150 inter-AS links and the labels associated with the inter-AS links are 151 exported via [I-D.ietf-idr-bgpls-segment-routing-epe]. The 152 controller needs to correlate the information acquired from all of 153 the ASes, including the inter-AS links in order to get a view of the 154 unified topology so that it can build end-to-end Traffic-Engineered 155 paths. 157 3. Fast Reroute Label 159 [I-D.ietf-spring-segment-routing-central-epe] section 3.6 describes 160 mechanisms to provide Fast Reroute (FRR) protection for the EPE 161 Labels. The BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] 162 describes "B" bit to indicate that a PeerNodeSID or PeerAdjSID is 163 eligible for backup. However, it does not specify what is the 164 behaviour when the failure kicks-in. The controller needs to know 165 which links are used for protection so that admission control and 166 failure simulation can be done effectively and appropriate inter-AS 167 links used for path construction. 169 This document defines a new flag "F" in the Peering SIDs TLV to 170 indicate a SID as an FRR SID. With the "F" flag set, the protection 171 for any peering SID can be specified using another PeerAdjSID, 172 PeerNodeSID or PeerSetSID to the controller. If the protection is 173 achieved by fallback to local IP lookup, FRR SID SHOULD not be 174 advertised. The link(s) represented by the FRR SID will carry the 175 traffic when there is a failure. These SIDs are included as an FRR 176 SIDs in the peerAdjSID, PeerNodeSID and PeerSetSID advertisements. 178 0 1 2 3 4 5 6 7 179 +-+-+-+-+-+-+-+-+ 180 |V|L|B|P|F|Rsvd | 181 +-+-+-+-+-+-+-+-+ 183 Figure 2: Peering SID TLV Flags Format 185 * F-Flag: FRR Label Flag: If set, the peer SID where the FRR Label 186 appears is using backup links represented by FRR Label. 188 4. TE Link attributes of PeerNode SID 190 In any eBGP deployment, the peering session can be either single-hop 191 of multi-hop. For single-hop eBGP sessions, the peering address is 192 that of the directly attached interface to which the session is 193 pinned down. For multi-hop eBGP session, the peering adress is 194 reachable over more than one interface and that the peering session 195 is not pinned down to any of the directly attached interfaces. 197 A Peer Node Segment is a segment describing a peer, including the SID 198 (PeerNodeSID) allocated to it. The link descriptors for the 199 PeerNodeSID include the addresses used by the BGP session encoded 200 using TLVs as defined in [RFC7752]. Since the eBGP session can be 201 either single-hop or multi-hop, the IP address used by BGP session as 202 local/neigbour is not sufficient to identify the underlaying 203 interface(s). Also, the controller needs to know the links 204 associated with the PeerNodeSID, to be able derive TE link 205 attributes. This can be achieved by including the interface local 206 and remote addresses in the Link attributes in PeerNodeSID NLRI. 208 PeerAdjSID MUST be advertised for each inter-AS link for the purposes 209 of inter-AS TE. The PeerAdjSID should contain link TE attributes 210 such as bandwidth, admin-group etc. The PeerAdjSID should also 211 contain the local and remote interface IPv4/IPv6 addresses which is 212 used for correlating the links. PeerNodeSID SHOULD contain the 213 additional attribute of link local address which is used by the 214 controller to find corresponding PeerAdjSID and hence the 215 corresponding link TE attributes. 217 A peerAdj segment carries mandatory link descriptors as local and 218 remote link id. Remote link id of the neighboring ASBR is not 219 readily available. [I-D.ietf-idr-bgpls-segment-routing-epe] suggests 220 to carry the value '0' for the remote link id. The Controller needs 221 to associate the links in both directions to effectively handle 222 failure notifications and for this purpose a unque remote link is 223 necessary. The remote link ID cannot be manually configured on the 224 router as the link-ids generally change over router reboot etc and 225 hence manual configuration is operationally very difficult to manage. 226 This document mandates advertisement of local and remote iterface 227 addresses for the inetr-AS TE purposes. 229 The Unnumbered interface is not in the scope of this document. 231 +-----------+---------------------+--------------+------------------+ 232 | TLV Code | Description | IS-IS TLV | Reference | 233 | Point | | /Sub-TLV | (RFC/Section) | 234 +-----------+---------------------+--------------+------------------+ 235 | 259 | IPv4 Local interface| 22/6 | [RFC5305]/3.2 | 236 | | Address | | | 237 | 261 | IPv6 Local interface| 22/12 | [RFC6119]/4.2 | 238 | | Address | | | 239 +-------------------------------------------------------------------+ 241 Figure 3: Link Addresses carried as attributes 243 5. Example Advertisements 245 The below diagram represents two ASBR routers and inter-AS links 246 between them. The inter-AS links could be connected via switches L1 247 and L2 as shown in the diagram or via Point-to-point links A2->B2, 248 A3->B3 as shown in the diagram below. In the below example, lets 249 assume peerNodeSID 1 is configured to use peerAdjSID 10002 then 250 PeerNodeSID 1 will have the B bit set which means the PeerNodeSID 1 251 is eligible for backup. Label 10002 is added to the PeerNodeSID with 252 a "F" bit set, which means 10002 is a backup for PeerNodeSID 1. 254 +------------------------------------------------------------------+ 255 | PeerNodeSID PeerAdjSID | 256 | | 257 |+-+----------------------------+ +-+-----------------------------+| 258 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 259 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 260 ||R|Link Descr: lo1:lo1 | |R|Link Descr LinkLocRmtID: 1:0 || 261 ||I| | |I|Link IP (mandatory): A1:B1|| 262 |+-+----------------------------+ +-+-----------------------------+| 263 ||A|Link IP (new): A1:B1 | |A|PeerAdjSID: 10001 || 264 ||T|Link IP (new): A2:B2 | |T|SRLG || 265 ||T|PeerNodeSID: 1 | |T|affinity group || 266 ||R|PeerSetSID (optional) | |R|MaxB/W || 267 |+-+----------------------------+ +-+-----------------------------+| 268 |+-+----------------------------+ +-+-----------------------------+| 269 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 270 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 271 ||R|Link Descr: lo2:lo2 | |R|Link Descr LinkLocRmtID: 2:0 || 272 ||I| | |I|Link IP (mandatory): A2:B2|| 273 |+-+----------------------------+ +-+-----------------------------+| 274 ||A|Link IP (new): A1:B1 | |A|PeerAdjSID: 10002 || 275 ||T|Link IP (new): A3:B3 | |T|SRLG || 276 ||T|PeerNodeSID: 2 | |T|affinity group || 277 ||R|PeerSetSID (optional) | |R|MaxB/W || 278 || | | | |Unused B/W || 279 |+-+----------------------------+ +-+-----------------------------+| 280 |+-+----------------------------+ +-+-----------------------------+| 281 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 282 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 283 ||R|Link Descr: A3:B3 | |R|Link Descr LinkLocRmtID: 2:0 || 284 ||I| | |I|Link IP (mandatory): A3:B3|| 285 |+-+----------------------------+ +-+-----------------------------+| 286 || |PeerNodeSID: 3 | |A|PeerAdjSID: 10103 || 287 ||A|SRLG | |T|SRLG || 288 ||T|affinity group | |T|affinity group || 289 ||T|MaxB/W | |R|MaxB/W || 290 ||R|Unused B/W | | |Unused B/W || 291 || |... | | | || 292 |+-+----------------------------+ +-+-----------------------------+| 293 +------------------------------------------------------------------+ 294 ^ 295 BGP-LS EPE | 296 +----------> w/ InerDomain -------+ 297 | extensions 298 | 299 | +---------------------------------mh-eBGP--------------------+ 300 | | | 301 | | +-----------------------------mh-eBGP----------------+ | 302 | | | | | 303 +--+---+-----+ static lo1 --> +-----+ +-----+ +-----+---+--+ 304 | v v | static lo2 --> | L2 | | L2 | | v v | 305 | lo1 lo2 A1*------------------| swt |--->| swt |----*B1 lo2 lo1 | 306 | | +-----+ +-----+ | | 307 | | | | 308 | | | | 309 | RtR A | static lo1 --> | RtR B | 310 | A2*----------------------------------------*B2 | 311 | | | | 312 | | static lo2 --> | | 313 | A3*----------------------------------------*B3 | 314 | | | | 315 +-----------+^ ^+-----------+ 316 | | 317 | | 318 +-------------------eBGP-----------------+ 320 Figure 4: Example Advertisements 322 6. Backward Compatibility 324 The extension proposed in this document is backward compatible with 325 procedures described in [I-D.ietf-idr-bgpls-segment-routing-epe] and 326 [I-D.ietf-spring-segment-routing-central-epe] 328 7. Security Considerations 330 TBD 332 8. IANA Considerations 334 No new TLV code points are needed. 336 9. Acknowledgements 338 Thanks to Julian Lucek and Rafal Jan Szarecki for careful review and 339 suggestions. 341 10. References 343 10.1. Normative References 345 [I-D.ietf-idr-bgpls-segment-routing-epe] 346 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 347 S., and J. Dong, "BGP-LS extensions for Segment Routing 348 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 349 segment-routing-epe-18 (work in progress), March 2019. 351 [I-D.ietf-spring-segment-routing-central-epe] 352 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 353 Afanasiev, "Segment Routing Centralized BGP Egress Peer 354 Engineering", draft-ietf-spring-segment-routing-central- 355 epe-10 (work in progress), December 2017. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 363 S. Ray, "North-Bound Distribution of Link-State and 364 Traffic Engineering (TE) Information Using BGP", RFC 7752, 365 DOI 10.17487/RFC7752, March 2016, 366 . 368 10.2. Informative References 370 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 371 Decraene, B., Litkowski, S., and R. Shakir, "Segment 372 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 373 July 2018, . 375 Authors' Addresses 377 Shraddha Hegde 378 Juniper Networks Inc. 379 Exora Business Park 380 Bangalore, KA 560103 381 India 383 Email: shraddha@juniper.net 385 Srihari Sangli 386 Juniper Networks Inc. 387 Exora Business Park 388 Bangalore, KA 560103 389 India 391 Email: ssangli@juniper.net 393 Xiaohu Xu 394 Alibaba Inc. 395 Beijing 396 China 398 Email: xiaohu.xxh@alibaba-inc.com