idnits 2.17.1 draft-ietf-isis-layer2-07.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 26, 2010) is 4961 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: 'RFC1195' is mentioned on line 73, but not defined == Missing Reference: 'TBD' is mentioned on line 169, but not defined == Missing Reference: 'RFC5305' is mentioned on line 182, but not defined == Missing Reference: 'RFC 5226' is mentioned on line 212, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC 1195' is defined on line 224, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' == Outdated reference: A later version (-04) exists of draft-hasmit-otv-00 Summary: 1 error (**), 0 flaws (~~), 7 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: March 30, 2011 Juniper Networks 6 September 26, 2010 8 Extensions to IS-IS for Layer-2 Systems 9 draft-ietf-isis-layer2-07 11 Abstract 13 This document specifies the IS-IS extensions necessary to support 14 link state routing to any protocols running directly over layer 2. 15 While supporting this concept involves several pieces, this document 16 only describes extensions to IS-IS. Furthermore, the TLVs described 17 in this document are generic layer 2 additions and specific ones as 18 needed are defined in the IS-IS technology specific extensions. We 19 leave it to the systems using these IS-IS extensions to explain how 20 the information carried in IS-IS is used. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 30, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. TLV Enhancements to IS-IS . . . . . . . . . . . . . . . . . . 4 59 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 4 60 2.2. Multi Topology aware Port Capability TLV . . . . . . . . . 5 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Overview 71 There are a number of systems (for example, [RBRIDGES], [802.1aq], 72 [OTV]) that use layer 2 addresses carried in a link state routing 73 protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 74 2 routing. In almost all the technologies mentioned above, classical 75 Layer 2 packets are encapsulated with an outer header. The outer 76 header format varies across all these technologies. This outer 77 header is used to route the encapsulated packets to their 78 destination. 80 In this document we specify a set of TLVs to be added to [IS-IS] 81 level 1 PDUs, to support these proposed systems. The TLVs are 82 generic layer 2 additions and specific ones as needed are defined in 83 the IS-IS technology specific extensions. This draft does not 84 propose any new forwarding mechanisms using this additional 85 information carried within IS-IS. 87 1.1. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119. 93 2. TLV Enhancements to IS-IS 95 In this section we specify the enhancements for the TLVs that are 96 needed in common by Layer-2 technologies. 98 2.1. The MAC-Reachability TLV 100 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the 101 following format: 103 +-+-+-+-+-+-+-+-+ 104 | Type= MAC-RI | (1 byte) 105 +-+-+-+-+-+-+-+-+ 106 | Length | (1 byte) 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Topology-Id/ Nickname | (2 bytes) 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Confidence | (1 byte) 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | RESV | VLAN-ID | (2 bytes) 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | MAC (1) (6 bytes) | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | ................. | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | MAC (N) (6 bytes) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 o Type: TLV Type, set to 141 (MAC-RI). 123 o Length: Total number of bytes contained in the value field given 124 by 5 + 6*n bytes. 126 o Topology-Id/Nickname : Depending on the technology in which it is 127 used, this carries the topology-id or nickname. When this field 128 is set to zero this implies that the MAC addresses are reachable 129 across all topologies or across all nicknames of the originating 130 IS. 132 o Confidence: This carries an 8-bit quantity indicating the 133 confidence level in the MAC addresses being transported. Whether 134 this field is used, and its semantics if used, are further defined 135 by the specific protocol using Layer-2-IS-IS. If not used, it 136 MUST be set to zero on transmission and be ignored on receipt. 138 o RESV: Must be sent as zero on transmission and is ignored on 139 receipt. 141 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 142 all subsequent MAC addresses in this TLV, or the value zero if no 143 VLAN is specified. 145 o MAC(i): This is the 48-bit MAC address reachable from the IS that 146 is announcing this TLV. 148 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 149 MUST contain only unicast addresses. The manner in which these TLVs 150 are generated by the various Layer 2 systems, and the manner they are 151 consumed are detailed in the technology specific documents. 153 In most of the technologies, these MAC-RI TLVs will translate to 154 populating the hardware with these entries with appropriate next-hop 155 information as derived from the advertising IS. 157 2.2. Multi Topology aware Port Capability TLV 159 The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS 160 TLV type 143 [TBD], and has the following format: 161 0 1 2 3 162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |Type=MT PORTCAP| Length |R|R|R|R| Topology Identifier | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | sub-TLVs | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 o Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. 171 o Length: Total number of bytes contained in the value field, 172 including the length of the sub-TLVs carried in this TLV. 174 o R: Reserved, MUST be sent as zero on transmission and is ignored 175 on receipt. 177 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 178 of the topology being announced. This field when set to zero 179 implies that it is being used to carry base topology information. 181 o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- 182 TLVs formatted as described in [RFC5305]. They are defined in the 183 technology scoped documents. 185 The MT-PORT-CAP TLV may occur multiple times, and is carried only 186 within a IIH PDU. 188 3. Acknowledgements 190 The authors would like to thank Peter Ashwood-Smith, Donald E. 191 Eastlake 3rd, Dino Farinacci, Don Fedyk, Les Ginsberg, Radia Perlman, 192 Mike Shand, and Russ White for their useful comments. 194 4. Security Considerations 196 This document adds no additional security risks to IS-IS, nor does it 197 provide any additional security for IS-IS. 199 5. IANA Considerations 201 This document specifies the definition of a set of new IS-IS TLVs, 202 the MAC-Reachability TLV (type 141), and the Port-Capability TLV 203 (type 143) that needs to be reflected in the IS-IS TLV code-point 204 registry. 206 IIH LSP SNP 207 MAC-RI TLV (141) - X - 209 MT-Port-Cap-TLV (143) X - - 211 IANA SHOULD manage the remaining space using the IETF Review method 212 [RFC 5226]. 214 6. References 216 6.1. Normative References 218 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 219 to Intermediate System Intra-Domain Routing Exchange 220 Protocol for use in Conjunction with the Protocol for 221 Providing the Connectionless-mode Network Service (ISO 222 8473)", 2002. 224 [RFC 1195] 225 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 226 Dual Environments", 1990. 228 6.2. Informative References 230 [IEEE 802.1aq] 231 "Standard for Local and Metropolitan Area Networks / 232 Virtual Bridged Local Area Networks / Amendment 9: 233 Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. 235 [OTV] Grover, H., Farinacci, D., and D. Rao, "OTV: Overlay 236 Transport Virtualization", draft-hasmit-otv-00, 2010. 238 [RBRIDGES] 239 Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 240 Ghanwani, "RBridges: Base Protocol Specification", 2010. 242 Authors' Addresses 244 Ayan Banerjee 245 Cisco Systems 246 170 W Tasman Drive 247 San Jose, CA 95138 248 US 250 Email: ayabaner@cisco.com 252 David Ward 253 Juniper Networks 254 1194 N. Mathilda Ave. 255 Sunnyvale, CA 94089-1206 256 USA 258 Phone: +1-408-745-2000 259 Email: dward@juniper.net