idnits 2.17.1 draft-ietf-trill-o-pw-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 (September 4, 2013) is 3887 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: March 3, 2014 September 4, 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 52 4. Security Considerations.................................6 54 Acknowledgements...........................................7 55 Normative References.......................................7 56 Informative References.....................................7 57 Authors' Addresses.........................................9 59 1. Introduction 61 The IETF has standardized the TRILL (Transparent Interconnection of 62 Lots of Links) protocol [RFC6325] that provides optimal pair-wise 63 data frame routing without configuration in multi-hop networks with 64 arbitrary topology. TRILL supports multipathing of both unicast and 65 multicast traffic. Devices that implement TRILL are called TRILL 66 Switches or RBridges (Routing Bridges). 68 Links between TRILL Switches can be based on arbitrary link 69 protocols, for example PPP [RFC6361], as well as Ethernet [RFC6325]. 70 A set of connected TRILL Switches together form a TRILL campus which 71 is bounded by end stations and layer 3 routers. 73 This document specifies how to interconnect a pair of TRILL Switch 74 ports using a pseudowire under existing TRILL and PWE3 (pseudowire 75 Emulation End-to-End) standards. 77 1.1 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 Acronyms used in this document include the following: 85 IS-IS - Intermediate System to Intermediate System [IS-IS] 87 MPLS - Multi-Protocol Label Switching 89 PPP - Point-to-Point Protocol [RFC1661] 91 PW - Pseudowire [RFC3985] 93 PWE3 - PW Emulation End-to-End 95 RBridge - Routing Bridge, an alternative name for a TRILL Switch 97 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 99 TRILL Switch - A device implementing the TRILL protocol 101 2. PWE3 Interconnection of TRILL Switches 103 When a pseudowire is used to interconnect a pair of TRILL Switch 104 ports, a PPP [RFC4618] pseudowire is used as described below. The 105 pseudowire between such ports can be auto-configured [RFC4447] or 106 manually configured. In this context, the TRILL Switch ports at the 107 ends of the pseudowire are acting as native service processing 108 elements (NSP [RFC3985]) and, assuming the pseudowires are over MPLS 109 or IP [RFC4023], as label switched routers. 111 (Although Ethernet pseudowires would be possible, they would require 112 an additional 12 or 16 bytes per frame. It would also be possible to 113 specify a special custom pseudowire type for TRILL traffic but the 114 authors feel that any efficiency gain over PPP pseudowires would be 115 too small to be worth the complexity of adding such a specification.) 117 Pseudowires provide transparent transport and the two TRILL Switch 118 ports appear directly interconnected with a transparent link. With 119 such an interconnection the TRILL adjacency over the link is 120 automatically discovered and established through TRILL IS-IS control 121 messages [RFC6327bis]. 123 A pseudowire is carried over a packet switched network tunnel 124 [RFC3985]. For example, an MPLS or MPLS-TP label switched path 125 tunnel in MPLS networks. Either a signaling protocol or manual 126 configuration can be used to configure a label switched path tunnel 127 between two TRILL Switch ports. This application needs no additions 128 to the existing pseudowire standards. 130 2.1 PWE3 Type Independent Details 132 The sending pseudowire TRILL Switch port MUST copy the priority of 133 the TRILL Data packets being sent to the 3-bit Class of Service field 134 of the pseudowire label [RFC5462] so the priority will be visible to 135 pseudowire transit devices and they can take the priority into 136 account. 138 If a pseudowire supports fragmentation and re-assembly, there is no 139 reason to do TRILL MTU testing on it and the pseudowire will not be a 140 constraint on the TRILL campus wide Sz (see Section 4.3.1 [RFC6325]). 141 If the pseudowire does not support fragmentation, then the available 142 TRILL IS-IS packet payload size over the pseudowire (taking into 143 account MPLS encapsulation with a control word) or some lower value, 144 MUST be used in helping to determine Sz (see Section 5 145 [ClearCorrect]). 147 An intervening MPLS label switched router or similar packet switched 148 network device has no awareness of TRILL. Such devices will not 149 change the TRILL Header hop count. 151 2.2 TRILL over PPP PWE3 153 For a PPP pseudowire (PW type = 0x0007), the two TRILL Switch ports 154 being connected are configured to form a pseudowire with PPP 155 encapsulation [RFC4618]. After the pseudowire is established and 156 TRILL use is negotiated within PPP, the two TRILL Switch ports appear 157 directly connected with a PPP link [RFC1661] [RFC6361]. 159 If pseudowire interconnection of two TRILL Switch ports is auto- 160 configured [RFC4447], the initiating TRILL Switch port MUST attempt 161 the connection set-up with pseudowire type PPP (0x0007). 163 Behavior for TRILL with a PPP pseudowire continues to follow that of 164 TRILL over PPP as specified in Section 3 of [RFC6361]. 166 3. IANA Considerations 168 No IANA actions are required by this document. RFC Editor: Please 169 remove this section before publication. 171 4. Security Considerations 173 For PPP link TRILL security considerations, see [RFC6361]. 175 For security considerations introduced by carrying PPP TRILL links 176 over pseudowires, see [RFC3985]. 178 Not all implementations need to include specific security mechanisms 179 at the pseudowire layer, for example if they are designed to be 180 deployed only in cases where the networking environment is trusted or 181 where other layers provide adequate security. A complete enumeration 182 of possible deployment scenarios and associated threats and options 183 is not possible and is outside the scope of this document. For 184 applications involving sensitive data, end-to-end security should 185 always be considered, in addition to link security, to provide 186 security in depth. In this context, such end-to-end security should 187 be between the end stations involved so as to protect the entire path 188 to, through, and from the TRILL campus. 190 For general TRILL protocol security considerations, see [RFC6325]. 192 Acknowledgements 194 The document was prepared in raw nroff. All macros used were defined 195 within the source file. 197 Normative References 199 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 200 STD 51, RFC 1661, July 1994. 202 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC4447] - Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 206 G. Heron, "Pseudowire Setup and Maintenance Using the Label 207 Distribution Protocol (LDP)", RFC 4447, April 2006. 209 [RFC4618] - Martini, L., "Encapsulation Methods for Transport of 210 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", 211 BCP 116, RFC 4618, September 2006. 213 [RFC5462] - Andersson, L. and R. Asati, "Multiprotocol Label 214 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 215 "Traffic Class" Field", RFC 5462, February 2009. 217 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 218 Ghanwani, "Routing Bridges (RBridges): Base Protocol 219 Specification", RFC6325, July 2011. 221 [RFC6361] - Carlson, J., and D. Eastlake, "PPP Transparent 222 Interconnection of Lots of Links (TRILL) Protocol Control 223 Protocol", RFC6361, August 2011. 225 [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, and 226 A. Banerjee, "TRILL: Clarifications, Corrections, and Updates", 227 draft-ietf-trill-clear-correct, in RFC Editor's queue. 229 Informative References 231 [IS-IS] - International Organization for Standardization, 232 "Intermediate system to Intermediate system intra-domain 233 routing information exchange protocol for use in conjunction 234 with the protocol for providing the connectionless-mode Network 235 Service (ISO 8473)", ISO/IEC10589:2002, Second Edition, Nov 236 2002 238 [RFC3985] - Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 239 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 241 [RFC4023] - Worster, T., Rekhter, Y., and E. Rosen, Ed., 242 "Encapsulating MPLS in IP or Generic Routing Encapsulation 243 (GRE)", RFC 4023, March 2005. 245 [RFC6327bis] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Howard, 246 Y., and V. Manral, "TRILL: Adjacency", draft-ietf-trill- 247 rfc6327bis, work in progress. 249 Authors' Addresses 251 Lucy Yong 252 Huawei Technologies 253 5340 Legacy Drive 254 Plano, TX 75025 USA 256 Phone: +1-469-227-5837 257 Email: lucy.yong@huawei.com 259 Donald E. Eastlake, 3rd 260 Huawei Technologies 261 155 Beaver Street 262 Milford, MA 01757 USA 264 Phone: +1-508-333-2270 265 Email: d3e3e3@gmail.com 267 Sam Aldrin 268 Huawei Technologies 269 2330 Central Expressway 270 Santa Clara, CA 95050 USA 272 Phone: +1-408-330-4517 273 Email: sam.aldrin@huawei.com 275 Jon Hudson 276 Brocade 277 130 Holger Way 278 San Jose, CA 95134 USA 280 Phone: +1-408-333-4062 281 jon.hudson@gmail.com 283 Copyright and IPR Provisions 285 Copyright (c) 2013 IETF Trust and the persons identified as the 286 document authors. All rights reserved. 288 This document is subject to BCP 78 and the IETF Trust's Legal 289 Provisions Relating to IETF Documents 290 (http://trustee.ietf.org/license-info) in effect on the date of 291 publication of this document. Please review these documents 292 carefully, as they describe your rights and restrictions with respect 293 to this document. Code Components extracted from this document must 294 include Simplified BSD License text as described in Section 4.e of 295 the Trust Legal Provisions and are provided without warranty as 296 described in the Simplified BSD License. The definitive version of 297 an IETF Document is that published by, or under the auspices of, the 298 IETF. Versions of IETF Documents that are published by third parties, 299 including those that are translated into other languages, should not 300 be considered to be definitive versions of IETF Documents. The 301 definitive version of these Legal Provisions is that published by, or 302 under the auspices of, the IETF. Versions of these Legal Provisions 303 that are published by third parties, including those that are 304 translated into other languages, should not be considered to be 305 definitive versions of these Legal Provisions. For the avoidance of 306 doubt, each Contributor to the IETF Standards Process licenses each 307 Contribution that he or she makes as part of the IETF Standards 308 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 309 language to the contrary, or terms, conditions or rights that differ 310 from or are inconsistent with the rights and licenses granted under 311 RFC 5378, shall have any effect and shall be null and void, whether 312 published or posted by such Contributor, or included with or in such 313 Contribution.