idnits 2.17.1 draft-yong-trill-o-pw-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 : ---------------------------------------------------------------------------- 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 (August 15, 2013) is 3905 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Lucy Yong 2 INTERNET-DRAFT Donald Eastlake 3 Intended status: Proposed Standard Sam Aldrin 4 Huawei Technologies 5 Jon Hudson 6 Brocade 7 Expires:February 14, 2014 August 15, 2013 9 TRILL Over Pseudowires 10 12 Abstract 14 This document specifies how to interconnect a pair of TRILL 15 (Transparent Interconnection of Lots of Links) switch ports using 16 pseudowires under existing TRILL and PWE3 (Pseudowire Emulation End- 17 to-End) standards. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the authors. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 39 Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Conventions used in this document......................3 47 2. PWE3 Interconnection of TRILL Switches..................4 48 2.1 PWE3 Type Independent Details..........................4 49 2.2 TRILL over PPP PWE3....................................5 51 3. IANA Considerations.....................................6 53 4. Security Considerations.................................6 55 Acknowledgements...........................................7 56 Normative References.......................................7 57 Informative References.....................................7 58 Authors' Addresses.........................................9 60 1. Introduction 62 The IETF has standardized the TRILL (Transparent Interconnection of 63 Lots of Links) protocol [RFC6325] that provides optimal pair-wise 64 data frame routing without configuration in multi-hop networks with 65 arbitrary topology. TRILL supports multipathing of both unicast and 66 multicast traffic. Devices that implement TRILL are called TRILL 67 Switches or RBridges (Routing Bridges). 69 Links between TRILL Switches can be based on arbitrary link 70 protocols, for example PPP [RFC6361], as well as Ethernet [RFC6325]. 71 A set of connected TRILL Switches together form a TRILL campus which 72 is bounded by end stations and layer 3 routers. 74 This document specifies how to interconnect a pair of TRILL Switch 75 ports using a pseudowire under existing TRILL and PWE3 (pseudowire 76 Emulation End-to-End) standards. 78 1.1 Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 Acronyms used in this document include the following: 86 IS-IS - Intermediate System to Intermediate System [IS-IS] 88 MPLS - Multi-Protocol Label Switching 90 PPP - Point-to-Point Protocol [RFC1661] 92 PW - Pseudowire [RFC3985] 94 PWE3 - PW Emulation End-to-End 96 RBridge - Routing Bridge, an alternative name for a TRILL Switch 98 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 100 TRILL Switch - A device implementing the TRILL protocol 102 2. PWE3 Interconnection of TRILL Switches 104 When a pseudowire is used to interconnect a pair of TRILL Switch 105 ports, a PPP [RFC4618] pseudowire is used as described below. The 106 pseudowire between such ports can be auto-configured [RFC4447] or 107 manually configured. In this context, the TRILL Switch ports at the 108 ends of the pseudowire are acting as native service processing 109 elements (NSP [RFC3985]) and, assuming the pseudowires are over MPLS 110 or IP [RFC4023], as label switched routers. 112 (Although Ethernet pseudowires would be possible, they would require 113 an additional 12 or 16 bytes per frame. It would also be possible to 114 specify a special custom pseudowire type for TRILL traffic but the 115 authors feel that any efficiency gain over PPP pseudowires would be 116 too small to be worth the complexity of adding such a specification.) 118 Pseudowires provide transparent transport and the two TRILL Switch 119 ports appear directly interconnected with a transparent link. With 120 such an interconnection the TRILL adjacency over the link is 121 automatically discovered and established through TRILL IS-IS [IS-IS] 122 control messages [RFC6325] [RFC6327bis]. 124 A pseudowire is carried over a packet switched network tunnel 125 [RFC3985]. For example, an MPLS or MPLS-TP label switched path 126 tunnel in MPLS networks. Either a signaling protocol or manual 127 configuration can be used to configure a label switched path tunnel 128 between two TRILL Switch ports. No addition to the existing 129 pseudowire standards is needed for this application. 131 2.1 PWE3 Type Independent Details 133 The sending pseudowire TRILL Switch port MUST copy the priority of 134 the TRILL Data packets being sent to the 3-bit Class of Service field 135 of the pseudowire label [RFC5462] so the priority will be visible to 136 pseudowire transit devices and they can take the priority into 137 account. 139 If a pseudowire supports fragmentation and re-assembly, there is no 140 reason to do TRILL MTU testing on it and the pseudowire will not be a 141 constraint on the TRILL campus wide Sz (see Section 4.3.1 [RFC6325]). 142 If the pseudowire does not support fragmentation, then the available 143 TRILL IS-IS packet payload size over the pseudowire (taking into 144 account MPLS encapsulation with a control word) or some lower value, 145 MUST be used in helping to determine Sz (see Section 5 146 [ClearCorrect]). 148 An intervening MPLS label switched router or similar packet switched 149 network device has no awareness of TRILL. Such devices will not 150 change the TRILL Header hop count. 152 2.2 TRILL over PPP PWE3 154 For a PPP pseudowire (PW type = 0x0007), the two TRILL Switch ports 155 being connected are configured to form a pseudowire with PPP 156 encapsulation [RFC4618]. After the pseudowire is established and 157 TRILL use is negotiated within PPP, the two TRILL Switch ports appear 158 directly connected with a PPP link [RFC1661] [RFC6361]. 160 If pseudowire interconnection of two TRILL Switch ports is auto- 161 configured [RFC4447], the initiating TRILL Switch port MUST attempt 162 the connection set-up with pseudowire type PPP (0x0007). 164 Behavior for TRILL with a PPP pseudowire continues to follow that of 165 TRILL over PPP as specified in Section 3 of [RFC6361]. 167 3. IANA Considerations 169 No IANA actions are required by this document. RFC Editor: Please 170 remove this section before publication. 172 4. Security Considerations 174 For PPP link TRILL security considerations, see [RFC6361]. 176 For security considerations introduced by carrying PPP TRILL links 177 over pseudowires, see [RFC3985]. 179 Not all implementations need to include specific security mechanisms 180 at the pseudowire layer, for example if they are designed to be 181 deployed only in cases where the networking environment is trusted or 182 where other layers provide adequate security. A complete enumeration 183 of possible deployment scenarios and associated threats and options 184 is not possible and is outside the scope of this document. For 185 applications involving sensitive data, end-to-end security should 186 always be considered, in addition to link security, to provide 187 security in depth. In this context, such end-to-end security should 188 be between the end stations involved so as to protect the entire path 189 to, through, and out of the TRILL campus. 191 For general TRILL protocol security considerations, see [RFC6325]. 193 Acknowledgements 195 The document was prepared in raw nroff. All macros used were defined 196 within the source file. 198 Normative References 200 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 201 STD 51, RFC 1661, July 1994. 203 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC4447] - Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 207 G. Heron, "Pseudowire Setup and Maintenance Using the Label 208 Distribution Protocol (LDP)", RFC 4447, April 2006. 210 [RFC4618] - Martini, L., "Encapsulation Methods for Transport of 211 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", 212 BCP 116, RFC 4618, September 2006. 214 [RFC5462] - Andersson, L. and R. Asati, "Multiprotocol Label 215 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 216 "Traffic Class" Field", RFC 5462, February 2009. 218 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 219 Ghanwani, "Routing Bridges (RBridges): Base Protocol 220 Specification", RFC6325, July 2011. 222 [RFC6361] - Carlson, J., and D. Eastlake, "PPP Transparent 223 Interconnection of Lots of Links (TRILL) Protocol Control 224 Protocol", RFC6361, August 2011. 226 [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, and 227 A. Banerjee, "TRILL: Clarifications, Corrections, and Updates", 228 draft-ietf-trill-clear-correct, in RFC Editor's queue. 230 Informative References 232 [IS-IS] - International Organization for Standardization, 233 "Intermediate system to Intermediate system intra-domain 234 routing information exchange protocol for use in conjunction 235 with the protocol for providing the connectionless-mode Network 236 Service (ISO 8473)", ISO/IEC10589:2002, Second Edition, Nov 237 2002 239 [RFC3985] - Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 240 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 242 [RFC4023] - Worster, T., Rekhter, Y., and E. Rosen, Ed., 243 "Encapsulating MPLS in IP or Generic Routing Encapsulation 244 (GRE)", RFC 4023, March 2005. 246 [RFC6327bis] - Eastlake 3rd, D., Perlman, R., Ghanwani, A.,Howard, 247 Y., and V. Manral, "TRILL: Adjacency", draft-ietf-trill- 248 rfc6327bis, work in progress. 250 Authors' Addresses 252 Lucy Yong 253 Huawei Technologies 254 5340 Legacy Drive 255 Plano, TX 75025 USA 257 Phone: +1-469-227-5837 258 Email: lucy.yong@huawei.com 260 Donald E. Eastlake, 3rd 261 Huawei Technologies 262 155 Beaver Street 263 Milford, MA 01757 USA 265 Phone: +1-508-333-2270 266 Email: d3e3e3@gmail.com 268 Sam Aldrin 269 Huawei Technologies 270 2330 Central Expressway 271 Santa Clara, CA 95050 USA 273 Phone: +1-408-330-4517 274 Email: sam.aldrin@huawei.com 276 Jon Hudson 277 Brocade 278 130 Holger Way 279 San Jose, CA 95134 USA 281 Phone: +1-408-333-4062 282 jon.hudson@gmail.com 284 Copyright and IPR Provisions 286 Copyright (c) 2013 IETF Trust and the persons identified as the 287 document authors. All rights reserved. 289 This document is subject to BCP 78 and the IETF Trust's Legal 290 Provisions Relating to IETF Documents 291 (http://trustee.ietf.org/license-info) in effect on the date of 292 publication of this document. Please review these documents 293 carefully, as they describe your rights and restrictions with respect 294 to this document. Code Components extracted from this document must 295 include Simplified BSD License text as described in Section 4.e of 296 the Trust Legal Provisions and are provided without warranty as 297 described in the Simplified BSD License. The definitive version of 298 an IETF Document is that published by, or under the auspices of, the 299 IETF. Versions of IETF Documents that are published by third parties, 300 including those that are translated into other languages, should not 301 be considered to be definitive versions of IETF Documents. The 302 definitive version of these Legal Provisions is that published by, or 303 under the auspices of, the IETF. Versions of these Legal Provisions 304 that are published by third parties, including those that are 305 translated into other languages, should not be considered to be 306 definitive versions of these Legal Provisions. For the avoidance of 307 doubt, each Contributor to the IETF Standards Process licenses each 308 Contribution that he or she makes as part of the IETF Standards 309 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 310 language to the contrary, or terms, conditions or rights that differ 311 from or are inconsistent with the rights and licenses granted under 312 RFC 5378, shall have any effect and shall be null and void, whether 313 published or posted by such Contributor, or included with or in such 314 Contribution.