idnits 2.17.00 (12 Aug 2021) /tmp/idnits7927/draft-fedyk-isis-spb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations / ISO Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 42 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IS-IS], [MT], [RFC2119], [PBB], [IS-IS-L2], [NLPID]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 183 has weird spacing: '...ertises this ...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'IS-IS-L2' on line 485 looks like a reference -- Missing reference section? 'RFC2119' on line 459 looks like a reference -- Missing reference section? 'MT' on line 462 looks like a reference -- Missing reference section? 'IS-IS' on line 496 looks like a reference -- Missing reference section? 'PBB' on line 480 looks like a reference -- Missing reference section? 'NLPID' on line 489 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group Peter Ashwood-Smith 3 Internet-Draft Don Fedyk 4 Date Created: June, 2009 David Allan 5 Expiration Date: January, 2010 Jerome Chiabaut 6 Intended Status: Informational Nigel Bragg 8 Preliminary 10 Shortest Path Bridging and Backbone Bridging with IS-IS 11 draft-fedyk-isis-spb-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire in January 6th 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your 46 rights and restrictions with respect to this document. 48 Abstract 50 Several techniques are being developed which use IS-IS to deliver 51 link state based layer 2 forwarding. The superset of the extensions 52 proposed to IS-IS to allow these capabilities is found in [IS-IS- 53 L2]. One technique for layer 2 forwarding is being specified in 54 the IEEE 802.1aq task group, under the over-arching title 55 of "Shortest Path Bridging" (SPB). SPB however only requires a 56 subset of the proposed IS-IS extensions in [IS-IS-L2]. For clarity 57 this informational draft documents only the subset required by SPB. 58 In addition a high level introduction, describing how these TLVs 59 are used is provided for those who do not follow the IEEE work in 60 detail. A reference is also given to the normative IEEE 802.1aq 61 document The ordering of material in this document follows that of 62 Clause 28 of IEEE 802.1aq, to aid cross-referencing. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 Table of Contents 72 1. Terminology..................................................3 73 2. Introduction.................................................4 74 3. New TLVs for SPB and SPBB....................................6 75 3.1 Base Vlan-Identifiers sub-TLV................................7 76 3.2 SPB/SPBB Instance sub-TLV....................................8 77 3.3 SPB Link Metric sub-TLV......................................9 78 3.4 The Group MAC Address sub-TLV................................9 79 3.5 The Service Identifier and Unicast Address sub-TLV..........10 80 4. Security Considerations.....................................10 81 5. IANA Considerations / ISO Considerations....................10 82 6. References..................................................11 83 6.1 Normative References........................................11 84 6.2 Informative References......................................11 85 7. Acknowledgments.............................................12 86 8. Author's Addresses..........................................12 88 1. Terminology 90 In addition to well understood IS-IS terms, this memo uses 91 terminology from IEEE 802.1 and introduces a few new terms: 93 802.1ah Provider Backbone Bridges a.k.a. Mac-in-Mac 94 encapsulation 95 802.1aq Shortest Path Bridging (SPB) 96 B-DA Backbone Destination Address in 802.1ah Mac-in-Mac 97 header 98 B-MAC Backbone MAC Address 99 B-SA Backbone Source address in 802.1ah Mac-in-Mac header 100 B-VID Backbone VLAN ID in 802.1ah Mac-in-Mac header 101 B-VLAN Backbone Virtual LAN 102 C-MAC Customer MAC. Inner MAC in 802.1ah Mac-in-Mac header 103 C-VID Customer VLAN ID 104 C-VLAN Customer Virtual LAN 105 DA Destination Address 106 FIB Forwarding information base (B-DA/B-VID to next hop(s)) 107 ISID 802.1ah: service membership in datapath(not always=SID) 108 MAC Media Access Control 109 PBB Provider Backbone Bridges as specified in 802.1ah 110 M-IS-IS Multi Topology IS-IS as used in [MT] 111 MT Multi Topology. As used in [MT] 112 MT-ID Multi Topology Identifier (12 bits). As used in [MT] 113 SPSourceID 20 bit nodal identifier used with SID forms mcast DA. 114 PATHID The unique identifier for a path used for symmetric tie 115 breaking 116 PBB Provider Backbone Bridge 117 PBT Provider Backbone Transport 118 SA Source Address 119 SID Service Identifier at control plane, groups many ISIDs 120 UNI User Network Interface: Customer/Backbone attach point 121 VID VLAN ID 123 2. Introduction 125 Shortest Path Bridging (SPB) and Shortest Path Backbone Bridging 126 (SPBB) both apply the [IS-IS] protocol to the utilization of mesh 127 topologies for native Ethernet bridging. While 802.1aq has the 128 umbrella title of shortest path bridging, this memo adopts the 129 convention of ascribing unique attributes to the terms SPB and SPBB 130 individually; SPB uses an IEEE 802.1Q forwarding paradigm, whilst 131 SPBB extends the FIB population techniques specified in 802.1Qay 132 combined with IEEE 802.1ah [PBB] adaptation. Both SPB and SPBB 133 forward packets on shortest path trees with minimum path cost as a 134 first order tie-breaker, where for any pair of nodes A and B, the 135 unicast path for A to B is the exact reverse of the path from B to A 136 (reverse path congruency), and all multicast traffic between the two 137 nodes follows the unicast path (multicast and unicast congruency). 138 These are direct extensions to fundamental Ethernet forwarding 139 properties in IEEE bridged networks. 141 In SPB, conventional bridge learning is used to associate (customer) 142 MAC addresses to ports and hence routes through the SPB region. The 143 source-rooted tree associated with each node is assigned a unique 144 VLAN ID (the SPVID) to identify it. 146 The 802.1ah [PBB] MAC-in-MAC encapsulation used by SPBB permits the 147 isolation of customer Ethernet addressing from backbone Ethernet 148 addressing in the core of a network. This has an important 149 consequence; the association between a customer MAC (C-MAC) and a B- 150 MAC to resolve forwarding across the core is required only at the 151 edge of the network. Flooding is only done by the edge adaptation 152 functions to learn which B-MAC reaches a given C-MAC using the 153 normal PBB C-MAC learning behavior, flooding at the C-MAC layer 154 resolving to a service specific multicast tree at the B-MAC layer. 156 A minimum of one B-VID MUST be assigned to each instance of SPBB 157 (IS-IS MT-ID). The B-VID MUST be unique backbone network wide. Two 158 B-VIDs MAY be used by a single SPBB instance (MT-ID) when it is 159 desired to use more than one equal cost shortest path permutation. 161 With Spanning Tree Protocol (STP), Rapid STP or Multiple STP[802.1Q] 162 Ethernet networks use a shared spanning tree (or a small number of 163 shared trees) to route traffic based on the VLAN ID and then on 164 learned MAC addresses. Per service multicast is instantiated as a 165 (*,G) multicast address which is a proper subset of the VID. 167 In order to move from a shared spanning tree to mesh connectivity, 168 SPB and SPBB use one or more broadcast trees per source as a 169 template for per service multicast trees i.e.(S,G). 171 SPB uses the SPVID when flooding, with conventional pruning as C-MAC 172 addresses are learned. 174 SPBB adapts client flooding onto service specific multicast trees 175 instantiated by encoding S,G in the destination MAC address. SPBB 176 therefore uses both B-VID and B-MAC when forwarding. 178 SPBB uses algorithmically constructed addresses for the multicast 179 DA. Multicast addresses are local to a PBB domain. The multicast B- 180 MAC DA address constructed for a particular node/service consists of 181 a unique nodal identifier called a SPSourceID (20 bits), combined 182 with the service identifier (SID) (24 bits). Every SPBB node(per 183 SPBB instance/MT-ID) therefore advertises this unique SPSourceID 184 which can be correlated to the node's ISIS SYSID by all nodes in the 185 SPBB network. 187 In SPB, a VID (called the Base VID) is also defined for 188 interoperation with xSTP regions. This VID identifies the Common and 189 Internal Spanning Tree (CIST) in the Shortest Path Region. It is 190 created as a conventional Spanning Tree within the SPB region, and 191 Group MAC addresses, installed by conventional Ethernet mechanisms, 192 may be supported on this VID. 194 A node performing SPB or SPBB calculations (for a given instance/MT- 195 ID) use the IS-IS topology, and link metrics to compute which leaves 196 of each shortest path tree require transit of the local node, and 197 this node can then do pair-wise comparison of services of interest 198 between the root and the leaves to populate the FIB accordingly. The 199 link metrics are forced to be equal in both directions by defaulting 200 to the largest of the two unidirectional metrics specified for a 201 link as seen during the establishment of a standard IS-IS adjacency. 203 A node performing SPB or SPBB for a given MT instance MUST specify 204 the NLPID for SPB and SPBB (IANA allocation 0xC1 pending) in its IS- 205 IS hello message. Links that do not support this NLPID for this MT 206 instance must be excluded from the shortest path computations by the 207 given MT instance. 209 Both SPB and SPBB employ a transitive symmetric tie breaking 210 algorithm which chooses deterministically and progressively between 211 equal cost alternatives by ranking the paths according to the sorted 212 list of node identifiers that make up the path. This sorted list of 213 node identifiers (SYSIDs) is called the Path Identifier (PATHID). 214 For SPB, and when only one B-VID is used in SPBB, the tie breaking 215 algorithm will always pick from a set of equal cost shortest path 216 alternatives by choosing the path with the lowest PATHID. Two B-VID 217 instances MAY be used for an SPBB instance, when it will assign the 218 lowest PATHID paths to one B-VID and the highest PATHID paths to the 219 other B-VID. In this manner an SPBB instance will use more of the 220 available paths in a network but will do so by assignment of packets 221 at the head ends to one of different SPBB B-VIDs. 223 3. New TLVs for SPB and SPBB 225 SPB and SPBB require a subset of the [MT] TLVs. 227 SPB and SPBB inherit the Multi Topology mechanisms from [MT] to 228 allow multiple logical bridging instances to exist within a single 229 IS-IS control instance. Top level TLV's used by SPB and SPBB 230 therefore begin with the Multi Topology Identifier (MT-ID) fields as 231 defined in [MT] and the new sub-TLVs identified here may be used as 232 sub-TLVs of the corresponding new top level Multi Topology TLV's 233 defined in [MT]. 235 In the IEEE the Multiple Spanning tree protocol allowed multiple 236 VIDs to represent a single VLAN. The single "logical" VLAN was 237 identified by a Base VID so that bridges external to the region 238 could have a consistent VID to identify the VLAN. This concept of a 239 Base VID extends easily to SPB and SPBB. In this way a Base VID can 240 be used to identify a topology instance and to correlate VIDs that 241 are allocated to a particular shortest path VLAN instance. 243 A Shortest Path Region also has the property that viewed from 244 outside the Region it appears as a single 802.1Q or 802.1ah bridge, 245 irrespective of how the VLAN is implemented. 247 In SPB, each node uses a unique VID as its source identifier (an 248 SPVID), and each SPVID is correlated to a Base VID. The set of 249 SPVIDs that map to a given Base VID form the SPB region. In SPBB, 250 this concept is reused however there is a slight modification. A 251 single B-VID maps to a Base VID for all bridges. However multiple B- 252 VIDs (currently two) can map to the same Base VID allowing multiple 253 trees within the SPBB VLAN. A typical use for multiple trees is to 254 instantiate equal cost paths and provide the opportunity to load 255 spread services. 257 A Base VID identifies a traditional spanning tree in both SPB and 258 SPBB that can be used to represent the VLAN for proper bridge 259 behavior when viewed by bridges outside the shortest path region. 260 In essence the VLAN identified by this Base VID can appear as a 261 single bridge allowing proper spanning tree behavior. 263 The following sections introduce the new [MT] TLVs which are used by 264 SPB and SPBB, and give an overview of their use from an SPB and SPBB 265 perspective. 267 3.1 Base Vlan-Identifiers sub-TLV 269 The Base Vlan-Identifier sub-TLV (section 2.3.5 of [IS-IS-L2]) is 270 carried within the Multi Topology aware Port Capability TLV (section 271 2.3 of [IS-IS-L2]), and this is carried in an IIH PDU. 273 The purpose of this sub-TLV is to check for compatible configuration 274 of SPB or SPBB mode of operation and then of SPB or SPBB parameters 275 as bridges form adjacencies, and to prevent adjacency formation when 276 incompatible configurations are detected. 278 In informal terms this requires : 279 - agreement on the NLPID for SPB and SPBB 280 - specification of the bridging mode to be used (SPB or SPBB) 281 - binding of individual VIDs to the Base VID, and specification of 282 the shortest path bridging algorithm to be used for each VID 283 - use (or not) of auto allocation capability for SPVIDs in SPB and 284 SPSourceIDs in SPBB. 286 It was mentioned earlier that each SPB node is assigned a unique VID 287 (a Shortest Path VID, or SPVID) as its source identifier for all 288 traffic it transmits. The set of SPVIDs, one for each SPB node in 289 the region, are bound to the Base VID, configured to execute a 290 specific tiebreaking algorithm, and collectively provide the 291 shortest path trees to support the VLAN. A control flag in the sub- 292 TLV determines whether the SPVIDs are provisioned, or auto-allocated 293 by the procedure in [801.1aq] 295 In SPB, the Base VID is also used to identify a VLAN providing peer 296 inter-working with other non-SPB bridges outside the SPB Region. 297 This VLAN forms a spanning tree across the region to achieve this. 299 In SPBB, the VID(s) on which forwarding is performed are Region-wide 300 assignments. At present, the use of one or two VIDs is defined, 301 with the latter capability available for edge-based load spreading 302 using Equal Cost Multiple Trees generated via the symmetric tie- 303 breaking variations. 305 Three algorithms are currently available to SPB and SPBB : 306 - spanning tree algorithm, which constructs a tree which is the 307 same as would be constructed by Spanning Tree Protocol [802.1D] 308 - shortest path trees, selecting the low PATHID as a tie-breaker 309 - shortest path trees, selecting the high PATHID as a tie-breaker 311 3.2 SPB/SPBB Instance sub-TLV 313 The SPB/SPBB Instance sub-TLV (section 2.5.1 of [IS-IS-L2]) is 314 carried within the Multi Topology Aware Capability TLV (section 2.5 315 of [IS-IS-L2]). 317 The purpose of this sub-TLV is to announce configuration and other 318 parameters to the entire SPB or SPBB Region. The instance sub-TLV 319 carries some information elements common to the Base VLAN- 320 Identifiers sub-TLV described in the previous section, which are : 321 - binding of individual VIDs to the Base VID, and specification of 322 the shortest path bridging algorithm to be used for each VID 323 - use (or not) of auto allocation capability for SPVIDs in SPB and 324 SPSourceIDs in SPBB. 326 The SPB/SPBB Instance sub-TLV carries further information : 327 - the SPSourceID - the 20 bit network wide unique identifier used 328 in the higher order bits of the SPBB multicast DA for packets 329 originating at this node 330 - various Spanning Tree parameters for inter-working with non-SPB 331 regions 333 In SPB, the multicast tree built off each SPB node is uniquely 334 associated with an SPVID which thereby identifies the source. The 335 required (S,G) trees, and loop avoidance checking, may be directly 336 implemented using this SPVID by standard Ethernet forwarding. The 337 SPVID can be configured from a pool or it can be auto allocated. 339 In SPBB multicast, the same capability is achieved by encoding the 340 service-specific (S,G) tree in the multicast Destination Address. 341 This is achieved by concatenating the PBB Service Identifier with 342 the nodal SPSourceID. The distribution of SPSourceID therefore 343 allows all SPBB nodes to compute the forwarding state they need to 344 install, based only on topology and service endpoint locations. The 345 computed SPBB multicast DA looks like this: 347 +-+-+-+-+-----------------------+---------------------------+ 348 |M/L| A | SPSourceID (20 bit) | I-SID (24 bit) | 349 +-+-+-+-+-----------------------+---------------------------+ 351 Where M/L = multicast/local bits 352 (2 bits - both set to 1) 353 A = SPSourceID allocation style 354 (2 bits - both 0 initially) 356 Figure 1: SPBB multicast MAC address construction 358 The SPSourceID can be provisioned, or auto allocated. 360 The Spanning tree inter-working parameters for SPB comprise : 362 - a Spanning tree compatible Bridge identifier, configured exactly 363 as specified in [802.1D]. This allows SPB to build a compatible 364 Spanning tree using link state. 365 - The Base VID identifies a VLAN capable of covering multiple 366 Regions, SPB and non-SPB. In SPB, this is known as the Common 367 and Internal Spanning Tree (CIST). At SPB Region boundaries, the 368 CIST Root Identifier and the CIST External Root Path Cost may be 369 imported from xSTP and flooded by IS-IS as a part of SPB`s 370 Spanning Tree emulation. 372 3.3 SPB Link Metric sub-TLV 374 SPB Link Metric sub-TLV (section 2.6 of [IS-IS-L2]) is carried 375 within the Extended Reachability TLV, or the Multi Topology 376 Intermediate System TLV. 378 The purpose of this sub-TLV is to announce SPB link metrics, in a 379 form which enables SPB to build xSTP compatible Spanning Trees, 380 typically to create the SPB component of the CIST (above) : 381 - indicates the administrative cost or weight of using a link 382 - a standard IEEE port identifier used to build a spanning tree 383 associated with this link 385 3.4 The Group MAC Address sub-TLV 387 The Group MAC Address sub-TLV (section 2.2.1 of [IS-IS-L2]) is 388 carried within the Group Address TLV (section 2.2 of [IS-IS-L2]), 389 which is in turn carried within the Multicast Group Level 1 link 390 state PDU. 392 This sub-TLV is used only by SPB. SPBB builds and installs per- 393 service per-source multicast addresses algorithmically, as 394 described earlier, using the SPSourceID and PBB Service Identifier 395 information announced in other sub-TLVs. 397 By default, SPB nodes broadcast traffic to all other nodes in their 398 region. When inter-working with non-SPB regions over the CIST, 399 multicast group membership may be signaled over the CIST using 400 mechanisms such as MMRP [802.1ak]. The Group MAC Address sub-TLV 401 allows such registrations to be imported and announced by IS-IS. 403 The sub-TLV carries the following information for SPB : 404 - the VID with which all subsequent MAC addresses are associated 405 - sets of group records, each consisting of a multicast group 406 address and a list of unicast MAC addresses known to be sources 407 of that group. 409 3.5 The Service Identifier and Unicast Address sub-TLV 411 The Service Identifier and Unicast Address sub-TLV (section 2.5.2 of 412 [IS-IS-L2]) is carried within the Multi Topology Aware Capability 413 TLV (section 2.5 of [IS-IS-L2]). 415 The purpose of this sub-TLV is to announce service group membership 416 (using the PBB Service Identifier or I-SID) on the originating node, 417 also to advertise an additional B-MAC unicast address present on or 418 reachable by the node. It is applicable to SPBB only. 420 This sub-TLV carries: 421 - the unicast B-MAC address which must be used to send to the set 422 of PBB I-SIDs announced in the sub-TLV, and which this node will 423 use as its source B-MAC when transmitting these I-SIDs 424 - the unicast VID which must be used to send to the set of PBB I- 425 SIDs announced in the sub-TLV, and which this node will use when 426 transmitting these I-SIDs 427 - a list of PBB I-SIDs and their transmit and receive properties. 429 Announcement of I-SIDs in this way allows all SPBB nodes to see all 430 service endpoints, and allows nodes not terminating a particular 431 service to algorithmically determine the per-service per-source 432 forwarding state which they must install if they lie on the shortest 433 path between two or more service end-points. 435 The advertisement of the B-MAC unicast address to be used to reach 436 the set of services allows different granularities of addressing to 437 be used within the SPBB node, without compromising inter-working 438 between nodes of different types. It also has application in some 439 resiliency schemes. 441 4. Security Considerations 443 This document adds no additional security risks to IS-IS. 445 SPBB assumes that the link state bridged subnetwork consists of 446 trusted devices and that the UNI ports to the domain are untrusted. 447 Care is required to ensure untrusted access to the trusted domain 448 does not occur. 450 5. IANA Considerations / ISO Considerations 452 See the subset of [IS-IS-L2] cited by this document and also the 453 NLPID assignments requested by [NLPID]. 455 6. References 457 6.1 Normative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 [MT] Multi Topology (MT) Routing in Intermediate System to 463 Intermediate Systems (IS-ISs), 464 RFC 5120, February 2008 466 [802.1D] "IEEE draft Standard for Local and Metropolitan 467 Networks, Media Access Control (MAC) Bridges", 468 IEEE 802.D June 2004 470 [802.1aq] "IEEE draft Standard for Local and Metropolitan 471 Networks, Virtual Bridged Local Area Networks, 472 Amendment 9: Shortest Path Bridging", 473 IEEE 802.1aq D2.0, June 2009 475 [802.1ak] "IEEE Standard for Local and Metropolitan Networks, 476 Virtual Bridged Local Area Networks, Amendment 7: 477 Multiple Registration Protocol" 478 IEEE Std 802.1ak - 2007 amendment to IEEE 802.Q - 2005 480 [PBB] "IEEE Standard for Local and Metropolitan 481 Networks, Virtual Bridged Local Area Networks, 482 Amendment 7: Provider Backbone Bridges" 483 IEEE Std 802.1ah - 2008 amendment to IEEE 802.Q - 2005 485 [IS-IS-L2] Extensions to IS-IS for Layer-2 Systems, IETF, 486 Internet Draft, draft-ietf-isis-layer2-00.txt, 487 Work in Progress, June 2009 489 [NLPID] IANA Considerations for NLPIDs, IETF, 490 Internet Draft, Draft-eastlake-nlpid-iana- 491 considerations-00.txt, 492 Work in Progress, June 23, 2009 494 6.2 Informative References 496 [IS-IS] ISO/IEC 10589:2002, "Intermediate system to 497 Intermediate system routing information exchange 498 protocol" ISO/IEC 499 10589:2002. 501 7. Acknowledgments 503 The authors would like to thank Antonela Paraschiv, Daniel Joyal, 504 Paul Unbehagen and Gautam Khera for their detailed review of this 505 work. 507 8. Author's Addresses 509 Don Fedyk 510 Alcatel-Lucent 511 220 Hayden Road 512 Groton, MA, USA 513 Email donald.fedyk@alcatel-lucent.com 515 Peter Ashwood-Smith 516 Huawei Technologies Canada 517 411 Leggget Drive, Suite 503 518 Kanata, Ontario, K2k3C9, Canada 519 Email: peter.ashwoodsmith@huawei.com 521 Nigel Bragg 522 Nortel Networks 523 London Road, Harlow, 524 Essex CM17 9NA, UK 525 Email: nbragg@nortel.com 527 David Allan 528 Nortel Networks 529 3500 Carling Ave. 530 Ottawa, ON, Canada 531 K1Y4H7 532 Email: dallan@nortel.com 534 Jerome Chiabaut 535 Nortel Networks 536 3500 Carling Ave. 537 Ottawa, ON, Canada 538 K1Y 4H7 539 Email: chiabaut@nortel.com