idnits 2.17.1 draft-zhang-bess-label-sharing-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2018) is 2199 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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' ** Downref: Normative reference to an Informational RFC: RFC 6571 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mingui Zhang 2 Intended status: Proposed Standard Peng Zhou 3 Donald Eastlake 4 Huawei 5 Russ White 6 IETF 7 Expires: September 20, 2018 March 21, 2018 9 Label Sharing for Fast PE Protection 10 draft-zhang-bess-label-sharing-00.txt 12 Abstract 14 This document describes a method to be used by VPN (Virtual Private 15 Network) Service Providers to provide multi-homed CEs with fast 16 protection of egress PEs. Egress PEs in a redundant group always 17 share the same label in distribution of VPN routes of a VRF. A 18 virtual Next Hop (vNH) in the IGP/MPLS backbone is created as the 19 common end of LSP tunnels which would otherwise terminate at each 20 egress PE. Primary and backup LSP tunnels ended at the vNH are set up 21 by MPLS on the basis of existing Interior Gateway Protocol (IGP) Fast 22 ReRoute (FRR) mechanisms. If the primary egress PE fails, the backup 23 egress PE can recognize the "shared" VPN route label carried by the 24 data packets. Therefore, the failure affected data packets can be 25 smoothly rerouted to the backup PE for delivery without changing 26 their VPN route label. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the authors or the TRILL working group mailing list: 35 trill@ietf.org. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction............................................3 55 1.1 Overview...............................................3 56 1.3 Terminology............................................4 58 2. The Virtual Next Hop....................................5 59 3. Link Costs Set Up for IGP FRR...........................6 60 4. The LSP Tunnels.........................................8 62 5. The VPN Route Label.....................................9 63 5.1. Sharing the VPN Route Label...........................9 64 5.1.1 Option A: Reserved Label Ranges per RG...............9 65 5.1.2 Option B: The Label Swapping Table..................10 66 5.2 Binding to LSP Tunnels................................10 68 6. Examples To Walk Through...............................11 69 6.1 Label Distribution Procedure..........................11 70 6.2 Protection Procedure..................................11 72 7. Operations.............................................12 73 7.1 Label Space Management for Option A...................12 74 7.2 Backup LSP Tunnel Exceptions..........................12 76 8. Security Considerations................................13 77 9. IANA Considerations....................................13 79 Acknowledgements..........................................13 81 Normative References......................................13 82 Informative References....................................14 84 Appendix A: Generating OSPF LSAs..........................15 85 Appendix B: Generating IS-IS LSPs.........................17 87 Authors' Addresses........................................20 89 1. Introduction 91 For the sake of reliability, ISPs often connect one CE (Customer 92 Edge) device to multiple PE (Provider Edge devices. When the primary 93 egress PE fails, a backup egress PE continues to offer VPN 94 connectivity to the CE. If local repair is performed by the upstream 95 neighbor of the primary egress PE on the data path, it's possible to 96 achieve a 50 msec switchover. 98 VPN (Virtual Private Network) routes learnt from CEs are distributed 99 by egress PEs to ingress PEs that need to know these VPN routes. 100 Egress PEs in a redundant group (RG) MUST advertise the same VPN 101 route label for routes of the same VPN. When the primary egress PE 102 fails, data packets are redirected to a backup egress PE by the PLR 103 (Point of Local Repair) router, the backup PE can recognize the VPN 104 route label in these data packets and deliver them correctly. The 105 method developed in this document is called "Label Sharing for Fast 106 PE Protection". 108 1.1 Overview 110 +====================================+ 111 +---+ | +---+ +--+ +---+ M | 112 |CE1+----+PE1+----+P1+----+PE3+-------+ | 113 +---+ | +-+-+ +-++ +---+ 1100| | 114 | | | | +-+-+ | +---+ 115 | | | | +vNH+----+CE2| 116 | | | | +-+-+ | +---+ 117 +---+ | +-+-+ +-++ +---+ 1100| | 118 |CE3+----+PE2+----+P2+----+PE4+-------+ | 119 +---+ | +---+ +--+ +---+ S | 120 | | 121 | IGP/MPLS Backbone Network | 122 +====================================+ 124 Figure 1.1: Egress PE routers share the same VPN route label 1100 126 An example topology is shown in Figure 1.1. Let PE1 and PE2 be 127 ingress routers, and let PE3 and PE4 be egress routers. CE2 is 128 connected to both PE3 and PE4 so they form an Redundant Group (RG). 129 Usually, egress PEs may be configured to be in the same RG or 130 discover each other from the CE routes learning process which can be 131 a dynamic routing algorithm or a static routing configuration 132 [RFC4364]. Suppose PE3 is the primary while PE4 is the backup. For 133 topologies with more than two egress PEs in an RG, one PE acts as the 134 primary while others act as backups. 136 A vNH (virtual Next Hop) node is created in the backbone. The primary 137 PE allocates a loopback IP address to vNH (say 192.0.2.2). Instead of 138 the egress PEs, vNH acts as the common end node of LSP tunnels which 139 otherwise end at egress PEs. The metrics ('M' and 'S') for the links 140 between egress PEs and vNH is set up in a way that the primary and 141 backup LSP tunnels to vNH respectively use PE3 and PE4 as the 142 penultimate hop. 144 Egress PEs in an RG MUST advertise the same VPN route label for each 145 VPN connected to this RG. When a route is learn from CE2 (say 146 10.9.8/24), PE3 and PE4 will distribute this route to other PEs 147 sharing the same label (say 1100). In this way, when the primary PE 148 fails, the VPN route label carried with the rerouted data packets 149 need not be changed. It can be recognized by the backup PE as well. 151 This document supposes a BGP/MPLS IP VPN [RFC4364] is deployed in the 152 backbone and a Label Distribution Protocol (LDP) is used to 153 distribute MPLS labels. The approach developed in this document 154 confines changes to routers in an RG. Provider and PE routers outside 155 of this RG are totally oblivious to these changes. 157 1.2. Conventions used in this document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119] [RFC8174] 162 when, and only when, they appear in all capitals, as shown here. 164 1.3 Terminology 166 CE: Customer Edge device, e.g., a host or network. 168 FEC: Forwarding Equivalency Class 170 FRR: Fast ReRoute [RFC7812] 172 LFA: Loop-Free Alternate [RFC6571] 174 LSP: Label Switched Path 176 PE: Provider Edge 178 PLR: Point of Local Repair 180 RG: Redundant Group. A Redundant Group of Provider Edge nodes (PEs) 181 to which a set of CEs are multi-homed. 183 VRF: Virtual Routing and Forwarding table [RFC4364] 185 2. The Virtual Next Hop 187 A virtual router (the virtual Next Hop, vNH) is created in IGP to 188 represent the Redundant Group (RG) in the Service Provider's 189 backbone. For other routers in the backbone, the vNH acts as the 190 common egress PE connecting a set of CEs. Multiple vNHs may be 191 created for one RG. Then multiple paths can be computed from ingress 192 PEs to the vNHs. Ingress PEs can choose from these paths to achieve 193 load balance for the CEs. 195 Service Providers may configure one PE to be the primary when an RG 196 is created. The primary PE may also be automatically elected out of 197 the RG in the same way the Designated Routed is selected in OSPF (see 198 section 7.3 of [RFC2328]) or the Designated Intermediate System is 199 selected in [IS-IS]. Other PEs in the RG will act as backup ones. 200 This primary PE determines the loopback IP address for the vNH. This 201 loopback IP address can be configured manually or assigned 202 automatically. The SystemID of the vNH under IS-IS is composed based 203 on this loopback IP address. The primary PE generates the router link 204 state information (LSA/LSP) on behalf of the vNH. Links to each PE 205 and each CE in the group are included in router link state 206 information PDUs of the PE and CE. 208 The overload mode MUST be set so that the rest of the routers in the 209 network will not route transit traffic through the vNH. In OSPF, the 210 overload mode can be set up through setting the link weights from the 211 vNH to egress PEs to the maximum link weight which is 0xFFFF. In IS- 212 IS, this overload mode is realized as setting the overload bit in the 213 LSP of the vNH. (See Appendix A and B for the detail set up of 214 LSAs/LSPs.) 216 3. Link Costs Set Up for IGP FRR 218 |<------ Sxy3-------->| 220 +-------Px(PLR)-------PE3 221 | | \ M 222 | | \ 223 Pxy C34| vNH 224 | | / 225 | | / S 226 +---------------------PE4 228 |<------ Sxy4-------->| 230 Figure 3: Illustration of equations. 232 If the IGP costs for the links between egress PEs and the vNH can be 233 set up in a way that one egress PE appears on the primary path while 234 the other PE appears on the backup path, the PLR can make use of the 235 multiple egress PEs to achieve fast failure protection. Link weights 236 can be set up according to the following rule in order to leverage 237 the well supported LFA [RFC6571] as the IGP (Interior Gateway 238 Protocol) FRR (Fast ReRoute [RFC7812]) mechanism. 240 1. This document supposes bidirectional link weights are being used. 241 As illustrated in Figure 3, assume the weight for the link between 242 PE3 and vNH is "M" and the weight for the link between PE4 and vNH 243 is "S". The weight for the link between PE3 and PE4 is C34. 245 2. Px is a neighbor of PE3. This Px will act as the PLR. Suppose Pxy 246 is Px's neighbor with the shortest path to PE4, after PE3 is 247 removed from the topology. The cost of this path is Sxy4. 249 3. Add PE3 back to the topology. The cost of the path from Pxy to PE3 250 is Sxy3. 252 4. "M" and "S" can be set up as long as the following two equations 253 hold. 255 eq1: Sxy4+S < Sxy3+M 257 eq2: C34+S > M 259 The eq1 guarantees that Pxy is safe to be used as the next hop by 260 the PLR for bypass, i.e., no loop occurs. The eq2 is designed to 261 insure that the primary path does not go through the primary 262 egress PE and backup egress PE in series. 264 Although this document designs the method based on Loop Free 265 Alternative (LFA [RFC6571]) which is widely deployed, other IGP FRR 267 [RFC7812] mechanisms can also be utilized to achieve the protection. 268 For example, maximally redundant trees [RFC7812] can be applicable 269 regardless of how the link weights are set up. 271 4. The LSP Tunnels 273 Egress PEs use the IP address of the vNH to identify the FEC. Its 274 LSPs are set up using LDP on basis of IGP routes with vNH as the last 275 hop: 277 - The primary LSP tunnel follows the IGP route from ingress PEs to 278 the vNH; 280 - The backup LSP tunnel is set up according to existing IGP FRR 281 [RFC7812] calculation, such as maximally redundant trees [RFC7812] 282 or LFA [RFC6571]. 284 Data packets are tunneled through the backbone using a "tunnel label" 285 at the top of the label stack. Egress PEs will not really transmit a 286 packet to the tunnel end node vNH. Rather, they need to locally 287 deliver the packet. It can be interpreted that at the egress PE, the 288 packet's next hop is the egress PE itself (see Section 3.10 of 289 [RFC3031]). The tunnel label will be popped at the egress PE. The 290 tunnel label at the top of the stack indicates popping since this is 291 a label assigned to the FEC identified by the PE's loopback IP 292 address. Next, there will be a pop of the VPN route label followed by 293 an address lookup in the VRF. Section 5 will explain how to set the 294 VPN route label to use these LSP tunnels to achieve the egress PE 295 protection. 297 5. The VPN Route Label 299 5.1. Sharing the VPN Route Label 301 In [RFC4364], egress PEs separately allocate and distribute the label 302 for the route to an address prefix they learn from CEs. In this 303 document, it's REQUIRED that backup PE(s) in an RG always advertises 304 the label already advertised by the primary PE for the address prefix 305 in question. The primary PE RG SHOULD distribute the same label for 306 any address prefix in an attached VPN. This is per VRF label sharing. 307 Others granularities, such as per address family per VRF label 308 sharing, are also feasible. 310 Egress PEs continue to locally allocate VPN route labels so that the 311 proposal need not modify existing forwarding processes of L3VPN 312 egress PEs. At the backup egress PE, the allocated label and the 313 distributed label would be inconsistent. The following two options 314 address this issue. 316 5.1.1 Option A: Reserved Label Ranges per RG 318 PEs in an RG are physically connected to the same set of CEs. It's 319 viable for them to allocate the same VPN route label per VPN. For 320 each VPN served by an RG, the backup egress PE always allocates the 321 same label as the primary PE. It acts as a "compromised" network 322 entity which always listens to the label advertised by the primary 323 then allocates and also distributed the same label. By doing this, 324 they are intimating the VPN route label allocation of the virtual 325 node, vNH. 327 For this option, PEs in an RG are REQUIRED to reserve the same label 328 range(s) for allocation at the management plane. PEs with hardware- 329 set disjoint label ranges are not qualified for this option. This 330 option SHOULD only be used in well managed and highly monitored 331 networks. It's not intended to be applicable when the RG spans more 332 than one administrative domain. It ought not to be deployed on or 333 over the public Internet. 335 Note that if one PE participates in multiple RGs, a label range 336 reserved for one RG can't be used by another RG on this PE. It 337 increases the consumption of labels on this PE. So this option should 338 be deployed with care in that case. 340 The architecture of the label sharing method allows a "higher-layer" 341 entity to allocate labels for all PEs across all RGs. This document 342 leaves this choice for future study. 344 5.1.2 Option B: The Label Swapping Table 346 +----+----+ 347 |1100| 30 | 348 |1101| 31 | 349 |1102| 32 | 350 . . 351 . . 352 . . 353 +----+----+ 355 Figure 5.1.2: The label swapping table 357 In the inter-AS L3VPN Option B defined in Section 10 of [RFC4364], 358 when an ASBR distributes a VPN route to an ASBR in another AS, it 359 needs to perform a label swap for this route. Similarly, the backup 360 PE in this proposal uses a label swapping table to record the mapping 361 between advertised labels and locally assigned labels for VPN routes. 362 Obviously, the backup PE needs to maintain one such table per RG. 363 Whenever a data packet to a route in a VPN attached to the RG arrives 364 at the backup PE, the locally assigned label (e.g., 30) obtained from 365 the swapping will be used in the VPN route label lookup followed by 366 an address lookup. 368 5.2 Binding to LSP Tunnels 370 When the VPN route with a shared label is distributed to other PEs by 371 the primary PE and backup PEs, the BGP next hop is set to the IP 372 address of the vNH. As specified in Section 4, LSP tunnels are set up 373 for the FEC also identified by the IP address of the vNH. By doing 374 this, the VPN route is bound to these LSP tunnels. When data packets 375 to this VPN route are tunneled through the backbone, these LSP 376 tunnels will offer protection. 378 6. Examples To Walk Through 380 Two examples are included in this section using the topology in 381 Figure 1.1. The first one describes how to distribute a VPN route 382 label to peers. It's westbound in the control plane. The second one 383 interprets how an egress PE acts in the case of the primary PE 384 failure. It's eastbound in the data plane. 386 6.1 Label Distribution Procedure 388 Assume PE3 is elected as the primary while PE4 is the backup. The 389 loopback IP address of vNH is 192.0.2.2. 391 1) PE3 learns the VPN route to address prefix 10.9.8/24 from CE2. It 392 allocates the VPN route label 1100 and distributes it in BGP with 393 192.0.2.2 as the BGP Next Hop. (prefix = 10.9.8/24|label = 394 1100|BGP Next Hop = 192.0.2.2) 396 2) PE4 also learns the VPN route to address prefix 10.9.8/24 and 397 allocate the VPN route label 30. It then waits for the primary PE3 398 to advertise the VPN route label for this prefix. 400 3) PE4 monitors the VPN route label 1100 from PE3 for the prefix 401 10.9.8/24. The mapping from 1100 to 30 is inserted to the swapping 402 table. 404 4) PE4 distributes the VPN route using the monitored label 1100. 405 (prefix = 10.9.8/24|label = 1100|BGP Next Hop = 192.0.2.2) 407 6.2 Protection Procedure 409 Suppose the label for the primary LSP tunnel to vNH is 2100 while the 410 backup LSP tunnel to vNH is 3100. P1 is the PLR. 412 1) In normal case, P1 sends data packets with tunnel label 2100 to 413 PE3. When PE3 fails, P1 redirects data packets to the backup LSP 414 tunnel (say P2-PE4-vNH) using tunnel label 3100. 416 2) PE4 will receive a packet with two levels of labels. It pops the 417 outer label 3100 and use this label to identify a swapping table. 419 3) PE4 pops the VPN route label and looks up the swapping table. The 420 VPN route label 1100 is mapped to 30. 422 4) The VPN route label 30 is looked up in the VPN route label table 423 followed by an address lookup in the VRF. 425 7. Operations 427 7.1 Label Space Management for Option A 429 A label range should be reserved before an RG is made operational. 430 Operators need to set a large label sharing space to reserve for 431 label ranges. When an RG is created, the operator needs reserve a 432 unused label range for it. The label range should be reserved in a 433 manner of "enough is enough". If a label range of an RG is becomes 434 exhausted, the operator can reserve a new range from the unused label 435 sharing space. The newly reserved range is then appended to the one 436 being exhausted. 438 If a backup PE is partitioned from the primary PE, it continues to 439 work with those allocated labels for the RG. However, it MUST NOT 440 allocate any more labels in the reserved ranges. A label in a 441 reserved range can only be allocated by a backup PE when it monitors 442 that the primary PE has distributed this label. 444 When a primary PE resumes from a failure, its reserved label ranges 445 are again available to it. It SHOULD conserve the labels it allocated 446 for each range. 448 7.2 Backup LSP Tunnel Exceptions 450 The label sharing method requires that the backup LSP tunnel is set 451 up as specified in Section 4, following the IGP route. However, 452 Service Providers are allowed to have exceptions. For instance, an 453 operator may use BGP Local_Pref to give a higher degree of preference 454 to the route advertised by the primary PE. For another instance, the 455 operator may have the primary PE advertise a more specific prefix. 456 In Figure 1.1, for example, the backup tunnel actually goes through 457 PE4->PE3->CE2 for both instances. When the VPN route is bound to this 458 tunnel, it does not protect the primary egress PE. An alarm should be 459 generated to notify the operator that such configuration will 460 jeopardize the VPN route's resilience to egress PE node failure. 462 8. Security Considerations 464 TBD 466 9. IANA Considerations 468 This document requires no IANA actions. RFC Editor: please remove 469 this section before publication. 471 Acknowledgements 473 Authors would like to thank the comments and suggestions from Bruno 474 Decraene, Eric Rosen, Eric Gray, Jakob Heitz, James Uttaro, Jeff 475 Tantsura, Loa Andersson, Nagendra Kumar, Robert Raszuk, Stewart 476 Bryant, Shunwan Zhuang, Wim Henderickx, and Zhenbin Li. 478 Normative References 480 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 481 information exchange protocol for use in conjunction with 482 the Protocol for providing the Connectionless-mode Network 483 Service (ISO 8473)," ISO/IEC 10589:2002. 485 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 486 for Network Management of TCP/IP-based internets:MIB-II", 487 STD 17, RFC 1213, March 1991. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, DOI 491 10.17487/RFC2119, March 1997, . 494 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 495 10.17487/RFC2328, April 1998, . 498 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 499 Label Switching Architecture", RFC 3031, DOI 500 10.17487/RFC3031, January 2001, . 503 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 504 Networks (VPNs)", RFC 4364, February 2006. 506 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 507 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, 508 . 510 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 511 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 512 Alternate (LFA) Applicability in Service Provider (SP) 513 Networks", RFC 6571, June 2012. 515 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 516 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 517 2017, . 519 Informative References 521 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 522 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 523 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 524 . 526 Appendix A: Generating OSPF LSAs 528 The following Type 1 Router-LSA is flooded by the egress PE with the 529 highest priority. As specified in [RFC2328], this LSA can only be 530 flooded throughout a single area. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | LS age | Options | LS type | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Link State ID | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Advertising Router | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | LS sequence number | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | LS checksum | length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | 0 |V|E|B| 0 | # links | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Link ID | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Link Data | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | # TOS | metric | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | ... | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | TOS | 0 | TOS metric | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Link ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Link Data | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ... | 563 LS age 564 The time in seconds since the LSA was originated. (Set to 0x708 565 (a half an hour) by default.) 567 Options 568 As defined in [RFC2328], options = (E-bit). 570 LS type 571 1 573 Link State ID 574 Same as the Advertising Router 576 Advertising Router 577 The Router ID of the vNH. 579 LS sequence number 580 As defined in [RFC2328]. 582 LS checksum 583 As defined and computed in [RFC2328]. 585 length 586 The length in bytes of the LSA. This includes the 20 byte LSA 587 header. (As defined and computed in [RFC2328].) 589 VEB 590 As defined in [RFC2328], set its value to 000. 592 #links 593 The number of router links described in this LSA. It equals to 594 the number of Egress PEs in the RG. 596 The following fields are used to describe each router link 597 connected to an egress PE. Each router link is typed as Type 1 598 Point-to-point connection to another router. 600 Link ID 601 The Router ID of one of the egress PEs in the RG. 603 Link Data 604 It specifies the interface's MIB-II [RFC1213] ifIndex value. It 605 ranges between 1 and the value of ifNumber. The ifNumber equals 606 to the number of the PEs in the RG. The PE with the highest 607 priority sorts the PEs according to their unsigned integer 608 Router ID in the ascend order and assigns the ifIndex for each. 610 Type 611 Value 1 is used, indicating the router link is a point-to-point 612 connection to another router. 614 # TOS 615 This field is set to 0 for this version. 617 Metric 618 It is set to 0xFFFF. 620 The fields used here to describe the virtual router links are also 621 included in the Router-LSA of each egress PEs. The Link ID is 622 replaced with the Router ID of the vNH. The Link Data specifies the 623 interface's MIB-II [RFC1213] ifIndex value. The "Metric" field is set 624 as defined in Section 3. 626 Appendix B: Generating IS-IS LSPs 628 The primary egress PE generates the following level 1 LSP to describe 629 the vNH node. 631 No. of octets 632 +-------------------------+ 633 | Intradomain Routeing | 1 634 | Protocol Discriminator | 635 +-------------------------+ 636 | Length Indicator | 1 637 +-------------------------+ 638 | Version/Protocol ID | 1 639 | Extension | 640 +-------------------------+ 641 | ID Length | 1 642 +-------------------------+ 643 |R|R|R| PDU Type | 1 644 +-------------------------+ 645 | Version | 1 646 +-------------------------+ 647 | Reserved | 1 648 +-------------------------+ 649 | Maximum Area Address | 1 650 +-------------------------+ 651 | PDU Length | 2 652 +-------------------------+ 653 | Remaining Lifetime | 2 654 +-------------------------+ 655 | LSP ID | ID Length + 2 656 +-------------------------+ 657 | Sequence Number | 4 658 +-------------------------+ 659 | Checksum | 2 660 +-------------------------+ 661 |P|ATT|LSPDBOL|IS Type | 1 662 +-------------------------+ 663 : Variable Length Fields : Variable 664 +-------------------------+ 666 Intradomain Routeing Protocol Discriminator - 0x83 (as specified in 667 [IS-IS]) 669 Length Indicator - Length of the Fixed Header in octets 671 Version/Protocol ID Extension - 1 673 ID Length - As defined in [IS-IS] 675 PDU Type (bits 1 through 5) - 18 676 Version - 1 678 Reserved - transmitted as zero, ignored on receipt 680 Maximum Area Address - same as the primary egress PE 682 PDU Length - Entire Length of this PDU, in octets, including the 683 header. 685 Remaining Lifetime - Number of seconds before this LSP is considered 686 expired. (Set to 0x384 (fifteen minutes) by default.) 688 LSP ID - the system ID of the source of the LSP. It is structured as 689 follows: 691 +-------------------------+ 692 | Source ID | 6 693 +-------------------------+ 694 | Pseudonode ID | 1 695 +-------------------------+ 696 | LSP Number | 1 697 +-------------------------+ 699 Source ID - SystemID of the vNH 701 Pseudonode ID - Transmitted as zero 703 LSP Number - Fragment number 705 Sequence Number - sequence number of this LSP (as defined in [IS-IS]) 707 Checksum - As defined and computed in [IS-IS] 709 P - Bit 8 - 0 711 ATT - Bit 7-4 - 0 713 LSDBOL - Bit 3 - 1 715 IS Type - Bit 1 and 2 - bit 1 set, indicating the vNH is a Level 1 716 Intermediate System 718 In the Variable Length Field, each link outgoing from the vNH to an 719 egress PE is depicted by a Type #22 Extended Intermediate System 720 Neighbors TLV [RFC5305]. The egress PE is identified by the 6 octets 721 SystemID plus one octet of all-zero pseudonode number. The 3 octets 722 metric is set as that in Section 3. No sub-TLVs are used by this 723 version, therefore the value of the one octet length of sub-TLVs is 724 0. The Type #22 TLV requires 11 octets. 726 The Type #22 TLV is also included in the LSP of each egress PE to 727 depict the incoming link of the vNH but in this case the 6 octets 728 SystemID is replaced with the SystemID of the vNH. 730 Authors' Addresses 732 Mingui Zhang 733 Huawei Technologies 734 No.156 Beiqing Rd. Haidian District, 735 Beijing 100095 P.R. China 737 Email: zhangmingui@huawei.com 739 Peng Zhou 740 Huawei Technologies 741 No.156 Beiqing Rd. Haidian District, 742 Beijing 100095 P.R. China 744 Email: Jewpon.zhou@huawei.com 746 Donald Eastlake, 3rd 747 Huawei Technologies 748 155 Beaver Street 749 Milford, MA 01757 USA 751 Email: d3e3e3@gmail.com 753 Russ White 754 Verisign 755 12061 Bluemont Way 756 Reston, VA 20190 757 USA 759 Email: russ@riw.us 761 Copyright, Disclaimer, and Additional IPR Provisions 763 Copyright (c) 2018 IETF Trust and the persons identified as the 764 document authors. All rights reserved. 766 This document is subject to BCP 78 and the IETF Trust's Legal 767 Provisions Relating to IETF Documents 768 (http://trustee.ietf.org/license-info) in effect on the date of 769 publication of this document. Please review these documents 770 carefully, as they describe your rights and restrictions with respect 771 to this document. Code Components extracted from this document must 772 include Simplified BSD License text as described in Section 4.e of 773 the Trust Legal Provisions and are provided without warranty as 774 described in the Simplified BSD License.