idnits 2.17.1 draft-ietf-isis-layer2-11.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 (February 9, 2011) is 4818 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' == Outdated reference: A later version (-04) exists of draft-hasmit-otv-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Banerjee 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track D. Ward 5 Expires: August 13, 2011 Juniper Networks 6 February 9, 2011 8 Extensions to IS-IS for Layer-2 Systems 9 draft-ietf-isis-layer2-11 11 Abstract 13 This document specifies the Intermediate System to Intermediate 14 System (IS-IS) extensions necessary to support link state routing for 15 any protocols running directly over Layer-2. While supporting this 16 concept involves several pieces, this document only describes 17 extensions to IS-IS. Furthermore, the Type, Length, Value pairs 18 (TLVs) described in this document are generic Layer-2 additions and 19 specific ones as needed are defined in the IS-IS technology specific 20 extensions. We leave it to the systems using these IS-IS extensions 21 to explain how the information carried in IS-IS is used. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 13, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. TLV Enhancements to IS-IS . . . . . . . . . . . . . . . . . . 4 60 2.1. Multi Topology aware Port Capability TLV . . . . . . . . . 4 61 2.2. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 4 62 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Overview 72 There are a number of systems (for example, [RBRIDGES], [802.1aq], 73 [OTV]) that use Layer-2 addresses carried in a link state routing 74 protocol, specifically Intermediate System to Intermediate System 75 (IS-IS) [IS-IS] [RFC 1195], to provide true Layer-2 routing. In 76 almost all the technologies mentioned above, classical Layer-2 77 packets are encapsulated with an outer header. The outer header 78 format varies across all these technologies. This outer header is 79 used to route the encapsulated packets to their destination. 81 Each Intermediate System (IS) advertises one or more IS-IS Link State 82 Protocol Data Units (PDUs) with routing information. Each Link State 83 PDU (LSP) is composed of a fixed header and a number of tuples, each 84 consisting of a Type, a Length, and a Value. Such tuples are 85 commonly known as TLVs. In this document we specify a set of TLVs to 86 be added to [IS-IS] PDUs, to support these proposed systems. The 87 TLVs are generic Layer-2 additions and specific ones, as needed, are 88 defined in the IS-IS technology specific extensions. This draft does 89 not propose any new forwarding mechanisms using this additional 90 information carried within IS-IS. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119. 98 2. TLV Enhancements to IS-IS 100 This section specifies the enhancements for the TLVs that are needed 101 in common by Layer-2 technologies. 103 2.1. Multi Topology aware Port Capability TLV 105 The Multi-Topology aware Port Capability (MT-PORT-CAP) is an IS-IS 106 TLV type 143, and has the following format: 108 +-+-+-+-+-+-+-+-+ 109 | Type=MTPORTCAP| (1 byte) 110 +-+-+-+-+-+-+-+-+ 111 | Length | (1 byte) 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 |R|R|R|R| Topology Identifier | (2 bytes) 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | sub-TLVs (variable bytes) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 o Type: TLV Type, set to MT-PORT-CAP TLV 143. 120 o Length: Total number of bytes contained in the value field, 121 including the length of the sub-TLVs carried in this TLV. 123 o R: Reserved 4-bits, MUST be sent as zero and ignored on receipt. 125 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 126 of the topology being announced. This field when set to zero 127 implies that it is being used to carry base topology information. 129 o sub-TLVs: The MT-PORT-CAP TLV value contains sub-TLVs formatted as 130 described in [RFC 5305]. They are defined in the technology 131 scoped documents. 133 The MT-PORT-CAP TLV may occur multiple times, and is carried within a 134 IS-IS Hello (IIH) PDU. 136 2.2. The MAC-Reachability TLV 138 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 147 and has the 139 following format: 141 +-+-+-+-+-+-+-+-+ 142 | Type= MAC-RI | (1 byte) 143 +-+-+-+-+-+-+-+-+ 144 | Length | (1 byte) 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Topology-Id/ Nickname | (2 bytes) 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Confidence | (1 byte) 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | RESV | VLAN-ID | (2 bytes) 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | MAC (1) (6 bytes) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | ................. | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | MAC (N) (6 bytes) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 o Type: TLV Type, set to 147 (MAC-RI). 161 o Length: Total number of bytes contained in the value field given 162 by 5 + 6*n bytes. 164 o Topology-Id/Nickname : Depending on the technology in which it is 165 used, this carries the topology-id or nickname. When this field 166 is set to zero this implies that the MAC addresses are reachable 167 across all topologies or across all nicknames of the originating 168 IS. 170 o Confidence: This carries an 8-bit quantity indicating the 171 confidence level in the MAC addresses being transported. Whether 172 this field is used, and its semantics if used, are further defined 173 by the specific protocol using Layer-2 IS-IS. If not used, it 174 MUST be set to zero on transmission and be ignored on receipt. 176 o RESV: (4-bits) MUST be sent as zero and ignored on receipt. 178 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 179 all subsequent MAC addresses in this TLV, or the value zero if no 180 VLAN is specified. 182 o MAC(i): This is the 48-bit MAC address reachable from the IS that 183 is announcing this TLV. 185 The MAC-RI TLV is carried in a standard Link State PDU (LSP). This 186 TLV can be carried multiple times in an LSP and in multiple LSPs. It 187 MUST contain only unicast addresses. The manner in which these TLVs 188 are generated by the various Layer-2 routing technologies, and the 189 manner they are consumed are detailed in the technology specific 190 documents. 192 In most of the technologies, these MAC-RI TLVs will translate to 193 populating the hardware with these entries with appropriate next-hop 194 information as derived from the advertising IS. 196 3. Acknowledgements 198 The authors would like to thank Peter Ashwood-Smith, Donald E. 199 Eastlake 3rd, Dino Farinacci, Don Fedyk, Les Ginsberg, Radia Perlman, 200 Mike Shand, and Russ White for their useful comments. 202 4. Security Considerations 204 This document adds no additional security risks to IS-IS, nor does it 205 provide any additional security for IS-IS. 207 5. IANA Considerations 209 This document specifies the definition of a set of new IS-IS TLVs, 210 the Port-Capability TLV (type 143), and the MAC-Reachability TLV 211 (type 147) that needs to be reflected in the IS-IS TLV code-point 212 registry. 214 IIH LSP SNP 215 MT-Port-Cap-TLV (143) X - - 216 MAC-RI TLV (147) - X - 218 6. References 220 6.1. Normative References 222 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 223 to Intermediate System Intra-Domain Routing Exchange 224 Protocol for use in Conjunction with the Protocol for 225 Providing the Connectionless-mode Network Service (ISO 226 8473)", 2002. 228 [RFC 1195] 229 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 230 Dual Environments", 1990. 232 [RFC 5305] 233 Li, T. and H. Smit, "IS-IS Extensions for Traffic 234 Engineering", 2008. 236 6.2. Informative References 238 [IEEE 802.1aq] 239 "Standard for Local and Metropolitan Area Networks / 240 Virtual Bridged Local Area Networks / Amendment 9: 241 Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. 243 [OTV] Grover, H., Farinacci, D., and D. Rao, "OTV: Overlay 244 Transport Virtualization", draft-hasmit-otv-01, 2010. 246 [RBRIDGES] 247 Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 248 Ghanwani, "RBridges: Base Protocol Specification", 2010. 250 Authors' Addresses 252 Ayan Banerjee 253 Cisco Systems 254 170 W Tasman Drive 255 San Jose, CA 95138 256 US 258 Email: ayabaner@cisco.com 260 David Ward 261 Juniper Networks 262 1194 N. Mathilda Ave. 263 Sunnyvale, CA 94089-1206 264 USA 266 Phone: +1-408-745-2000 267 Email: dward@juniper.net