idnits 2.17.1 draft-hegde-idr-bgp-ls-epe-inter-as-02.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 (November 1, 2019) is 1610 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 432, but no explicit reference was found in the text ** 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: 4 errors (**), 0 flaws (~~), 3 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 M. Srivastava 5 Expires: May 4, 2020 Juniper Networks Inc. 6 X. Xu 7 Alibaba Inc. 8 November 1, 2019 10 BGP-LS Extensions for Inter-AS TE using EPE based mechanisms 11 draft-hegde-idr-bgp-ls-epe-inter-as-02 13 Abstract 15 In certain network deployments, a single operator has multiple 16 Autonomous Systems(AS) to facilitate ease of management. A multiple 17 AS network design could also be a result of network mergers and 18 acquisitions. In such scenarios, a centralized Inter-domain TE 19 approach could provide most optimal allocation of resources and the 20 most controlled path placement. BGP-LS-EPE 21 [I-D.ietf-idr-bgpls-segment-routing-epe] describes an extension to 22 BGP Link State (BGP-LS) for the advertisement of BGP Peering Segments 23 along with their BGP peering node and inter-AS link information, so 24 that efficient BGP Egress Peer Engineering (EPE) policies and 25 strategies can be computed based on Segment Routing. This document 26 describes extensions to the BGP-LS EPE to enable it to be used for 27 inter-AS Traffic-Engineering (TE) purposes. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 4, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Reference Topology . . . . . . . . . . . . . . . . . . . . . 3 70 3. Fast Reroute Label . . . . . . . . . . . . . . . . . . . . . 4 71 4. TE Link attributes of PeerNode SID . . . . . . . . . . . . . 5 72 5. TE Link attributes of PeerAdj SID . . . . . . . . . . . . . . 5 73 6. Link address TLV . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Example Advertisements . . . . . . . . . . . . . . . . . . . 7 75 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 12.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Segment Routing (SR) leverages source routing. A node steers a 87 packet through a controlled set of instructions, called segments, by 88 prepending the packet with an SR header with segment identifiers 89 (SID). A SID can represent any instruction, topological or service- 90 based. SR segments allows to enforce a flow through any topological 91 path or service function while maintaining per-flow state only at the 92 ingress node of the SR domain. 94 As there is no per-path state in the network, the bandwidth 95 management for the paths is expected to be handled by a centralized 96 entity which has a complete view of: 98 1. Up-to-date topology of the network 100 2. Resources, States and Attributes of links and nodes of the 101 network 103 3. Run-time utilization/availability of resources 105 The BGP Link-State extensions provide mechanisms whereby link-state 106 and TE information can be propagated n a network and a consumer of 107 such BGP LS updates may build topology, provide bandwidth calendering 108 and other traffic engineering services. The centralized entity can 109 be such a consumer (also referred to as controller). In the case of 110 multi-AS networks, the controller needs to learn the per-AS network 111 information and the inter-AS link information thus arriving at a 112 consolidated Traffic Engineering Database which can be used to 113 compute end-to-end Traffic Engineering Path. The controller can 114 learn the topology, link-state and TE information from each of the AS 115 networks either by participating in their IGPs or by listening to BGP 116 LS updates [RFC7752]. Similar information about the inter-AS links 117 can be learnt via BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] 118 along with extensions defined in this documet. 120 2. Reference Topology 122 The controller learns TE attributes of all the links, including the 123 inter-AS links and uses the attributes to compute constrained paths. 124 The controller should be able to correlate the inter-AS links for 125 bidirectional connectivity from both ASes. 127 +----------+ 128 |Controller| 129 +----------+ 130 | 131 |----------| 132 +---------+ +------+ 133 | | | | 134 | H B------D G 135 | | +---/| AS 2 |\ +------+ 136 | |/ +------+ \ | |---L/8 137 A AS1 C---+ \| | 138 | |\\ \ +------+ /| AS 4 |---M/8 139 | | \\ +-E |/ +------+ 140 | X | \\ | K 141 | | +===F AS 3 | 142 +---------+ +------+ 144 Figure 1: Reference Diagram 146 The reference diagram from 147 [I-D.ietf-spring-segment-routing-central-epe] represents multiple 148 Autonomous Systems connected to each other. When the Multiple ASes 149 belong to same operator and are organised into separate domains for 150 operational purposes, it is advantageous to support Traffic- 151 Engineering across the ASes including the inter-AS links. The 152 controller has visibility of all of the ASes by means of IGP topology 153 exported via BGP-LS [RFC7752], or other means. In addition, the 154 inter-AS links and the labels associated with the inter-AS links are 155 exported via [I-D.ietf-idr-bgpls-segment-routing-epe]. The 156 controller needs to correlate the information acquired from all of 157 the ASes, including the inter-AS links in order to get a view of the 158 unified topology so that it can build end-to-end Traffic-Engineered 159 paths. 161 3. Fast Reroute Label 163 [I-D.ietf-spring-segment-routing-central-epe] section 3.6 describes 164 mechanisms to provide Fast Reroute (FRR) protection for the EPE 165 Labels. The BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] 166 describes "B" bit to indicate that a PeerNodeSID or PeerAdjSID is 167 eligible for backup. However, it does not specify what is the 168 behaviour when the failure kicks-in. The controller needs to know 169 which links are used for protection so that admission control and 170 failure simulation can be done effectively and appropriate inter-AS 171 links used for path construction. 173 This document defines a new flag "F" in the Peering SIDs TLV to 174 indicate a SID as an FRR SID. With the "F" flag set, the protection 175 for any peering SID can be specified using another PeerAdjSID, 176 PeerNodeSID or PeerSetSID to the controller. If the protection is 177 achieved by fallback to local IP lookup, FRR SID SHOULD not be 178 advertised. The link(s) represented by the FRR SID will carry the 179 traffic when there is a failure. These SIDs are included as an FRR 180 SIDs in the peerAdjSID, PeerNodeSID and PeerSetSID advertisements. 182 0 1 2 3 4 5 6 7 183 +-+-+-+-+-+-+-+-+ 184 |V|L|B|P|F|Rsvd | 185 +-+-+-+-+-+-+-+-+ 187 Figure 2: Peering SID TLV Flags Format 189 * F-Flag: FRR Label Flag: If set, the peer SID where the FRR Label 190 appears is using backup links represented by FRR Label. 192 4. TE Link attributes of PeerNode SID 194 In any eBGP deployment, the peering session can be either single-hop 195 of multi-hop. For single-hop eBGP sessions, the peering address is 196 that of the directly attached interface to which the session is 197 pinned down. For multi-hop eBGP session, the peering adress is 198 reachable over more than one interface and that the peering session 199 is not pinned down to any of the directly attached interfaces. 201 A Peer Node Segment is a segment describing a peer, including the SID 202 (PeerNodeSID) allocated to it. The link descriptors for the 203 PeerNodeSID include the addresses used by the BGP session encoded 204 using TLVs as defined in [RFC7752]. Since the eBGP session can be 205 either single-hop or multi-hop, the IP address used by BGP session as 206 local/neigbour is not sufficient to identify the underlaying 207 interface(s). Also, the controller needs to know the links 208 associated with the PeerNodeSID, to be able derive TE link 209 attributes. This can be achieved by including the interface local 210 and remote addresses in the Link attributes in PeerNodeSID NLRI. 211 This document defines a new link attribute TLV name Interface Address 212 TLV. PeerNodeSID NLRI MAY optionally include Interface Address TLV. 214 5. TE Link attributes of PeerAdj SID 216 PeerAdjSID MUST be advertised for each inter-AS link for the purposes 217 of inter-AS TE. The PeerAdjSID should contain link TE attributes 218 such as bandwidth, admin-group etc. The PeerAdjSID should also 219 contain the local and remote interface IPv4/IPv6 addresses which is 220 used for correlating the links. PeerNodeSID SHOULD contain the 221 additional attribute of link local address which is used by the 222 controller to find corresponding PeerAdjSID and hence the 223 corresponding link TE attributes. 225 A peerAdj segment carries mandatory link descriptors as local and 226 remote link id. Remote link id of the neighboring ASBR is not 227 readily available. [I-D.ietf-idr-bgpls-segment-routing-epe] suggests 228 to carry the value '0' for the remote link id. The Controller needs 229 to associate the links in both directions to effectively handle 230 failure notifications and for this purpose a unque remote link is 231 necessary. The remote link ID cannot be manually configured on the 232 router as the link-ids generally change over router reboot etc and 233 hence manual configuration is operationally very difficult to manage. 234 This document mandates advertisement of local and remote iterface 235 addresses for the inetr-AS TE purposes. 237 The Unnumbered interface is not in the scope of this document. 239 6. Link address TLV 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |Type = TBD | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | No.of IPV4 interface pairs |No. of IPv6 interface Pairs | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Local Interface address1 (4/16 octets) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Remote Interface address1 (4/16 octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Local Interface address2 (4/16 octets) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | ...... | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3: Link Address TLV carried as attribute 259 Type : TBD 261 Length : variable based on ipv4/ipv6 interface address 262 Number of IPv4 interface pairs: 264 Number of IPv6 interface pairs: 266 There may be a number of parallel interfaces and few or all of them 267 may be used for the PeerNodeSID. These interfaces may have both IPV4 268 and IPV6 address or some interfaces may be IPv4 only and some IPv6 269 only. The total number of IPv4 and IPv6 interface address count is 270 carried seperately in above fields. 272 Local Interface Address : 274 The interface local address ipv4/ipv6 which corresponds to the 275 PeerNodeSID MUST be specified. For IPv4,this field is 4 octets; for 276 IPv6, this field is 16 octets. 278 Remote Interface Address : 280 The interface remote address ipv4/ipv6 which corresponds to the 281 PeerNodeSID MUST be specified. For IPv4,this field is 4 octets; for 282 IPv6, this field is 16 octets. 284 There can be multiple Layer 3 interfaces on which a peerNodeSId 285 loadbalances the traffic. All such interfaces local/remote address 286 MUST be included when a Link address TLV is added.When a single Layer 287 3 interface consists of multiple addresses or when a link has both 288 IPv4 and IPv6 addresses configured, It is sufficient to include one 289 such pair (either IPV4 or IPv6)address for the PeerNodeSID 290 advertisement. When a PeerNodeSID load-balances over few interfaces 291 with IPv4 only address and few interfaces with IPv6 address then the 292 Link address TLV should list all IPv4 address pairs together followed 293 by IPv6 address pairs. 295 7. Example Advertisements 297 The below diagram represents two ASBR routers and inter-AS links 298 between them. The inter-AS links could be connected via switches L1 299 and L2 as shown in the diagram or via Point-to-point links A2->B2, 300 A3->B3 as shown in the diagram below. In the below example, lets 301 assume peerNodeSID 1 is configured to use peerAdjSID 10002 then 302 PeerNodeSID 1 will have the B bit set which means the PeerNodeSID 1 303 is eligible for backup. Label 10002 is added to the PeerNodeSID with 304 a "F" bit set, which means 10002 is a backup for PeerNodeSID 1. 306 +------------------------------------------------------------------+ 307 | PeerNodeSID PeerAdjSID | 308 | | 309 |+-+----------------------------+ +-+-----------------------------+| 310 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 311 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 312 ||R|Link Descr: lo1:lo1 | |R|Link Descr LinkLocRmtID: 1:0 || 313 ||I| | |I|Link IP (mandatory): A1:B1|| 314 |+-+----------------------------+ +-+-----------------------------+| 315 ||A|Intf Adress(new): A1:B1 | |A|PeerAdjSID: 10001 || 316 ||T| A2:B2 | |T|SRLG || 317 ||T|PeerNodeSID: 1 | |T|affinity group || 318 ||R|PeerSetSID (optional) | |R|MaxB/W || 319 |+-+----------------------------+ +-+-----------------------------+| 320 |+-+----------------------------+ +-+-----------------------------+| 321 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 322 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 323 ||R|Link Descr: lo2:lo2 | |R|Link Descr LinkLocRmtID: 2:0 || 324 ||I| | |I|Link IP (mandatory): A2:B2|| 325 |+-+----------------------------+ +-+-----------------------------+| 326 ||A|Intf addr (new): A1:B1 | |A|PeerAdjSID: 10002 || 327 ||T| : A3:B3 | |T|SRLG || 328 ||T|PeerNodeSID: 2 | |T|affinity group || 329 ||R|PeerSetSID (optional) | |R|MaxB/W || 330 || | | | |Unused B/W || 331 |+-+----------------------------+ +-+-----------------------------+| 332 |+-+----------------------------+ +-+-----------------------------+| 333 ||N|Loc Node Descr: AS1:A | |N|Loc Node Descr: AS1:A|| 334 ||L|Rmt Node Descr: AS2:B | |L|Rmt Node Descr: AS2:B|| 335 ||R|Link Descr: A3:B3 | |R|Link Descr LinkLocRmtID: 2:0 || 336 ||I| | |I|Link IP (mandatory): A3:B3|| 337 |+-+----------------------------+ +-+-----------------------------+| 338 || |PeerNodeSID: 3 | |A|PeerAdjSID: 10103 || 339 ||A|SRLG | |T|SRLG || 340 ||T|affinity group | |T|affinity group || 341 ||T|MaxB/W | |R|MaxB/W || 342 ||R|Unused B/W | | |Unused B/W || 343 || |... | | | || 344 |+-+----------------------------+ +-+-----------------------------+| 345 +------------------------------------------------------------------+ 346 ^ 347 BGP-LS EPE | 348 +----------> w/ InerDomain -------+ 349 | extensions 350 | 351 | +---------------------------------mh-eBGP--------------------+ 352 | | | 353 | | +-----------------------------mh-eBGP----------------+ | 354 | | | | | 355 +--+---+-----+ static lo1 --> +-----+ +-----+ +-----+---+--+ 356 | v v | static lo2 --> | L2 | | L2 | | v v | 357 | lo1 lo2 A1*------------------| swt |--->| swt |----*B1 lo2 lo1 | 358 | | +-----+ +-----+ | | 359 | | | | 360 | | | | 361 | RtR A | static lo1 --> | RtR B | 362 | A2*----------------------------------------*B2 | 363 | | | | 364 | | static lo2 --> | | 365 | A3*----------------------------------------*B3 | 366 | | | | 367 +-----------+^ ^+-----------+ 368 | | 369 | | 370 +-------------------eBGP-----------------+ 372 Figure 4: Example Advertisements 374 8. Backward Compatibility 376 The extension proposed in this document is backward compatible with 377 procedures described in [I-D.ietf-idr-bgpls-segment-routing-epe] and 378 [I-D.ietf-spring-segment-routing-central-epe] 380 9. Security Considerations 382 TBD 384 10. IANA Considerations 386 New attribute TLV in BGP-LS Node Descriptor, Link Descriptor, Prefix 387 Descriptor, and Attribute TLVs registry 389 +-----------+-----------------------+--------------+------------------+ 390 | TLV Code | Description | IS-IS TLV | Reference | 391 | Point | | /Sub-TLV | (RFC/Section) | 392 +-----------+-----------------------+--------------+------------------+ 393 | TBD | Link address TLV | NA | This draft | 394 +---------------------------------------------------------------------+ 396 Figure 5: IANA code point 398 11. Acknowledgements 400 Thanks to Julian Lucek and Rafal Jan Szarecki for careful review and 401 suggestions. 403 12. References 405 12.1. Normative References 407 [I-D.ietf-idr-bgpls-segment-routing-epe] 408 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 409 S., and J. Dong, "BGP-LS extensions for Segment Routing 410 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 411 segment-routing-epe-19 (work in progress), May 2019. 413 [I-D.ietf-spring-segment-routing-central-epe] 414 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 415 Afanasiev, "Segment Routing Centralized BGP Egress Peer 416 Engineering", draft-ietf-spring-segment-routing-central- 417 epe-10 (work in progress), December 2017. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 425 S. Ray, "North-Bound Distribution of Link-State and 426 Traffic Engineering (TE) Information Using BGP", RFC 7752, 427 DOI 10.17487/RFC7752, March 2016, 428 . 430 12.2. Informative References 432 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 433 Decraene, B., Litkowski, S., and R. Shakir, "Segment 434 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 435 July 2018, . 437 Authors' Addresses 439 Shraddha Hegde 440 Juniper Networks Inc. 441 Exora Business Park 442 Bangalore, KA 560103 443 India 445 Email: shraddha@juniper.net 446 Srihari Sangli 447 Juniper Networks Inc. 448 Exora Business Park 449 Bangalore, KA 560103 450 India 452 Email: ssangli@juniper.net 454 Mukul Srivastava 455 Juniper Networks Inc. 457 Email: msri@juniper.net 459 Xiaohu Xu 460 Alibaba Inc. 461 Beijing 462 China 464 Email: xiaohu.xxh@alibaba-inc.com