idnits 2.17.1 draft-ietf-trill-routing-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 451. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. 'TARCH' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Gray 2 Internet Draft Editor 3 Expires: July, 2007 Ericsson 5 January, 2007 7 TRILL Routing Requirements in Support of RBridges 8 draft-ietf-trill-routing-reqs-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 31, 2007. 36 Abstract 38 RBridges provide the ability to have an entire domain, with multiple 39 physical links, look to IP like a single subnet. The design allows 40 for zero configuration of switches within an RBridge domain, optimal 41 pair-wise routing, safe forwarding even during periods of temporary 42 loops, and potential additional advantages as well. The design also 43 supports VLANs, allows forwarding tables to be based on destinations 44 within the RBridge domain (rather than station destinations, allowing 45 internal forwarding tables to be smaller than in conventional bridge 46 systems). 48 The intent is to re-uses one or more existing routing protocols to 49 accomplish these goals. 51 This document lays out the background and specific requirements of 52 potential routing protocols to be considered for use in this design. 53 In particular, this document defines what is needed to accomodate 54 this design using IS-IS (or OSPF) as a basis for RBridge protocols. 56 Table of Contents 58 1. Introduction....................................................3 59 1.1. Terminology................................................4 60 1.2. Specific TRILL Goals.......................................5 61 2. General Requirements Potentially Affecting Routing..............6 62 3. Link State Protocol Specific Requirements.......................6 63 4. Potential Issues................................................7 64 4.1. Interactions with Spanning Tree Forwarding.................7 65 4.2. Computing Routes...........................................8 66 4.3. RBridge Interactions with Routing..........................8 67 5. Security Considerations.........................................8 68 6. Conclusions.....................................................9 69 7. IANA Considerations.............................................9 70 8. Acknowledgments.................................................9 71 9. References.....................................................10 72 9.1. Normative References......................................10 73 9.2. Informative References....................................10 74 10. Author's Address(es)..........................................10 75 11. Intellectual Property Statement...............................10 76 12. Disclaimer of Validity........................................11 77 13. Copyright Statement...........................................11 78 14. Acknowledgment................................................11 80 1. Introduction 82 The current dominant approach to segregating network traffic relies 83 on a hierarchical arrangement of bridges and routers. Hierarchy is 84 further extended - both within routing protocols (such as IS-IS and 85 OSPF) and between routing protocols (for example, between IGPs and 86 BGP). At least part of the current network structure is based on a 87 determined trade-off between limitations of IP routing and similar 88 disadvantages of 802 bridging. 90 Bridging Limitations 92 For example, bridged networks consist of single broadcast/flooding 93 domains. Ethernet/802 encapsulation (on which bridging is based) 94 does not provide mechanisms for reducing the impact of looping data 95 traffic that may result from a transient change in network topology 96 and the existence of multiple paths. 98 The impact of looping traffic is far worse with flooded or broadcast 99 traffic as this results in exponentially increasing traffic load. 100 Consideration of the impacts of looping data lead to the use of 101 STP/RSTP to establish a connected - loop free - tree by disabling 102 forwarding on a subset of links that might create a loop. This has 103 also the effect of eliminating redundant paths, reducing aggregate 104 throughput and increasing latency through the network. 106 Because of the potential for severe impact from looping traffic, 107 many (if not most) current bridge implementations stop forwarding of 108 traffic frames following a topology change event and restart only 109 after STP/RSTP is complete. 111 As a result, the process of eliminating potential loops in existing 112 bridging deployments: 114 1) Results in inefficient use of inter-bridge connections 115 and 116 2) May cause delays in forwarding traffic as a result of 117 changes in the network topology. 119 The combined effect of broadcast/flooding traffic, and the use of 120 spanning trees for loop avoidance, sets practical limits on bridged 121 network size in the network hierarchy and results in inefficient 122 bandwidth use of inter-bridge connections. Inefficient inter-bridge 123 connection usage similarly limits the usefulness of bridging with 124 high-speed (and consequently high cost) interfaces. 126 IP Routing Issues 128 For IP routed networks, any link (or subnet) must have at least one 129 unique prefix. This means that a node that moves from one IP subnet 130 to another must change its IP address. Also, nodes with multiple IP 131 subnet attachments must have multiple IP addresses. In IP routed 132 networks, there are frequent trade-off considerations between using 133 smaller subnets (longer prefix length) to minimize wasted IP address 134 space (as a result of unused addresses in the fixed address range 135 defined by the prefix and length) and using larger subnets (shorter 136 prefix length) to minimize the need for (changes in) configuration. 138 In any case - with current IP routing technology - subnets must be 139 configured for each routed interface. 141 Proposed Solution 143 Using a hybrid of routing and bridging - an RBridge - we hope to 144 gain the benefits of both technologies, in particular, gaining the 145 bandwidth advantages of shortest path routing while retaining the 146 simplified configuration associated with bridging. 148 1.1. Terminology 150 The following terms are used in this document in the way that 151 they are defined in "TRILL RBridge Architecture" [TARCH]: 153 ARP (Address Resolution Protocol) 154 Bridge Learning 155 Broadcast Domain 156 Broadcast Traffic 157 Cooperating RBridges 158 Egress RBridge 159 Ethernet 160 Flooded Traffic 161 Flooding 162 Frame 163 IGP (Interior Gateway Protocol) 164 Ingress RBridge 165 Ingress RBridge Tree 166 IS-IS (Intermediate System to Intermediate System) 167 ND (Neighbor Discovery) 168 OSPF (Open Shortest Path First) 169 RBridge 170 SPF (Shortest Path First) 171 Station 172 STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol) 173 TRILL (TRansport Interconnect over Lots of Links) 174 Unknown Destination 175 VLAN (Virtual Local Area Network) 177 1.2. Specific TRILL Goals 179 (Near) Zero Configuration 181 It is a TRILL requirement that it must be possible to deploy RBridges 182 in at least a nominal set of potential deployment scenarios without a 183 need to perform any configuration at each RBridge. It is possible to 184 meet this goal for a sub-set of all possible deployment scenarios by 185 making realistic restrictions on deployment - such as restricting the 186 deployment scenarios to exclude those involving a "trust model" that 187 imposes a need for configuration of some form of "shared secret" or 188 other configuration required to restrict access to "trusted" devices. 190 It is also conceivable that a minimal configuration may be required 191 for deployment of an initial (set of) device(s) - with subsequently 192 deployed devices deriving that configuration information during the 193 process of - for example - peer discovery. This would constitute a 194 mechanism for "near zero configuration". 196 Efficient Unicast Bandwidth Usage 198 For unicast, non-flooded traffic, RBridges are intended to merge the 199 efficient bandwidth use of IP routing with the simplicity of Ethernet 200 (or 802.1) bridging for networks possibly larger - and with greater 201 forwarding capacity - than is the case with these networks presently. 203 The approach that we will use in accomplishing this is based on the 204 idea of extending (one or more) link state routing protocol(s) to 205 include distribution of Ethernet/802 reachability information between 206 RBridges. In addition, there may be specific requirements imposed on 207 the interactions between these extensions and Spanning Tree Protocol 208 (STP) and between RBridges and (potentially co-located) IP routing 209 instances. 211 Potentially More Efficient Multicast and Broadcast Usage 213 There are clear advantages to incorporating mechanisms for improved 214 efficiency in forwarding (layer 2) multicast frames and - possibly 215 in reducing the amount of broadcast traffic as well. To the extent 216 that these efficiency improvements may be considered "optimizations" 217 and may be defined orthogonally to the process of specifying basic 218 RBridge functionality, the potential to include these optimizations 219 is (highly) desirable, but not mandatory. 221 Examples of this type of optimization include use of any intrinsic 222 multicast routing capabilities and optimizations of ARP/ND. 224 Backward Compatibility 226 RBridges must be fully compatible with current bridges, IPv4 and 227 IPv6 routers and stations. They should be invisible to current IP 228 routers (just as bridges are), and like routers, they terminate a 229 bridged spanning tree, (i.e. - they do not forward BPDUs). Unlike 230 Routers, RBridges do not terminate a broadcast domain. 232 2. General Requirements Potentially Affecting Routing 234 Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated 235 for compatibility with the above goals. 237 For example, since IS-IS requires a unique System ID for each IS-IS 238 instance (at least within a "scoped" deployment), a requirement for 239 "(near) zero configuration" implies a need for mechanisms that allow 240 auto-configuration and/or negotiation of these (scoped) unique IDs. 242 Similar requirement must apply for OSPF as well, if selected. 244 In addition, forwarding of protocol messages must be compatible with 245 (or reasonably adaptable to) use of forwarding at layer 2, or there 246 must be a means for deriving suitable higher layer addresses for the 247 purpose of protocol exchanges - without imposing the need to manually 248 configure higher-layer addresses. 250 3. Link State Protocol Specific Requirements 252 Assuming that link state routing protocols meet above requirements, 253 running a link state protocol among RBridges is straightforward. It 254 is the same as running a level 1 routing protocol in an area. This 255 would be theoretically true for either IS-IS or OSPF, assuming that 256 both of these meet the general requiremenst above. 258 From the perspective of simply extending existing routing protocols, 259 IS-IS is a more appropriate choice than OSPF because it is easy in 260 IS-IS to define new TLVs for use in carrying a new information type. 261 This document, however, does not mandate a specific link-state, IGP, 262 routing protocol. Instead, it sets forth the requirements that will 263 apply to any link-state routing protocol that may be used. 265 For implementations providing co-located Router/RBridge function, 266 it is necessary to have mechanisms for distinguishing any protocol 267 interactions in Routing instances from protocol interactions in the 268 co-located RBridge instance. Specific mechanisms we will use are 269 very likely to be determined by the Link State Routing Protocol that 270 we select. Potential distinguishing mechanisms include use of a new 271 well-known Ethernet/802 multicast address, higher-layer protocol ID 272 or other - routing protocol specific - approaches. 274 The mechanism chosen should be consistent with the TRILL goals. If, 275 for example, a routing protocol specific approach required use of a 276 unique "area" identifier, the RBridge area identifier should be a 277 constant, well-known, value for all RBridges, and would not be one 278 that would ever appear as a real routing area identifer - in order 279 to allow for a potential for configuration-free operation. 281 Information that RBridge link state information will carry includes: 283 o layer 2 addresses of nodes within the domain which have 284 transmitted frames but have not transmitted ARP or ND replies 286 o layer 3, layer 2 addresses of IP nodes within the domain. For 287 data compression, perhaps only the portion of the address 288 following the domain-wide prefix need be carried. This will be 289 more of an issue for IPv6 than for IPv4. 291 o VLANs directly connected to this RBridge 293 Station information need only be delivered to RBridges supporting 294 the VLAN in which the station resides. So, for instance, if station 295 E is discovered through a VLAN A frame, then E's location need only 296 be delivered to other RBridges that are attached to VLAN A links. 298 Given that RBridges must support delivery only to links within a VLAN 299 (for multicast or unknown frames marked with the VLAN's tag), this 300 mechanism can be used to advertise station information solely to the 301 RBridges "within" a VLAN (i.e. - having connectivity or configuration 302 that associates them with a VLAN). Although a separate instance of 303 the link state protocol could be run for this purpose, the topology 304 is so restricted (just a single broadcast domain), that it may be 305 preferable to define special case mechanisms whereby each Designated 306 RBridge advertises attached stations, and receives explicit 307 acknowledgments from other RBridges. 309 4. Potential Issues 311 4.1. Interactions with Spanning Tree Forwarding and Bridge Learning 313 Spanning tree forwarding applies within parts of the RBridge domain, 314 where two or more RBridges are connected by a link that includes 315 multiple 802.1 bridges. 317 In order to simplify the interactions between RBridges and bridges - 318 in particular, relative to spanning tree forwarding - RBridges block 319 BPDUs in spanning tree protocol with attached 802.1 bridges. 321 Hence, from the Link State Routing protocol perspective, the protocol 322 will be able to treat spanning tree links as indistinguishable from 323 any other Ethernet/802.1 link, in the same way that routing protocols 324 do today. 326 However, support for multi-pathing is potentially problematic and is 327 assumed - in this document - to be a non-goal. Multi-path forwarding 328 has the potential to confound the bridge learning process. 330 4.2. Computing Routes 332 RBridges must calculate an L2 "route table" consisting of Next Hop 333 information for each known L2 unicast destination address within a 334 (possibly VLAN scoped) broadcast domain. This is computed using a 335 routing protocol's SPF algorithm and based on destination layer 2 336 address reachability advertisements. 338 4.3. RBridge Interactions with Routing 340 The fact that RBridges participate in flooding, and will have other 341 significant differences in forwarding behavior, provides additional 342 reasons to maintain separate routing instances if an RBridge and 343 Router are co-located. Otherwise, interactions between routers and 344 RBridges should be identical to interactions between routers and 345 bridges. 347 One of the potential interactions to consider in evaluating specific 348 routing protocols is how a specific routing protocol advertises on a 349 shared media. For instance, if a "pseudo-node" is used as a target 350 for such advertisements, how does this interact with the advertising 351 requirements for RBridges? 353 We expect this to be routing and RBridge protocol specific, and a 354 subject for further study. 356 5. Security Considerations 358 The goal is not to add additional security issues over what would be 359 present with traditional bridges and routers. RBridge Interactions 360 with Routers must be defined such that there is no "leaking" of info 361 used in authentication and/or encryption between router and r-bridge 362 instances. 364 As with routing schemes, authentication of RBridge messages would be 365 a simple addition to protocol (and it could be accomplished the same 366 way as it would be in existing routing protocol). However, any sort 367 of authentication requires additional configuration, which might 368 interfere with the requirement that RBridges need no configuration. 370 The essential requirement that RBridges do not require configuration 371 provides a forceful argument that most RBridge components are likely 372 to be physically separate (verses logically separate instances within 373 a single physical device) from routers. However, implementers may 374 choose to provide devices with both Routing and RBridge instancing 375 capabilities. 377 Implementers should consider the differences in trust models implied 378 in Routing and Bridging domains and apply appropriate trust boundary 379 safeguards in addition to instance isolation in general. 381 6. Conclusions 383 Routing protocols must be evaluated using the criteria in sections 384 2 and 3 above, with a clear objective of satisfying the TRILL goals 385 outlined in section 1.2. In addition, specific protocol solutions 386 should use discussion in section 4 above in making a determination 387 as to what approaches TRILL should use, for that (or those) routing 388 protocols that is determined to be useful for RBridge implementation. 390 Because of the requirement to be able to extend the routing protocol 391 to carry new information, and potentially support new types of peer 392 negotiation, the selected routing protocol must include mechanisms 393 to allow simple routing protocol extensions, new message formats and 394 potentially new types of message exchanges. 396 For reasons stated in above sections, we believe it is clear that the 397 IS-IS routing protocol may easily be adapted to satisfy TRILL routing 398 protocol requirements. 400 7. IANA Considerations 402 There is no action required of IANA by this document. 404 8. Acknowledgments 406 Thanks and appreciation are due Radia Perlman and Erik Nordmark for 407 their efforts in reviewing this document. Also appreciated are the 408 review efforts of Joel Halpern and Russ White. 410 9. References 412 9.1. Normative References 414 [TARCH] "TRILL RBridge Architecture", Gray, E. Editor - Work in 415 Progress. 417 9.2. Informative References 419 None. 421 10. Author's Addresses 423 Eric Gray 424 Ericsson 425 900 Chelmsford Street, 426 Lowell, MA - 01851 427 Email: Eric.Gray@Ericsson.com 429 11. Intellectual Property Statement 431 The IETF takes no position regarding the validity or scope of any 432 Intellectual Property Rights or other rights that might be claimed to 433 pertain to the implementation or use of the technology described in 434 this document or the extent to which any license under such rights 435 might or might not be available; nor does it represent that it has 436 made any independent effort to identify any such rights. Information 437 on the procedures with respect to rights in RFC documents can be 438 found in BCP 78 and BCP 79. 440 Copies of IPR disclosures made to the IETF Secretariat and any 441 assurances of licenses to be made available, or the result of an 442 attempt made to obtain a general license or permission for the use of 443 such proprietary rights by implementers or users of this 444 specification can be obtained from the IETF on-line IPR repository at 445 http://www.ietf.org/ipr. 447 The IETF invites any interested party to bring to its attention any 448 copyrights, patents or patent applications, or other proprietary 449 rights that may cover technology that may be required to implement 450 this standard. Please address the information to the IETF at 451 ietf-ipr@ietf.org. 453 12. Disclaimer of Validity 455 This document and the information contained herein are provided on an 456 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 457 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 458 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 459 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 460 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 461 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 463 13. Copyright Statement 465 Copyright (C) The IETF Trust (2007). 467 This document is subject to the rights, licenses and restrictions 468 contained in BCP 78, and except as set forth therein, the authors 469 retain all their rights. 471 14. Acknowledgment 473 Funding for the RFC Editor function is currently provided by the 474 Internet Society.