idnits 2.17.1 draft-ietf-idr-ls-trill-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2018) is 2174 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard W. Hao 3 Updates: 7752 Y. Li 4 Huawei 5 S. Gupta 6 IP Infusion 7 M. Durrani 8 Equinix 9 Expires: October 14, 2018 April 15, 2018 11 Distribution of TRILL Link-State using BGP 12 14 Abstract 16 This draft describes a TRILL link state and MAC address reachability 17 information distribution mechanism using a BGP LS extension. 18 External components such as an SDN Controller can use the information 19 for topology visibility, troubleshooting, network automation, and the 20 like. This document updates RFC 7752. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the IDR working group mailing list: idr@ietf.org. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 2. Conventions used in this document.......................5 50 3. Carrying TRILL Link-State Information in BGP............6 51 3.1 Node Descriptors.......................................6 52 3.1.1 IGP Router-ID........................................7 53 3.2 MAC Address Descriptors................................7 54 3.2.1 MAC-Reachability TLV.................................8 55 3.3 The BGP-LS Attributes..................................8 56 3.3.1 Node Attribute TLVs..................................8 57 3.3.1.1 Node Flag Bits TLV.................................9 58 3.3.1.2 Opaque Node Attribute TLV..........................9 59 3.3.2. Link Attribute TLVs.................................9 61 4. Operational Considerations.............................10 62 5. Security Considerations................................11 63 6. IANA Considerations....................................11 65 Normative References......................................12 66 Informative References....................................13 68 Acknowledgments...........................................13 69 Authors' Addresses........................................14 71 1. Introduction 73 BGP has been extended to distribute IGP link-state and traffic 74 engineering information to some external components [RFC7752], such 75 as the PCE and ALTO servers. The information can be used by these 76 external components to compute a MPLS-TE path across IGP areas, 77 visualize and abstract network topology, and the like. 79 TRILL (Transparent Interconnection of Lots of Links) protocol 80 [RFC6325] provides a solution for least cost transparent routing in 81 multi-hop networks with arbitrary topologies and link technologies, 82 using [IS-IS] [RFC7176] link-state routing and a hop count. TRILL 83 switches are sometimes called RBridges (Routing Bridges). 85 The TRILL protocol has been deployed in many data center networks. 86 Data center automation is a vital step to increase the speed and 87 agility of business. An SDN controller as an external component 88 normally can be used to provide centralized control and automation 89 for the data center network. Providing a holistic view of whole 90 network topology to the SDN controller is an important part of data 91 center network automation and troubleshooting. 93 +-------------+ 94 | SDN | 95 --------| Controller |-------- 96 | +-------------+ | 97 | | 98 + + + + 99 + +-----------+ + 100 | | 101 +--------+ |IP Network | +--------+ 102 | | +----+ +----+ | | 103 +---+ +---+ | | | | | | | | +---+ +---+ 104 |ES1|-|RB1|-| Area 1 |-|BRB1| |BRB2|-| Area 2 |-|RB2|-|ES2| 105 +---+ +---+ | | +----+ +----+ | | +---+ +---+ 106 | | | | | | 107 +--------+ +-----------+ +--------+ 109 |<----TRILL ------>||<-----TRILL ----->| 111 Figure 1: TRILL interconnection 113 In Data Center interconnection scenario illustrated in Figure 1, a 114 single SDN Controller or network management system (NMS) can be used 115 for end-to-end network management. End-to-end topology visibility on 116 the SDN controller or NMS is very useful for whole network automation 117 and troubleshooting. BGP LS can be used by the external SDN 118 controller to collect multiple TRILL domain's link-state. 120 BGP LS also can be used for MAC address reachability information 121 synchronization across multiple TRILL domains. The transported MAC 122 reachability information and the like is for telemetry purposes and 123 for use by SDN controller(s) where the coordination or protocol 124 between the SDN controllers is out of scope. 126 This document describes the detailed BGP LS extension mechanisms for 127 TRILL link state and MAC address reachability information 128 distribution. This document updated [RFC7752] by creating a new IANA 129 registry for BGP-LS Node Descriptor Flag Bits. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 BGP - Border Gateway Protocol 139 BGP-LS - BGP Link-State 141 Data label - VLAN or FGL (Fine Grained Label [RFC7172]) 143 IGP - Interior Gateway Protocol 145 IS - Intermediate System (for this document, all relevant 146 intermediate systems are RBridges) 148 LS - Link State 150 NLRI - Network Layer Reachability Information 152 SDN - Software Defined Networking 154 RBridge - A device implementing the TRILL protocol 156 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 157 [RFC7176] 159 3. Carrying TRILL Link-State Information in BGP 161 In [RFC7752], several BGP-LS NLRI types are defined. For TRILL link- 162 state distribution, the Node NLRI and Link NLRI are extended to carry 163 layer 3 gateway role and link MTU information. TRILL specific 164 attributes are carried using opaque Node Attribute TLVs. Examples of 165 such attributes are nickname, distribution tree number and 166 identifiers, interested VLANs/Fine Grained Label, and multicast group 167 address, etc. 169 To differentiate the TRILL protocol from layer 3 IGP protocols, a new 170 TRILL Protocol-ID = TBD1 is specified. 172 ESADI (End Station Address Distribution Information) protocol 173 [RFC7357] is a per data label control plane MAC learning solution. 174 MAC address reachability information is carried in ESADI packets. 175 Compared with data plane MAC learning solution, ESADI protocol has 176 security and fast update advantage that are pointed out in [RFC7357]. 178 For an RBridge that is announcing participation in ESADI, the RBridge 179 can distribute MAC address reachability information to external 180 components using BGP. A new "MAC Reachability NLRI" NLRI type TBD2 is 181 used for the MAC address reachability distribution. 183 The MAC Reachability NLRI uses the format as shown in the following 184 Figure. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+ 189 | Protocol-ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Identifier | 192 | (64 bits) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 // Local Node Descriptor (variable) // 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 // MAC Address Descriptors (variable) // 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: The MAC Reachability NLRI format 201 3.1 Node Descriptors 203 The Node Descriptor Sub-TLV types include Autonomous System and BGP- 204 LS Identifier, IS-IS Area-ID and IGP Router-ID. TRILL uses a fixed 205 zero Area Address as specified in [RFC6325], Section 4.2.3. This is 206 encoded in a 4-byte Area Address TLV (TLV #1) as follows: 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | 0x01, Area Address Type | (1 byte) 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | 0x02, Length of Value | (1 byte) 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | 0x01, Length of Address | (1 byte) 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | 0x00, zero Area Address | (1 byte) 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 3: Area Address TLV 220 3.1.1 IGP Router-ID 222 Similar to layer 3 IS-IS, TRILL protocol uses 7-octet "IS-IS ID" as 223 the identity of an RBridge or a pseudonode, IGP Router ID sub-TLV in 224 Node Descriptor TLVs contains the 7-octet "IS-IS ID". In TRILL 225 network, each RBridge has a unique 48-bit (6-octet) IS-IS System ID. 226 This ID may be derived from any of the RBridge's unique MAC addresses 227 or configured. A pseudonode is assigned a 7-octet ID by the DRB 228 (Designated RBridge) that created it, the DRB is similar to the 229 "Designated Intermediate System" (DIS) corresponding to a LAN. 231 3.2 MAC Address Descriptors 233 The "MAC Address Descriptor" field is a set of Type/Length/Value 234 (TLV) triplets. "MAC Address Descriptor" TLVs uniquely identify an 235 MAC address reachable by a Node. The following attributes TLVs are 236 defined: 238 +--------------+---------------------+----------+-----------------+ 239 | TLV Code | Description | Length | Value defined | 240 | Point | | | in: | 241 +--------------+---------------------+----------+-----------------+ 242 | 1 | MAC-Reachability | variable | section 3.2.1 | 243 +--------------+---------------------+----------+-----------------+ 245 Table 1: MAC Address Descriptor TLVs 247 3.2.1 MAC-Reachability TLV 249 +-+-+-+-+-+-+-+-+ 250 | Type= MAC-RI | (1 byte) 251 +-+-+-+-+-+-+-+-+ 252 | Length | (1 byte) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+ 254 |V|F| RESV | Data Label | (4 bytes) 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MAC (1) (6 bytes) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | ................. | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | MAC (N) (6 bytes) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 4: MAC-Reachability TLV format 265 Length is 4 plus a multiple of 6. 267 The bits of 'V' and 'F' are used to identify Data Label type and are 268 defined as follows: 270 +----------+-------------------------+ 271 | Bit | Description | 272 +----------+-------------------------+ 273 | 'V' | VLAN | 274 | 'F' | Fine Grained Label | 275 +----------+-------------------------+ 277 Table 2: Data Label Type Bits Definitions 279 Notes: If BGP LS is used for NVO3 network MAC address distribution 280 between an external SDN Controller and NVE, Data Label can be used to 281 represent 24 bits VN ID. 283 3.3 The BGP-LS Attributes 285 3.3.1 Node Attribute TLVs 286 3.3.1.1 Node Flag Bits TLV 288 A new Node Flag bit TBD4 is added to the Node Flag Bits TLV. This 289 flag indicates that the node is a distributed Layer 3 gateway 290 [RFC7956]. 292 3.3.1.2 Opaque Node Attribute TLV 294 The Opaque Node Attribute TLV is used as the envelope to 295 transparently carry TRILL specific information. In most cases, this 296 information is encoded as sub-TLVs within the IS-IS Router Capability 297 and MT-Capability TLVs or as the Group Address (GADDR) TLV. Many of 298 these are specified in [RFC7176] but additional sub-TLVs have been 299 specified and may be specified in the future that also can be carried 300 using the Opaque Node Attribute TLV. 302 3.3.2. Link Attribute TLVs 304 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 305 attribute with a link NLRI. Besides the TLVs that has been defined in 306 [RFC7752] section 3.3.2 Table 9, the following 'Link Attribute' TLV 307 is provided for TRILL. 309 +----------+--------------+------------+-----------------------+ 310 | TLV Code | Description | IS-IS TLV | Defined in: | 311 | Point | | /Sub-TLV | | 312 +----------+--------------+------------+-----------------------+ 313 | TBD3 | Link MTU | 22/28 | [RFC7176] Section 2.4 | 314 +----------+--------------+------------+-----------------------+ 316 Table 7: Link Attribute TLVs 318 4. Operational Considerations 320 This document does not require any MIB or YANG model to configure 321 operational parameters. 323 Any implementation of this specification (i.e. that distributes TRILL 324 Link-State information using BGP), MUST do the malformed attribute 325 checks below, and if it detects a malformed attribute, it should use 326 the 'Attribute Discard' action per [I-D.ietf.idr-error-handling] 327 section 2. 329 An implementation MUST perform the following expanded BGP-LS 330 syntactic check for determining if the message is malformed: 332 o Does the sum of all TLVs found in the BGP LS attribute correspond 333 to the BGP LS path attribute length ? 335 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 336 correspond to the BGP MP_REACH_NLRI length ? 338 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 339 attribute correspond to the BGP MP_UNREACH_NLRI length ? 341 o Does the sum of all TLVs found in a Node-, Link, prefix (IPv4 or 342 IPv6) NLRI attribute correspond to the Node-, Link- or Prefix 343 Descriptors 'Total NLRI Length' field ? 345 o Does every fixed length TLV correspond to the TLV Length field in 346 this document ? 348 o Does the sum of MAC reachability TLVs equal the length of the 349 field? 351 In addition, the following checks need to be made for the fields 352 specific to the BGP LS for TRILL: 354 PROTOCOL ID is TRILL 356 NLRI types are valid 358 MAC Reachability NLRI has correct format including: 360 o Identifier (64 bits), 362 o local node descriptor with AREA address TLV has the form 363 found in Figure 2 365 5. Security Considerations 367 Procedures and protocol extensions defined in this document do not 368 affect the BGP security model. See [RFC6952] for details. 370 6. IANA Considerations 372 For all of the following assignments, [this document] is the 373 reference. 375 IANA is requested to assign one Protocol-ID TBD1 for "TRILL" from the 376 BGP-LS registry of Protocol-IDs. 378 IANA is requested to assign one NLRI Type TBD2 for "MAC Reachability" 379 from the BGP-LS registry of NLRI Types. 381 IANA is requested to assign one new TLV type TBD3 for "Link MTU" from 382 the BGP-LS registry of BGP-LS Attribute TLVs. 384 IANA is requested to create a registry for BGP-LS Node Descriptor 385 Flag Bits and to assign one Node Flag bit TBF4 [bit 6 suggested] for 386 "Layer 3 Gateway". This new registry is to be added to the IANA 387 Border Gateway Protocol - Link State (BGP-LS) Parameters web page as 388 follows: 390 Name: BGP-LS Node Descriptor Flag Bits 391 Registration Procedure: Expert Review 392 Reference: [RFC7752] 393 Note: These bits are in the payload of the Node Flag Bits TLV. 394 The bit array is variable length so the maximum bit value 395 assignable is very large; however, length of the TLV grows 396 linearly with the highest numbered flag bit used and there 397 may be practical limits on the length of the TLV. 399 Bit Letter Description Reference 400 ---- ------ -------------- ------------ 401 0 O Overload Bit [ISO10589] 402 1 T Attached Bit [ISO10589] 403 2 E External Bit [RFC2328] 404 3 B ABR Bit [RFC2328] 405 4 R Router Bit [RFC5340] 406 5 V V6 Bit [RFC5340] 407 6 G L3 Gateway Bit [this document][RFC7956] 408 7-up - Unassigned 410 Normative References 412 [I-D.ietf.idr-error-handling] - Enke, C., John, S., Pradosh, M., 413 Keyur,P., "Revised Error Handling for BGP UPDATE Messages", 414 draft-ietf-idr-error-handling-19(work in progress), April 2015. 416 [IS-IS] - International Organization for Standardization, 417 "Information technology -- Telecommunications and information 418 exchange between systems -- Intermediate System to Intermediate 419 System intra-domain routeing information exchange protocol for 420 use in conjunction with the protocol for providing the 421 connectionless-mode network service (ISO 8473)", ISO/IEC 422 10589:2002, Second Edition, November 2002. 424 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 428 Ghanwani, "Routing Bridges (RBridges): Base Protocol 429 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 430 . 432 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 433 and D. Dutt, "Transparent Interconnection of Lots of Links 434 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 435 10.17487/RFC7172, May 2014, . 438 [RFC7176] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 439 Banerjee, A.," Transparent Interconnection of Lots of Links 440 (TRILL) Use of IS-IS", May 2014. 442 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 443 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 444 End Station Address Distribution Information (ESADI) Protocol", 445 RFC 7357, September 2014, . 448 [RFC7752] - Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., 449 and S. Ray, "North-Bound Distribution of Link-State and Traffic 450 Engineering (TE) Information Using BGP", RFC 7752, DOI 451 10.17487/RFC7752, March 2016, . 454 [RFC7956] - Hao, W., Li, Y., Qu, A., Durrani, M., and P. Sivamurugan, 455 "Transparent Interconnection of Lots of Links (TRILL) 456 Distributed Layer 3 Gateway", RFC 7956, DOI 10.17487/RFC7956, 457 September 2016, . 459 Informative References 461 [ISO10589] - SO, "Intermediate System to Intermediate System intra- 462 domain routeing information exchange protocol for use in 463 conjunction with the protocol for providing the connectionless- 464 mode network service (ISO 8473)", International Standard 465 10589:2002, Second Edition, 2002. 467 [RFC2328] - Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 468 10.17487/RFC2328, April 1998, . 471 [RFC5340] - Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 472 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 473 . 475 [RFC6952] - Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 476 BGP, LDP, PCEP, and MSDP Issues According to the Keying and 477 Authentication for Routing Protocols (KARP) Design Guide", RFC 478 6952, DOI 10.17487/RFC6952, May 2013, 481 Acknowledgments 483 Authors thank Susan Hares, John Scudder, Ross Callon, Andrew Qu, Jie 484 Dong, Mingui Zhang, Qin Wu, Shunwan Zhuang, Zitao Wang, Lili Wang for 485 their valuable inputs. 487 Authors' Addresses 489 Weiguo Hao 490 Huawei Technologies 491 101 Software Avenue, 492 Nanjing 210012 493 China 495 Phone: +86-25-56623144 496 Email: haoweiguo@huawei.com 498 Donald E. Eastlake 499 Huawei Technologies 500 155 Beaver Street 501 Milford, MA 01757 USA 503 Phone: +1-508-333-2270 504 Email: d3e3e3@gmail.com 506 Yizhou Li 507 Huawei Technologies 508 101 Software Avenue, 509 Nanjing 210012, China 511 Phone: +86-25-56625375 512 Email: liyizhou@huawei.com 514 Sujay Gupta 515 IP Infusion 517 Email: sujay.gupta@ipinfusion.com 519 Muhammad Durrani 520 Equinix 522 Email: mdurrani@equinix.com 524 Copyright, Disclaimer, and Additional IPR Provisions 526 Copyright (c) 2018 IETF Trust and the persons identified as the 527 document authors. All rights reserved. 529 This document is subject to BCP 78 and the IETF Trust's Legal 530 Provisions Relating to IETF Documents 531 (http://trustee.ietf.org/license-info) in effect on the date of 532 publication of this document. Please review these documents 533 carefully, as they describe your rights and restrictions with respect 534 to this document. Code Components extracted from this document must 535 include Simplified BSD License text as described in Section 4.e of 536 the Trust Legal Provisions and are provided without warranty as 537 described in the Simplified BSD License. The definitive version of 538 an IETF Document is that published by, or under the auspices of, the 539 IETF. Versions of IETF Documents that are published by third parties, 540 including those that are translated into other languages, should not 541 be considered to be definitive versions of IETF Documents. The 542 definitive version of these Legal Provisions is that published by, or 543 under the auspices of, the IETF. Versions of these Legal Provisions 544 that are published by third parties, including those that are 545 translated into other languages, should not be considered to be 546 definitive versions of these Legal Provisions. For the avoidance of 547 doubt, each Contributor to the IETF Standards Process licenses each 548 Contribution that he or she makes as part of the IETF Standards 549 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 550 language to the contrary, or terms, conditions or rights that differ 551 from or are inconsistent with the rights and licenses granted under 552 RFC 5378, shall have any effect and shall be null and void, whether 553 published or posted by such Contributor, or included with or in such 554 Contribution.