idnits 2.17.1 draft-eastlake-trill-lldp-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 (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- 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.) -- The document date (September 12, 2012) is 4242 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 6327 (Obsoleted by RFC 7177) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Updates: 6325 Anoop Ghanwani 4 Intended status: Proposed Standard Dell 5 Expires: March 11, 2012 September 12, 2012 7 Transparent Interconnection of Lots of Links (TRILL) 8 Support of the Link Layer Discover Protocol (LLDP) 9 11 Abstract 13 RBridges are devices that implement the IETF TRILL (Transparent 14 Interconnection of Lots of Links, RFC 6325) protocol. The Link Layer 15 Discovery Protocol (LLDP, IEEE Std 802.1AB) is a one-way, 16 unacknowledged protocol for the announcement of a station's 17 capabilities to its peers. The set of peers that receive these 18 frames and the scoping of the frame is primarily determined by the 19 destination MAC address of the LLDP frame. This document specifies a 20 Nearest-RBridge MAC address and other details of TRILL support of 21 LLDP. It updates RFC 6325. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the authors. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Terminology and Acronyms...............................3 51 2. LLDP on RBridge Ports...................................4 52 2.1 Use on Ethernet Ports..................................4 53 2.2 Use on Other RBridge Ports.............................5 55 3. Nearest-RBridge as Inner.MacDA..........................6 56 3.1 Transmission...........................................6 57 3.2 Receipt................................................6 59 4. Change in RFC 6325......................................8 60 5. IANA Considerations.....................................8 61 6. Security Considerations.................................8 63 Normative References.......................................9 64 Informative References.....................................9 66 1. Introduction 68 The Link Layer Discovery Protocol (LLDP [802.1AB]) is a one-way, 69 unacknowledged protocol for the announcement of a station's 70 capabilities to its peers. The set of peers that receive these 71 frames and the scoping of the frame is primarily determined by the 72 destination address of the LLDP frame. This document specifies TRILL 73 (Transparent Interconnection of Lots of Links, [RFC6325] [RFC6327]) 74 support of LLDP. Such support is optional. This document updates 75 [RFC6325]. 77 Clause 7.1 of the IEEE [802.1AB] Standard provides that LLDP may be 78 used with any unicast or group (multi-destination) destination 79 address. This document specifies the Nearest-RBridge MAC destination 80 address. 82 1.1 Terminology and Acronyms 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 The following are used in this document: 90 IEEE - Institute for Electronic and Electrical Engineers 91 (www.ieee.org) 93 LLDP - Link Layer Discovery Protocol [802.1AB] 95 LLDPDU - LLDP Data Unit [802.1AB] 97 MAC - Media Access Control [802] 99 RBridge - Routing Bridge [RFC6325] 101 TPMR - Two Port MAC Relay [802.1Q] 103 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 105 2. LLDP on RBridge Ports 107 LLDP [802.1AB] is explicitly specified to be usable with "Any group 108 MAC address" and "Any individual MAC address" as the destination 109 address. That standard also documents specific destination MAC 110 addresses with different scope for propagation across various bridge 111 types specified by IEEE 802.1 such as: 113 o Nearest Customer Bridge: Propagation stops at the nearest Customer 114 Bridge; i.e. such frames would pass through Provider Bridges and 115 Two-port MAC Relays (TPMRs) [802.1Q]. (01-80-C2-00-00-00) 117 o Nearest Non-TPMR Bridge: Propagation stops at the nearest Customer 118 or Provider Bridge, but not at a TPMR. (01-80-C2-00-00-03) 120 o Nearest Bridge: Propagation stops at the nearest bridge of any 121 type, including a TPMR. (01-80-C2-00-00-02) 123 Note that the devices that stop the propagation of LLDP frames are 124 the only devices that process them; other devices forward them as if 125 they were regular data frames. 127 A new Nearest-RBridge multicast MAC address (see Section 4) is used 128 as a destination MAC address with LLDPUs to send them to neighbor 129 RBridges. There may in the future be other uses of the Nearest- 130 RBridge multicast MAC address; in such applications, the Ethertype of 131 those frames would be different than the LLDP EtherType (0x88CC). 133 2.1 Use on Ethernet Ports 135 LLDPDUs sent with the Nearest-RBridge multicast address out an 136 RBridge Ethernet port are not encapsulated with a TRILL Header and 137 are sent natively. Intervening bridges, if any, will be transparent 138 to frames using this multicast address. 140 LLDPDUs using the Nearest-RBridge MAC destination address may be 141 transmitted as permitted by [802.1AB] by an RBridge on any of its 142 Ethernet ports regardless of the state of any adjacencies [IS-IS] 143 [RFC6327] on that port. 145 LLDPDUs may also be sent by an RBridge on Ethernet ports with the 146 IEEE 802.1 provided destination MAC addresses listed above or other 147 appropriate destination MAC addresses if other scopes are desired. 149 2.2 Use on Other RBridge Ports 151 If an RBridge port is a port on which an LLDPDU cannot be transmitted 152 in native form, for example, a PPP TRILL port [RFC6361], the Nearest- 153 RBridge destination MAC multicast address is still used but the 154 LLDPDU appears inside a TRILL Data frame as specified in Section 3. 155 The payload EtherType is the LLDP EtherType (0x88CC) with the 156 subsequent portion of the frame following normal LLDP rules. This 157 technique can be used to send an LLDPDU out any non-Ethernet RBridge 158 port to RBridges that are one hop away. 160 To assure than any required link initialization has occurred, TRILL 161 Data frames containing LLDPDUs MUST NOT be transmitted out an RBridge 162 port unless there is at least one adjacency [IS-IS] [RFC6327] on that 163 port in a state other than Down. The rate of transmission of such 164 frames is governed by the same rules as native LLDPDUs [802.1AB]. 166 An LLDPDU received in a TRILL Data frame must pass the tests in 167 Section 3.2 before being passed on to LLDP to be acted on. 169 3. Nearest-RBridge as Inner.MacDA 171 The Nearest-RBridge multicast MAC address is not intended to be 172 forwarded by an Rbridge, and as a result the scope of a frame with 173 this address as the MAC destination address would be all immediately 174 adjacent RBridge neighbors on a link. The following sub-sections 175 specify TRILL Data frame transmission and receipt where the 176 Inner.MacDA is Nearest-RBridge. 178 3.1 Transmission 180 When the Inner.MacDA of a TRILL Data frame is the Nearest-RBridge 181 multicast MAC, then the following apply. Different uses of this MAC 182 address are distinguished by the payload EtherType, for example 183 0x88CC for LLDP. 185 1. The originating RBridge MUST set the Inner.MacSA to a MAC address 186 unique within the campus owned by that originating RBridge. This 187 MAY be the same Inner.MacSA used for ESADI [ESADIdraft] and/or 188 RBridge Channel [Channel] frames. 190 2. The Inner.VLAN defaults to 0x001 and is ignored on receipt unless 191 otherwise specified. 193 3. TRILL Header fields MUST be set as follows: 195 3.a the hop count is initialized to the maximum value (0x3F), 197 3.b the M bit is set to zero, 199 3.c the ingress nickname is a nickname owned by the originating 200 RBridge, 202 3.d the egress nickname is set to Any-RBridge. RBridges supporting 203 the Nearest-RBridge MAC address MUST recognize the Any-RBridge 204 egress nickname. 206 4. The link header/trailer are set as for a multi-destination TRILL 207 Data frame [RFC6325]. 209 3.2 Receipt 211 When a TRILL Data frame with an Inner.MacDA of Nearest-RBridge is 212 egressed at an RBridge, it MUST be discarded unless it passes the 213 following TRILL Header tests: 215 1. The M bit is zero and the egress nickname is Any-RBridge. 217 2. The hop count confirms that it came from an immediate neighbor 218 [RFC5082]; that is, the hop count is 0x3F before decrement or 0x3E 219 if tested after decrement. 221 If not discarded, it is assumed to be directed to the egress RBridge 222 itself and is handled as appropriate for the payload protocol. 224 4. Change in RFC 6325 226 A change in the behavior mandated by [RFC6325] is required to support 227 the optional features specified in this document, as follows: 229 An RBridge conformant to [RFC6325] will discard an Ethernet frame 230 that it receives whose Outer MAC destination address is the 231 Nearest-RBridge multicast address. To support LLDP to that address 232 as described in Section 2.1 above, an RBridge must accept such 233 frames and process them appropriately depending on their protocol 234 type if the RBridge implements that protocol. For example, if the 235 EtherType is the LLDP EtherType and LLDP is implemented at the 236 receiving RBridge, it would be processed as an LLDPDU. 238 5. IANA Considerations 240 IANA is requested to allocate a new TRILL multicast address 241 [01-80-C2-00-00-44 suggested] for use as the Nearest-RBridge address 242 and add this to the TRILL Multicast Addresses sub-registry. 244 6. Security Considerations 246 This document specifies how to send LLDPDUs between adjacent 247 RBridges. These techniques increase the span of the "link" over which 248 LLDP can operate. This increased span may require use of additional 249 security measures depending on the uses to which LLDP is put. If 250 sensitive information is being transported, then appropriate link 251 security should be used, depending on the link type, such as IEEE 252 [802.1AE] for Ethernet links. 254 Should an RBridge that does not understand the Any-RBridge egress 255 nickname accept a frame with Outer.MacDA of All-RBridges but with the 256 M bit zero in the TRILL Header it will simply discard the frame as 257 having a reserved egress nickname value. 259 Normative References 261 [802.1AB] - IEEE 802.1, "IEEE Standard for Local and metropolitan 262 area networks / Station and Media Access Control Connectivity 263 Discovery", IEEE Std 802.1AB-2009, 17 September 2009. 265 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 266 Intermediate System Intra-Domain Routing Exchange Protocol for 267 use in Conjunction with the Protocol for Providing the 268 Connectionless-mode Network Service (ISO 8473)", 2002. 270 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 274 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 275 5082, 277 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, A. Ghanwani, 278 "Routing Bridges (RBridges): Base Protocol Specification", RFC 279 6325, July 2011. 281 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 282 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 283 6327, July 2011. 285 [ESADIdraft] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, draft-ietf- 286 trill-esadi, work in progress. 288 Informative References 290 [802] - IEEE 802, "IEEE Standard for Local and metropolitan area 291 networks: Overview and Architecture", IEEE Std 802-2001, 8 292 March 2002. 294 [802.1AE] - IEEE 802.1, "IEEE Standard for Local and metropolitan 295 area networks / Media Access Control (MAC) Security", IEEE Std 296 802.1AE-2006, 18 August 2006. 298 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 299 networks / Virtual Bridged Local Area Networks", IEEE Std 300 802.1Q-2011, 31 August 2011. 302 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 303 Interconnection of Lots of Links (TRILL) Protocol Control 304 Protocol", RFC 6361, August 2011. 306 [Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, 307 draft-ietf-trill-rbridge-channel, work in progress. 309 Authors' Addresses 311 Donald Eastlake 3rd 312 Huawei R&D USA 313 155 Beaver Street 314 Milford, MA 01757 USA 316 Phone: +1-508-333-2270 317 EMail: d3e3e3@gmail.com 319 Anoop Ghanwani 320 Dell 321 350 Holger Way 322 San Jose, CA 95134 USA 324 Phone: +1-408-571-3500 325 Email: anoop@alumni.duke.edu 327 Copyright, Disclaimer, and Additional IPR Provisions 329 Copyright (c) 2012 IETF Trust and the persons identified as the 330 document authors. All rights reserved. 332 This document is subject to BCP 78 and the IETF Trust's Legal 333 Provisions Relating to IETF Documents 334 (http://trustee.ietf.org/license-info) in effect on the date of 335 publication of this document. Please review these documents 336 carefully, as they describe your rights and restrictions with respect 337 to this document. Code Components extracted from this document must 338 include Simplified BSD License text as described in Section 4.e of 339 the Trust Legal Provisions and are provided without warranty as 340 described in the Simplified BSD License. The definitive version of 341 an IETF Document is that published by, or under the auspices of, the 342 IETF. Versions of IETF Documents that are published by third parties, 343 including those that are translated into other languages, should not 344 be considered to be definitive versions of IETF Documents. The 345 definitive version of these Legal Provisions is that published by, or 346 under the auspices of, the IETF. Versions of these Legal Provisions 347 that are published by third parties, including those that are 348 translated into other languages, should not be considered to be 349 definitive versions of these Legal Provisions. For the avoidance of 350 doubt, each Contributor to the IETF Standards Process licenses each 351 Contribution that he or she makes as part of the IETF Standards 352 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 353 language to the contrary, or terms, conditions or rights that differ 354 from or are inconsistent with the rights and licenses granted under 355 RFC 5378, shall have any effect and shall be null and void, whether 356 published or posted by such Contributor, or included with or in such 357 Contribution.