idnits 2.17.1 draft-zhang-trill-active-active-cp-req-00.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 (October 21, 2013) is 3839 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) == Missing Reference: 'RFC6349' is mentioned on line 83, but not defined == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Missing Reference: 'RFC3376' is mentioned on line 162, but not defined ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) == Outdated reference: A later version (-04) exists of draft-ietf-trill-rfc6327bis-01 ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) == Outdated reference: A later version (-09) exists of draft-ietf-trill-esadi-03 == Outdated reference: A later version (-03) exists of draft-ietf-isis-rfc6326bis-01 == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Huawei 4 Expires: April 24, 2014 Russ White 5 Verisign 6 Hongjun Zhai 7 ZTE 8 October 21, 2013 10 Control Plane Requirements for TRILL Active/Active Edge 11 draft-zhang-trill-active-active-cp-req-00.txt 13 Abstract 15 TRILL Active/Active Edge enables a Multi-Chassis Link Aggregation 16 Group to connect to multiple RBridges which can ingress and egress 17 data traffic for the same VLAN at the same time. The purpose of 18 introducing the TRILL Active/Active Edge is to increase the access 19 bandwidth and resilience. This new access type puts forward new 20 requirements for TRILL control plane. Current TRILL control plane 21 need be extended in order to make the TRILL Active/Active Edge 22 operational. Requirements are developed in this document as the 23 guidelines for designing those specific control plane functions. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 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 33 Internet-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 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 65 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Control Plane Requirements . . . . . . . . . . . . . . . . . . 3 68 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Election . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.3. Forwarding Information Synchronization . . . . . . . . . . 4 71 3.4. Failure Detection and Notification . . . . . . . . . . . . 5 72 3.5. Communicating Configuration Information . . . . . . . . . . 5 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 78 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 TRILL makes use of IS-IS link state routing to provide least-cost 83 forwarding between TRILL switches. At the edge, [RFC6349] already 84 defines an active-standby access for end-stations. An active-active 85 method is to be added in TRILL so that end stations are able to 86 increase the bandwidth and resilience of their access to a TRILL 87 campus using Multi-Chassis Link Aggregation Group (MC-LAG) [PS]. 88 Unlike a LAN link, MC-LAG does not exchange TRILL IS-IS PDUs. The 89 TRILL switch ports attached to the MC-LAG demarcate the edge of TRILL 90 and no adjacency can be formed on top of the MC-LAG. 92 From the point of view of the end stations, the MC-LAG is treated as 93 if it were a single link and those RBridges connected to the other 94 end of the MC-LAG need operate as if they were a single TRILL switch. 95 Thus an Active/Active Edge (AAE) is set up. However, it doesn't mean 96 that RBridges in the AAE can be connected to only one MC-LAG. It's 97 possible that one port of an RBridge is connected to one MC-LAG and 98 the other port is connected to another. 100 To achieve the TRILL Active/Active Edge, some functions should be 101 added to the current TRILL control plane. There are several possible 102 places to host these functions. For example, the TRILL IS-IS, TRILL 103 BFD, ESADI protocol and TRILL Channel are potential choices [BFD] 104 [ESADI] [Channel]. This document describes the high-level 105 requirements for these new control plane functions. When specific 106 protocols are designed, these requirements should be followed. 108 2. Acronyms and Terminology 110 2.1. Acronyms 112 MC-LAG: Multi-Chassis Link Aggregation Group 113 IS-IS: Intermediate System to Intermediate System 114 TRILL: TRansparent Interconnection of Lots of Links 115 AAE: Active/Active Edge 117 2.2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 Familiarity with [RFC6325], [RFC6327], [6327bis] and [RFC6439] is 124 assumed in this document. 126 3. Control Plane Requirements 127 This section specifies the requirements on the functions that the 128 TRILL control plane need to provide for the AAE. 130 3.1. Discovery 132 When an RBridge is attached to an MC-LAG, it need to recognize other 133 RBridges attached to this MC-LAG as in the same AAE. It also need to 134 notify other RBridges the fact that it joins or leaves the AAE. 136 The identification of the AAE is REQUIRED during the discovery. The 137 System Identifier of the MC-LAG is a choice. RBridges in an AAE MUST 138 include this ID in the Protocol Data Units of the control plane 139 protocol to achieve the discovery. 141 3.2. Election 143 RBridges per [RFC6325] run a protocol on the link to elect the 144 Designated RBridge (DRB). The DRB performs some common tasks for the 145 link. For example, the DRB gives the link a pseudonode nickname. 147 RBridges in an AAE need elect a master node to carry on common tasks 148 for the AAE as well. Since MC-LAG disables the delivery of TRILL IS- 149 IS PDUs. The TRILL IS-IS election protocol defined in Section 2.1 of 150 [RFC6325] is not applicable here. 152 A substitute election protocol SHOULD be set up. Such protocol should 153 reuse the decision process algorithm defined in [ISIS] to avoid 154 introducing too much complexity into TRILL. 156 3.3. Forwarding Information Synchronization 158 As an example, AAE members may learn MAC addresses through data plane 159 learning and ESADI protocol. MAC addresses learnt by one member 160 should be shared to other members in the same AAE in order to reduce 161 the unknown unicast traffic [PS]. As another example, the IGMP 162 (Internet Group Management Protocol) [RFC3376] snooping on those 163 ports attached to a MC-LAG has to be synchronized. A protocol is 164 needed to synchronize these forwarding information among AAE members 165 and keep the information updated in a timely manner. 167 MAC address may be frequently updated due to data plane learning. It 168 is REQUIRED that the CPU is not overloaded due to the control plane 169 MAC address update. Therefore the protocol should define a minimum 170 updating interval. 172 Due to the overhead that may be produced, this protocol SHOULD be 173 confined in the scope of the AAE members. Obviously, it SHOULD NOT be 174 realized though the extension of TRILL IS-IS, which may otherwise 175 introduce a heavy burden to current TRILL's control plane. TRILL 176 ESADI or TRILL Channel are proper candidates to realize such 177 protocol. 179 3.4. Failure Detection and Notification 181 When a link of the MC-LAG to an AAE member RBridge or this RBridge 182 itself is failed, this failure should be detected and notified to 183 other AAE member RBridges through the control plane as soon as 184 possible. RBridges other than AAE member RBridges may need be 185 notified as well so that these RBridges can change their forwarding 186 paths to avoid the failure. 188 The failed AAE member RBridge leaves the AAE. It's possible that 189 there is less than two RBridges in the AAE due to the failure. Then 190 the AAE should be destroyed. If the AAE is not destroyed, the failure 191 notification will trigger a re-convergence of the AAE. It is optional 192 to establish a dedicated session such as BFD to detect the failure in 193 order to enable a fast convergence. All AAE members MUST run into a 194 consensus converge state just like the convergence in IGP routing 195 protocols. The control plane protocols need take the design of the 196 re-convergence algorithm into consideration. 198 3.5. Communicating Configuration Information 200 Configuration on RBridges to enable the operation of an AAE should be 201 minimized. Some of the configuration is local while the other is of 202 global sense and need be conveyed through the control plane to other 203 RBridges. An example is the Affinity Sub-TLV defined in [6326bis] and 204 used in [CMT]. 206 The communication of the configuration information through the 207 control plane helps to settle mis-configuration. For example, enabled 208 VLANs of every port attached to the same MC-LAG MUST be the same. An 209 RBridge in an AAE can report the enabled VLANs to others through the 210 control plane so that a mis-configured VLAN can be rectified or 211 trigger an alarm to the management plane. 213 4. Security Considerations 215 Security issue should be considered when a specific extension is made 216 to the existing TRILL control plane. 218 Authenticity for contents transported in IS-IS PDUs is enforced using 219 regular IS-IS security mechanism [ISIS][RFC5310]. 221 For security considerations pertain to extensions hosted by TRILL BFD 222 and ESADI, corresponding documents should refer to the Security 223 Considerations in [BFD], [ESADI] and [Channel]. 225 5. IANA Considerations 227 This document requires no IANA actions. RFC Editor: please remove 228 this section before publication. 230 6. References 232 6.1. Normative References 234 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 235 Ghanwani, "Routing Bridges (RBridges): Base Protocol 236 Specification", RFC 6325, July 2011. 238 [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and 239 V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 240 6327, July 2011. 242 [6327bis] D. Eastlake, R. Perlman, et al, "TRILL: Adjacency", draft- 243 ietf-trill-rfc6327bis-01.txt, July 2013, working in 244 progress. 246 [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, 247 "Routing Bridges (RBridges): Appointed Forwarders", RFC 248 6439, November 2011. 250 [BFD] V. Manral, D. Eastlake, et al, "TRILL (Transparent 251 Interconnetion of Lots of Links): Bidirectional Forwarding 252 Detection (BFD) Support", draft-ietf-trill-rbridge-bfd- 253 07.txt, July 2012, working in progress. 255 [ESADI] H. Zhai, F. Hu, et al, "TRILL (Transparent Interconnection 256 of Lots of Links): ESADI (End Station Address Distribution 257 Information) Protocol", draft-ietf-trill-esadi-03.txt, July 258 2013, working in progress. 260 [6326bis] D. Eastlake, T. Senevirathne, et al, "Transparent 261 Interconnection of Lots of Links (TRILL) Use of IS-IS", 262 draft-ietf-isis-rfc6326bis-01.txt, April 2013, working in 263 progress. 265 [Channel] D. Eastlake, V Manral, et al, "TRILL: RBridge Channel 266 Support", draft-ietf-trill-rbridge-channel-08.txt, July 267 2012, working in progress. 269 6.2. Informative References 271 [PS] M. Zhang and D. Eastlake, "Problem Statement: TRILL 272 Active/Active Edge", draft-zhang-trill-aggregation-04.txt, 273 August 2013, working in progress. 275 [ISIS] ISO, "Intermediate system to Intermediate system routeing 276 information exchange protocol for use in conjunction with 277 the Protocol for providing the Connectionless-mode Network 278 Service (ISO 8473)", ISO/IEC 10589:2002. 280 [CMT] T. Senevirathne, J. Pathangi, et al, "Coordinated Multicast 281 Trees (CMT)for TRILL", draft-ietf-trill-cmt-02.txt, 282 November 2012, working in progress. 284 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 285 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 286 RFC 5310, February 2009. 288 Author's Addresses 290 Mingui Zhang 291 Huawei Technologies 292 No.156 Beiqing Rd. Haidian District, 293 Beijing 100095 P.R. China 295 Email: zhangmingui@huawei.com 297 Russ White 298 Verisign 299 12061 Bluemont Way 300 Reston, VA 20190 301 USA 303 Email: riwhite@verisign.com 305 Hongjun Zhai 306 ZTE 307 68 Zijinghua Road, Yuhuatai District 308 Nanjing, Jiangsu 210012 309 China 311 Phone: +86 25 52877345 312 Email: zhai.hongjun@zte.com.cn