idnits 2.17.1 draft-unbehagen-spb-ip-ipvpn-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 : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 121 has weird spacing: '... and proto...' -- The document date (March 5, 2012) is 4436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 116, but not defined == Missing Reference: 'IEEE802.1aq' is mentioned on line 117, but not defined == Missing Reference: 'SPB' is mentioned on line 361, but not defined == Missing Reference: 'ECMP' is mentioned on line 361, but not defined == Unused Reference: 'KEYWORDS' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'MTISIS' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'IPVPN' is defined on line 516, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-pbb-vpls-pe-model-00 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Paul Unbehagen 3 Intended Status: Informational Roger Lapuh 4 Expires: September 6, 2012 Avaya 5 Sue Hares 6 Peter Ashwood-Smith 7 Hauwei 9 March 5, 2012 11 IP/IPVPN services with IEEE 802.1aq SPB networks 12 draft-unbehagen-spb-ip-ipvpn-00.txt 14 Abstract 16 This document describes a compact method of using a IEEE 802.1aq 17 Shortest Path Backbone Bridging (SPB) network to natively enable and 18 carry IP and IPVPN services on native Ethernet links. Further this 19 documents the extensions to SPB's control protocol, IS-IS, required 20 to allow it to be a single mechanism for providing all these services 21 types. On its own SPB provides virtual Ethernet networks; utilizing 22 IS-IS to create loop free Ethernet topologies that forward Ethernet 23 traffic using a standard Ethernet header. This document shows how 24 the same SPB network can also be leveraged to provide IP based 25 services. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. SPB control of BMAC forwarding . . . . . . . . . . . . . . . . 4 68 3. IP forwarding with SPB . . . . . . . . . . . . . . . . . . . . 5 69 3.1. IP Unicast . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. IPVPN services with SPB . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Route Propagation Techniques . . . . . . . . . . . . . . . 6 72 4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp . . . . . 8 73 4.3. I-TAG Encapsulation . . . . . . . . . . . . . . . . . . . . 9 74 5. Interworking with MPLS based Networks . . . . . . . . . . . . . 10 75 6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 80 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1 Introduction 86 The IEEE has defined a method for L2 virtualization called Shortest 87 Path Bridging (SPB), which is leveraging IS-IS as a new Ethernet 88 control plane to control the BMAC layer of the 802.1ah PBB 89 encapsulation, replacing Ethernet's flooding and learning as the 90 backbone forwarding protocol. In addition to layer 2 (bridging), the 91 24 bits of the Service Instance defined in the 802.1ah frame format 92 can also be leveraged for any network connectivity service including 93 layer 3 Unicast and Multicast for IPv4 and IPv6. This document 94 outlines the proposed extensions to ISIS-SPB to enable this 95 functionality. The benefits of leveraging one protocol (ISIS-SPB) to 96 provide any type of connectivity service on top of Ethernet are 97 significant. 99 SPB, through the use of ISIS to exchange the connectivity service 100 topology, provides a powerful end-point-only provisioning model. 101 IP/SPB leverages this and extends this to Layer 3, thus not only L2 102 VPNs can be formed by attaching Virtual LANs to service IDs (ISIDs), 103 but also L3 VPNs can be formed by binding Virtual Route Forwarders 104 (VRFs) to ISIDs at the service attachment points. 106 Due to the fact that all connectivity services described above are 107 using the same SPB forwarding plane defined in IEEE802.1aq/.1Qbp, 108 network availability is defined by the convergence timing of the 109 single ISIS-SPB control plane. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 [IEEE802.1aq] defines a technology for providing a link state 118 protocol for the control of a common Ethernet switching layer. 120 [IEEE802.1ah] Provider Backbone Bridging is a set of architecture 121 and protocols for transporting of a customer network traffic over a 122 provider's network 124 BCB - Backbone Core Bridge 126 BDA - Backbone Destination Address 128 BEB - Backbone Edge Bridge 130 BMAC - Backbone MAC Address 131 BSA - Backbone Source Address 133 BVID - Backbone VLAN ID 135 ESP - Ethernet Switched Path 137 ISID - Service Identifier 139 ISIS - Intermediate System to Intermediate System Routing 140 Protocol 142 ISIS-SPB - ISIS extensions for SPB 144 MDT - Multicast Distribution Tree 146 SPF - Shortest Path Forwarding 148 SPB - Shortest Path Bridging 150 TLV - Type Length Value 152 VLAN - Virtual LAN 154 2. SPB control of BMAC forwarding 156 SPB uses the terms Backbone Core Bridge (BCB) and Backbone Edge 157 Bridge (BEB) to describe the functions of network nodes in the 158 network. These terms describe features that are similar in function 159 to the PE and P nodes in an MPLS network. 161 SPB enables a loop free construction of Ethernet switched paths 162 between every SPB enabled node by reusing some existing components of 163 IS-IS and by adding a small set of new IS-IS TLVs. SPB nodes use a 164 standard IS-IS mechanism of operation for neighbor discovery and 165 database distribution. SPB utilizes an IS-IS based on IS-IS Ethernet 166 link level peering protocol so it does not depend on link level IP 167 addressing. Also, due to the fact that the links are forwarding on 168 the source and destination information in the Ethernet header, there 169 is no requirement to verify that each node can do IP routing. 170 Multicast Forwarding entries (BMAC FDB or FIB) on each node are 171 constructed based on a combination of a nodal unique identifier and a 172 administratively controlled service identifier providing multicast 173 trees that can be adjusted to match a desired service granularity. 175 Each node uses standard IS-IS methods of sharing link state PDU's. 176 Those PDUs contain the System-ID of each node, the attached neighbors 177 and information such as EVPN ISIDs for SPB. A unicast SPF process 178 runs on each switch to construct the unicast connectivity of each 179 switch to every other switch based on these nodal MAC's (BMACs) 180 derived from the System-ID. Each node that is on the shortest path 181 between any other given nodes will install corresponding FDB entries 182 only on their associated ports. This has the added benefit that 183 Ethernet FDB entries exist only on nodes that are the source, root, 184 or tandem point for a give SPF ESP between any given set of nodes. 185 Any node that does not need to participate in the tandem calculations 186 may use the IS-IS overload bit to exclude tandem paths and behave as 187 only the root or source for any given service traffic. 189 3. IP forwarding with SPB 191 IP unicast and multicast can leverage this base BMAC switching layer 192 by mapping IP to the Ethernet service points. For unicast forwarding 193 the standard mechanisms of IS-IS IP route propagation can be used to 194 associate remote IP networks to the far end nodal Ethernet address. 196 The encapsulation of IP unicast packets would use the standard method 197 to include an Ethertype of 0x800 behind the BMAC header. 199 Packets received Packets in transit Packets forwarded 200 at ingress BEB in the network by egress BEB 202 +============+ +=============+ +============+ 203 | IP Header | | IP Header | | IP Header | 204 +============+ >>>>> +=============+ >>>>> +============+ 205 | C-MAC | | B-MAC | | C-MAC | 206 +============+ +=============+ +============+ 208 3.1. IP Unicast 210 The native unicast entries SPB constructs, provide a simple way of 211 enabling end to end switching of IP packets along a deterministic 212 Ethernet Switched Path (ESP). Knowledge of the location of IP 213 subnet's is achieved by utilizing the existing functionality of IS-IS 214 TLVs for IPv4 and IPv6. The control plane operation becomes one of 215 simply creating FDB entries that map IP routes to their points of 216 presence. In other words the FDB entry for an IP route simply gives 217 the last hop BMAC of the BEB which advertised that route. No shortest 218 path computations are required since that has already been 219 accomplished by the SPB layer. For IP subnet awareness the existing 220 IS-IS TLVs are used to propagate routes. The encapsulation is the 221 standard IP in Ethernet encapsulation. 223 To enable this behavior, this document specifies an efficient 224 learning and forwarding operation where an edge BEB provides a 225 standard IP interface to its attached IP devices. The BEB performs a 226 route lookup on the destination IP addresses which will resolve to a 227 remote BMAC to forward towards on the SPB portion of the network, and 228 then encapsulates the IP packet in a Ethernet header using the 229 unicast BMAC operation with a standard IPv4 or IPv6 Ethertype. In 230 essence this is IP over Ethernet where the Ethernet is a BMAC based 231 Ethernet. One simple way to think of this is that existing ISIS for 232 IP implementations forward IP packets to the next hop router, while 233 this mechanism forwards an IP packet directly to the last hop BEB 234 within the SPB domain thereby eliminating IP forwarding operations on 235 tandem devices. 237 4. IPVPN services with SPB 239 Using the TLV extensions described below it is possible to extend SPB 240 to not only provide EVPN and the above described IP connectivity, but 241 also provide virtualized solutions for IP services such as IPVPNs. 242 The next sections will outline the route propagation techniques for 243 two different deployment models. 245 Two common modes of carrying information are: BGP or ISIS [ISIS]. 246 The IS-IS method will be described in this version of the draft. The 247 control plane encapsulation of VRF routes passed in BGP is similar to 248 the method used here with ISIS. 250 4.1. Route Propagation Techniques 252 The ability to share routes within a network can be provided within 253 IS-IS. To accomplish this flexibility the use of a new IPVPN TLV and 254 an optional sub-TLV is proposed. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |R R R R| MT-ID |U|Resv | VID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |T|R| Resv |S| ISID Value | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2 IPVPN TLV 264 The TLV MAY appear any number of times (including none) within a Link 265 State PDU. 267 The up/down bit used for notification if this TLV has been leaked 268 down into a L1. 270 The T bit and R bit are used to signal to the other nodes whether to 271 construct Multicast trees to and from this announcing node depending 272 on the combination of bits set to 1. If neither the T nor R bit is 273 set, then the IPVPN service is unicast only. The next 4 bits are 274 reserved and the S bit is used to signify that the VPN-Route Sub-TLVs 275 are present. 277 Sub-TLVs may be set to carry specific routes for each VPN within IS- 278 IS. This allows for routes from multiple VPNs to be carried under 279 their respective VPN ISID IDs and allow for overlapping IP subnet's. 281 IP/SPB VPN ISIDs are comparable to RFC4364 Route distinguishers and 282 route targets to separate VPN traffic in the control plane. VPN 283 routes are exchanged through IS-IS and can be distinguished by the 284 individual ISID they are associated with. In order to form different 285 types of IP VPNs on BEB's, routes can be exported into ISID's or 286 imported from ISID's. 288 This document also defines the following new sub-TLV types that need 289 to be reflected in the IS-IS sub-TLV registry for the SPB ipvpn TLV: 291 Sub-Type Description 292 ------- ------------------------------ 293 1 IPv4 Prefix information 294 2 IPv6 Prefix information 295 3 Reserved 296 4 Reserved 298 The encapsulation is as follows: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length | Sub-TLVs | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3 Sub-TLV model 307 The sub-TLVs are designed to mimic the top level TLVs for IP 308 reachability within the VPN. Allowing for a given VRF to support 309 multiple IP service models within a single VPN-ID. 311 Sub-TLV 1 is similar as the Extended IPv4 TLV 135 and MAY appear 312 multiple times in the same TLV with a data structure consisting of: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | Metric | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Metric | Resv |S| Prefix Ln | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | IPv4 Prefix | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 4 IPv4 sub-TLV 325 Sub-TLV 2 is similar to the IPv6 TLV 236 and MAY appear multiple 326 times in the same TLV with a data structure consisting of: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | Resv |E|S| Prefix Ln | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Metric | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | IPv6 Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | IPv6 Address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 5 IPv6 sub-TLV 341 4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp 343 Shortest Path Bridging supports two major modes for L2VPNs via 344 802.1aq [SPB] and 802.1Qbp [ECMP] the behaviors of which may be 345 selected on a per ISID basis for carriage of L3VPNs as follows. 347 The 802.1aq [SPB] L2 underlay on which IPVPN packets flow, supports 348 deterministic and symmetric multiple equal cost routes with hashing 349 to the different routes at the head end via normal IP n-tuple or 350 other micro flow order preserving hash mechanisms. To obtain this 351 behavior the IPVPN TLV VID field MUST contain a BVID value which has 352 been associated with one of the 802.1aq ECT-ALGORITHMS by the SPB 353 underlay in the SPB Base VLAN-Identifiers sub-TLV. This will cause 354 the ISID information which follows to have 802.1aq semantics - i.e. 355 (S,G) multicast and symmetric/congruent routing. The normal 802.1aq 356 ECT-ALGORITHM values 00-80-C2-01 thru 00-80-C2-10 and their 357 associated VIDs are advertised normally in the IIH and LSPs for 358 802.1aq and the head end IPVPN behavior is free to hash over any or 359 all of those VIDs. 361 The 802.1Qbp [ECMP] extensions to [SPB] supports a flow-tag with a 362 FlowId and TTL resulting in a per hop hashed choice of next hop by L2 363 forwarding. To obtain this behavior the IPVPN TLV VID field MUST 364 contain a BVID value which has been associated with one of the 365 802.1Qbp ECT-ALGORITHMS by the SPB underlay in the SPB Base VLAN- 366 Identifiers sub-TLV. This will cause the ISID information which 367 follows to have 802.1Qbp semantics - i.e. (*,G) and/or (S,G) 368 multicast and non deterministic non symmetric routing. The normal 369 802.1Qbp ECT-ALGORITHM value 00-80-C2-11 and its associated VIDs are 370 advertised normally in the IIH and LSPs for 802.1Qbp and the head end 371 IPVPN behavior is free to hash over all ECMP L2 next hops for this 372 VID and to insert a flow-tag with appropriate TTL value and FlowId 373 based on the L3 hash result. The TTL and FlowId will then be used to 374 enable tandem .1Qbp ECMP behavior without knowledge of or inspection 375 of the L3VPN headers. 377 4.3. I-TAG Encapsulation 379 For the forwarding of IPVPN traffic the use of the standard 802.1ah 380 I-TAG would require the encapsulation of a nulled out CMAC address, 381 since the traffic is IP and routed at each BEB there is no need for a 382 CMAC. Therefore the more optimal encapsulated method used for IPVPN 383 traffic within the SPB network is to use the ISID portion of the I- 384 TAG without a CMAC header, called the short I-TAG. This allows the 385 network to carry forward the benefits of the global label/VPN ID 386 purpose of the ISID without enforcing unnecessary header overhead. 388 The encapsulation of IP packets being forwarded for a IPVPN would use 389 a short I-Tag (ISID with no CMAC) behind the BMAC header. While the 390 short I-TAG is the recommended mode for carrying IPVPN traffic this 391 standard permits the inclusion of a zerod out CMAC. In this case the 392 sender MUST zero out the CMAC on transmission and MUST ignore a non- 393 zero CMAC on receipt. 395 Packets received Packets in transit Packets forwarded 396 at ingress BEB VRF in the network by egress BEB VRF 398 +=============+ 399 | IP Header | 400 +============+ +=============+ +============+ 401 | IP Header | | Short I-TAG | | IP Header | 402 +============+ >>>>> +=============+ >>>>> +============+ 403 | C-MAC | | B-MAC | | C-MAC | 404 +============+ +=============+ +============+ 405 Figure 7 Short I-TAG encapsulation of IPVPN Packets 407 Where the ISID encapsulation is as follows. Directly between the VLAN 408 and IP header. 410 .1ah I-TAG TCI 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | P/DE |R1 |R2 | I-SID | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 9 Short I-Tag 416 P/DE 3 Bits Priority, 1 bit Drop Eligible 417 R1 Res1 418 R2 Res2 420 5. Interworking with MPLS based Networks 422 Any IP/SPB and/or IPVPN SPB network may exist on its own or may be 423 part of a larger network. For example it may be attached to a 424 standard IP or IP/MPLS network. This section will define a use case 425 for using an SPB base network as a method of extending IPVPNs from a 426 IP/MPLS core network. A similar model exists for the ELAN service 427 that may span both a SPB and VPLS portions of the network as defined 428 in [PBBVPLS] The scale and size of the SPB portion of the network and 429 network devices can then be utilized more efficiently as a single 430 protocol will drain less resources and thereby allow the IPVPN VRFs 431 extend closer to the end customer. Another benefit is that packets 432 that are destined within the SPB network can be forwarded directly in 433 the SPB portion of the domain without needing to be processed by the 434 MPLS PE. 436 _,,..--..,,, 437 ,-'` `'-, 438 .` `' 439 ,' `. 440 / , 441 | IP MPLS Core | 442 ` 443 `. ` 444 ', _-` 445 +------/-,, _,-,------+ 446 | ,-,/ | ``'''--'''`` | ,-, | 447 MPLS-PE1 | |VRF| | | |VRF| |MPLS-PE2 448 | | | | BC-PEs | | | | 449 | `|' | | `|' | 450 +-,--,,-+ +--,--,,+ 451 ,' ,' 452 / / 453 | SPB | | SPB | 454 | Network | | Network | 455 | | | | 456 / / 457 `. / `. / 458 +------`-,,+-------+ +-------+'-'+-------+ 459 | ,-, | | ,-, | | ,-, | | ,-, | 460 | |VRF| | | |VRF| | | |VRF| | | |VRF| | 461 | | | | | | | | BEBs | | | | | | | | 462 | `'' | | `'' | | `'' | | `'' | 463 +-------+ +-------+ +-------+ +-------+ 464 BEB1 BEB2 BEB3 BEB4 466 Figure 12 MPLS Interworking 468 A vrf does Service Address Encapsulation on a VPN basis with some 469 entries of the VRF having MPLS labels and some have IPVPN SPB entries 470 based on the direction from which the route was learned. The VRF also 471 gets information from different topologies. Routes learned via BGP 472 have FIB entries pointing to the appropriate next hop and Label set. 473 While routes learned from the IPVPN ISID SPB domain have FDB entries 474 for the appropriate BMAC address and ISID. 476 Route propagation to and from each domain happens naturally via the 477 protocol interaction within a given VRF. Routes learned from the SPB 478 domain are automatically announced into the BGP domain or may have 479 policies applied and routes learned from other PE's from BGP are 480 automatically propagated towards the CE's by injecting them into the 481 SPB domain as a sub-TLV under the VRF's IPVPN ISID TLV. 483 6. OAM 485 Various techniques exist within the Ethernet standards space for 486 scalable management of Ethernet based networks. For example OAM 487 techniques defined in the IEEE 802.ag and the ITU Y.1731 can be used 488 for the IP based services similarly as they are defined for the EVPNs 490 7. Security Considerations 492 The extensions defined in this document do not incur any additional 493 security considerations. Any IS-IS SPB network may utilize the 494 security enhancements already defined within the IS-IS working group. 496 8. IANA Considerations 498 IP/SPB requires that IANA/ISO allocate a new number from ISIS-TLV 499 Codepoints for the IPVPN TLV. 501 IP/SPB also requires that IANA/ISO allocate a new registry for sub 502 TLV values within the above TLV. The first four values being: 1 503 IPV4 2 IPV6 3 reserved 4 reserved 505 9. References 507 9.1 Normative References 509 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [MTISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 513 Topology (MT) Routing in Intermediate System to 514 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 516 [IPVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 517 Networks (VPNs)", RFC 4364, February 2006. 519 [802.1AQ] "IEEE P802.1aq/D4.5 Draft Standard for Local and 520 Metropolitan Area Networks -- Media Access Control (MAC) 521 Bridges and Virtual Bridged Local Area Networks, 522 Amendment 8: Shortest Path Bridging", IEEE 802.1aq D4.5, 523 Feb 6, 2012 525 [802.1AQ] Ashwood-Smith, P, Fedyk, D., "IS-IS Extensions Supporting 526 IEEEE 802.1aq Shortest Path Bridging" RFC 6329, XXX, 2012. 528 9.2 Informative References 530 [IEEE802.1ah] "IEEE Standard for Local and Metropolitan Networks, 531 Virtual Bridged Local Area Networks, Amendment 7: 532 Provider Backbone Bridges" IEEE Std 802.1ah - 2008 533 amendment to IEEE 802.Q - 2005. 535 [ISIS] ISO/IEC 10589:2002, "Intermediate system to Intermediate 536 system routing information exchange protocol," 537 ISO/IEC10589:2002. 539 [PBBVPLS] Extensions to VPLS PE model for Provider Backbone Bridging, 540 IETF, Internet Draft, draft-ietf-l2vpn-pbb-vpls-pe-model- 541 00.txt, Work in Progress, May 12 2009 543 10. Acknowledgments 545 The authors would like to thank Don Fedyk for input into the 546 contents of this document. And also Dave Allan, Nigel Bragg, Gautam 547 Khera, Srikanth Keesara and Harish Sankaran for their detailed review 548 of larger work that is behind this memo. 550 This document was prepared using nroff. 552 Authors' Addresses 554 Paul Unbehagen Jr 555 Avaya 556 1300 W. 120th Avenue 557 Westminster, CO 80234 USA 558 Email: unbehagen@avaya.com 560 Roger Lapuh 561 Avaya 562 Flughofstrasse 54 563 8152 Glattbrugg 564 Switzerland 565 Email: rlapuh@avaya.com 567 Peter Ashwood-Smith 568 Huawei Technologies Canada LTD. 569 303 Terry Fox drive, Suite 400 570 Kanata, Ontario , K2K 2J1, Canada 571 Email: peter.ashwoodsmith@huawei.com 573 Susan Hares 574 Huawei 575 Email: shares@ndzh.com 576 1-734-604-0332