idnits 2.17.1 draft-ietf-lsr-ospf-prefix-originator-05.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 (November 25, 2019) is 1612 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) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-12 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track A. Lindem 5 Expires: May 28, 2020 Cisco Systems 6 J. Dong 7 Huawei Technologies 8 P. Psenak 9 K. Talaulikar 10 Cisco Systems 11 November 25, 2019 13 OSPF Prefix Originator Extension 14 draft-ietf-lsr-ospf-prefix-originator-05 16 Abstract 18 This document defines Open Shortest Path First (OSPF) encodings to 19 advertise the router-id of the originator of inter-area prefixes for 20 OSPFv2 and OSPFv3 Link-State Advertisements (LSAs). The source 21 originator is needed in several multi-area OSPF use cases. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 28, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Inter-Area Prefix Source Advertisement Use Cases . . . . . . 4 61 5. External Prefix Source Advertisement Use Cases . . . . . . . 5 62 6. Prefix Source Router-ID sub-TLV . . . . . . . . . . . . . . . 6 63 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Inter-Area Prefixes . . . . . . . . . . . . . . . . . . . 7 65 7.2. External Prefixes . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 11.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 10 73 Appendix B. Special Considerations on Inter-Area Topology 74 Retrieval . . . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 [I-D.ietf-ospf-mpls-elc] defines mechanisms to advertise Entropy 80 Readable Label Depth (ERLD) for ingress Label Switching Routers (LSR) 81 to discover other LSR's capability of performing Entropy Label based 82 load-balancing in MPLS networks. The ingress LSR can use this 83 information to construct the appropriate label stack for specific 84 traffic requirements, especially in segment routed networks and other 85 deployments requiring stacked LSPs. 87 However, in inter-area scenarios, the Area Border Router (ABR) does 88 not advertise the originating OSPF router-id for inter-area prefixes. 89 An OSPF router in one area doesn't know the origin area of inter-area 90 prefixes and can't determine the router that originated these 91 prefixes or the ERLD capabilities of the destination. Therefore, it 92 is necessary to advertise the originator of these inter-area prefixes 93 to ensure the ingress LSR can construct the appropriate label stack. 95 More generally, [RFC8476] defines a mechanism to advertise multiple 96 types of supported Maximum SID Depths (MSD) at node and/or link 97 granularity. This information will be referred when the head-end 98 router starts to send traffic to destination prefixes. In inter-area 99 scenario, it is also necessary for the sender to learn the 100 capabilities of the receivers associated with the inter-area 101 prefixes. 103 There is another scenario where knowing the originator of inter-area 104 prefixes is useful. For example, Border Gateway Protocol Link-State 105 (BGP-LS) [RFC7752] describes mechanisms using the BGP protocol to 106 advertise Link-State information. This information can enable a 107 Software Definition Network (SDN) controller to automatically 108 determine the underlay network topology. 110 However, if the underlay network is partitioned into multiple areas 111 and running the OSPF protocol, it is not easy for the SDN controller 112 to rebuild the multi-area topology since ABR that connects multiple 113 areas will normally hide the detailed topology for these non-backbone 114 areas. If only the internal routers within backbone area run the 115 BGP-LS protocol, they just learn and report the summary network 116 information from the non-backbone areas. If the SDN controller can 117 learn the originator of the inter-area prefixes, it is possible to 118 rebuild the inter-area topology. 120 [RFC7794] introduces the Intermediate System to Intermediate System 121 (IS-IS) "IPv4/IPv6 Source Router IDs" Type-Length-Value (TLV) to 122 advertise the source of prefixes leaked from a different IS-IS level. 123 This TLV can be used in the above scenarios. Such solution can also 124 be applied in networks that run the OSPF protocol, but existing OSPF 125 LSAs TLVs must be extended to include the router originating the 126 prefix. 128 This draft provides such solution for the OSPFv2 [RFC2328] and OSPFv3 129 [RFC5340] protocols. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. Terminology 141 The following terms are used in this document: 143 o ABR: Area Border Router 144 o ASBR: Autonomous System Border Router 146 o ERLD: Entropy Readable Label Depth 148 o EL: Entropy Label 150 o IS-IS: Intermediate System to Intermediate System 152 o LSA: Link-State Advertisement 154 o MSD: Maximum SID Depths 156 o NLRI: Network Layer Reachability Information 158 o OSPF: Open Shortest Path First 160 o SID: Segment IDentifier 162 o SDN: Software Definition Network 164 4. Inter-Area Prefix Source Advertisement Use Cases 166 Figure 1 illustrates a topology where OSPF is running in multiple 167 areas. R0-R4 are routers in the backbone area, S1-S4 are internal 168 routers in area 1, and T1-T4 are internal routers in area 2. R1 and 169 R3 are ABRs between area 0 and area 1. R2 and R4 are ABRs between 170 area 0 and area 2. N1 is the network between router S1 and S2 and N2 171 is the network between router T1 and T2. Ls1 is the loopback address 172 of Node S1 and Lt1 is the loopback address of Node T1. 174 +-----------------+ 175 |IP SDN Controller| 176 +--------+--------+ 177 | 178 | BGP-LS 179 | 180 +---------------------+------+--------+-----+--------------+ 181 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 182 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 183 | +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++| 184 | | | | | || | | 185 | | | | | || | | 186 | +-++ +-++ ++-+ +-++ ++++ +-++| 187 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 188 | +--+ +--+ ++-+ +-++ ++-+ +--+| 189 | | | | 190 | | | | 191 | Area 1 | Area 0 | Area 2 | 192 +---------------------+---------------+--------------------+ 194 Figure 1: OSPF Inter-Area Prefix Originator Scenario 196 If S1 wants to send traffic to prefix Lt1 that is connected to T1 in 197 another area, it should know the ERLD and MSD values associated with 198 the node T1, and then construct the right label stack at the ingress 199 node for traffic destined to prefix Lt1. 201 In another scenario, If R0 has some method to learn the originator of 202 network N1 and reports such information to IP SDN controller, then it 203 is possible for the controller to reconstruct the topology in the 204 non-backbone areas. The topology reconstruction process and its 205 limitations are described in the Appendix A and Appendix B. 207 5. External Prefix Source Advertisement Use Cases 209 Figure 2 illustrates a topology where OSPF is running in different 210 domain that is connected by an Autonomous System Border Router 211 (ASBR). A, B, and C are routers in the Domain 1; C, D, and E are 212 routers in Domain 2. Router C is the ASBR between the two domains. 214 When router E receives an external prefix, it will redistribute it as 215 an AS-External LSA within domain 2. When C receives such LSA, the 216 originator information for such external prefix will be lost when it 217 encodes the prefix information with the current LSA format field. In 218 some situations, it will be helpful if C can advertise such 219 originator information. 221 +-------------------------------------------------------------------+ 222 | | External Prefix | 223 | +---+ +---+ +---+ +---+ +-|-+ | 224 | | A +-------+ B +----------| C +---------+ D +---------+ E |------| 225 | +---+ +---+ +---+ +---+ +---+ | 226 | Domain 1 | Domain 2 | 227 +-------------------------------------------------------------------+ 229 Figure 2: OSPF External Prefix Originator Scenario 231 From the above scenarios, we can conclude that it is useful to define 232 the OSPF prefix originator sub TLV . 234 6. Prefix Source Router-ID sub-TLV 236 [RFC7684] and [RFC8362] respectively define TLV-based LSAs for OSPFv2 237 and OSPFv3. These documents facilitate addition of new attributes 238 for prefixes and provide the basis for a sub-TLV to advertise the 239 "Prefix Source Router ID". For OSPFv2, this sub-TLV is a sub-TLV of 240 OSPFv2 Extended Prefix TLV which SHOULD be included in the "OSPFv2 241 Extended Prefix Opaque LSA" [RFC7684] for inter-area prefixes. For 242 OSPFv3, this sub-TLV is a sub-TLV of "Inter-Area-Prefix TLV", which 243 SHOULD be included in the "E-Inter-Area-Prefix-LSA" [RFC8362]. 245 The "Prefix Source Router-ID" sub-TLV has the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Prefix Source Router-ID | 253 +---------------------------------------------------------------+ 254 Figure 3: Prefix Source Router-ID sub-TLV Format 256 o Source Router-ID Sub-TLV Type: 4 (IANA TEMPORARY allocation) 257 [RFC7684] or 27 (IANA TEMPORARY allocation) [RFC8362] 259 o Length: 4 261 o Value: Router-ID of OSPFv2/OSPFv3 router that is the source of the 262 prefix. 264 This sub-TLV provides the same functionality as the IS-IS "IPv4/IPv6 265 Source Router" TLV defined in [RFC7794]. 267 7. Elements of Procedure 269 The following sections describe the procedure to include the newly 270 defined "Source Router-ID Sub-TLV" in the related LSA for inter-area 271 prefixes and external prefixes respectively. 273 7.1. Inter-Area Prefixes 275 When an ABR, for example R2 in Figure 1, receives a Router-LSA 276 advertisement in area 2, it SHOULD originate the corresponding 277 "OSPFv2 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area- 278 Prefix-LSA" for OSPFv3 that includes the Source Router-ID sub-TLV for 279 the network prefixes. For example, to identify the source router 280 prefix Lt1 and other inter-area prefixes in Figure 1. 282 When a router in another area, e.g., S1, receives such LSA, it then 283 can ascertain that prefix Lt1 is associated with node T1 and obtain 284 the ERLD or MSD value from T1's Router-Information LSA [RFC7770] and 285 construct the right label stack at the ingress node S1 for traffic 286 destined to prefix Lt1. 288 When a router in another area, e.g., R0, receives such LSA, it learns 289 the Prefix Source Router-id and includes it in the prefix information 290 advertised to an SDN controller as described in 291 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN controller can 292 then use such information to build the inter-area topology according 293 to the process described in the Appendix A. The topology retrieval 294 process may not suitable for some environments as stated in 295 Appendix B. 297 7.2. External Prefixes 299 When an ASBR, for example C in Figure 2, receives an AS-External LSA 300 for an external prefix in domain 2, it SHOULD extract the originator 301 information from the "Advertising Router" field from the LSA header. 302 When the prefix is advertised into domain 1 as an AS-External LSA, 303 router C may also advertise the Source Router-ID using a AS-scoped 304 OSPFv2 Extended Prefix Opaque LSA or as a Sub-TLV in the OSPFv3 AS- 305 External LSA. 307 8. Security Considerations 309 Since this document extends the "OSPFv2 Extended Prefix LSA" and 310 "OSPFv3 E-Inter-Area-Prefix LSA", the security considerations for 311 [RFC7684] and [RFC8362] are applicable. 313 Modification of the "Prefix Source Sub-TLV" could be used for a 314 Denial-of-Service attack and could inhibit the use cases described in 315 Section 4. If the OSPF domain is vulnerable to such attacks, OSPF 316 authentication should be used as defined for OSPFv2 in [RFC5709] and 317 [RFC7474] and for OSPFv3 in [RFC7166]. 319 Additionally, advertisement of the prefix source for inter-area 320 prefixes facilitates reconstruction of the OSPF topology for other 321 areas. Network operators may consider their topologies to be 322 sensitive confidential data. For OSPFv3, IPsec can be used to 323 provide confidentiality [RFC4552]. Since there is no standard 324 defined for native OSPFv2 IPsec, some form of secure tunnel is 325 required to provide confidentiality. 327 9. IANA Considerations 329 This specification defines the Prefix Source Router-ID sub-TLV as 330 described in Section 6. This value should be added to the both 331 existing "OSPFv2 Extended Prefix TLV Sub-TLVs" and "OSPFv3 Extended- 332 LSA Sub-TLVs" registries. 334 The following sub-TLV is added to the "OSPFv2 Extended Prefix TLV 335 Sub-TLVs" registry. The allocation policy is IETF Review as defined 336 in [RFC7684] 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Code Point | Description | Status | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | 4 | Prefix Source Sub-TLV | Allocation from IANA | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: Code Point in "OSPFv2 Extended Prefix TLV Sub-TLVs" 345 The following sub-TLV is added to the "OSPFv3 Extended-LSA Sub-TLVs" 346 registry. The allocation policy is IETF Review as defined in 347 [RFC8362] 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Code Point | Description | Status | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | 27 | Prefix Source Sub-TLV | Allocation from IANA | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 5: Code Point in "OSPFv3 Extended-LSA Sub-TLVs" 356 10. Acknowledgement 358 Many thanks to Les Ginsberg for his suggestions on this draft. Also 359 thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals 360 Dirk, Smita Selot, Shaofu Peng, and John E Drake for their valuable 361 comments. 363 11. References 365 11.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 373 DOI 10.17487/RFC2328, April 1998, 374 . 376 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 377 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 378 . 380 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 381 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 382 . 384 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 385 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 386 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 387 2009, . 389 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 390 Authentication Trailer for OSPFv3", RFC 7166, 391 DOI 10.17487/RFC7166, March 2014, 392 . 394 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 395 "Security Extension for OSPFv2 When Using Manual Key 396 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 397 . 399 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 400 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 401 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 402 2015, . 404 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 405 S. Shaffer, "Extensions to OSPF for Advertising Optional 406 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 407 February 2016, . 409 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 410 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 411 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 412 March 2016, . 414 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 415 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 416 May 2017, . 418 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 419 F. Baker, "OSPFv3 Link State Advertisement (LSA) 420 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 421 2018, . 423 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 424 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 425 DOI 10.17487/RFC8476, December 2018, 426 . 428 11.2. Informative References 430 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 431 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 432 and M. Chen, "BGP Link-State extensions for Segment 433 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 434 (work in progress), June 2019. 436 [I-D.ietf-ospf-mpls-elc] 437 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 438 and M. Bocci, "Signaling Entropy Label Capability and 439 Entropy Readable Label-stack Depth Using OSPF", draft- 440 ietf-ospf-mpls-elc-12 (work in progress), October 2019. 442 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 443 S. Ray, "North-Bound Distribution of Link-State and 444 Traffic Engineering (TE) Information Using BGP", RFC 7752, 445 DOI 10.17487/RFC7752, March 2016, 446 . 448 Appendix A. Inter-Area Topology Retrieval Process 450 When an IP SDN Controller receives BGP-LS [RFC7752] information, it 451 should compare the prefix Network Layer Reachability Information 452 (NLRI) that is included in the BGP-LS NLRI. When it encounters the 453 same prefix but with different source router ID, it should extract 454 the corresponding area-ID, rebuild the link between these two source 455 routers in the non-backbone area. Below is one example that based on 456 the Figure 1: 458 Assuming we want to rebuild the connection between router S1 and 459 router S2 located in area 1: 461 a. Normally, router S1 will advertise prefix N1 within its router- 462 LSA. 464 b. When this router-LSA reaches the ABR router R1, it will convert 465 it into summary-LSA, add the Prefix Source Router-ID sub-TLV, 466 which is router id of S1 in this example. 468 c. R1 then floods this extension summary-LSA to R0, which is using 469 the BGP-LS protocol with IP SDN Controller. The controller then 470 knows the prefix for N1 is from S1. 472 d. Router S2 will perform a similar process, and the controller will 473 also learn that prefix N1 is also from S2. 475 e. Then it can reconstruct the link between S1 and S2, using the 476 prefix N1. The topology within Area 1 can then be reconstructed 477 accordingly. 479 Iterating the above process continuously, the IP SDN controller can 480 retrieve a detailed topology that spans multiple areas. 482 Appendix B. Special Considerations on Inter-Area Topology Retrieval 484 The above topology retrieval process can be applied in the case where 485 each point-to-point or multi-access link connecting routers is 486 assigned a unique prefix. However, there are some situations where 487 this heuristic cannot be applied. Specifically, the cases where the 488 link is unnumbered or the prefix corresponding to the link is an 489 anycast prefix. 491 The Appendix A heuristic to rebuild the topology can normally be used 492 if all links are numbered. For anycast prefixes, if it corresponds 493 to the loopback interface and has a host prefix length, i.e., 32 for 494 IPv4 prefixes and 128 for IPv6 prefixes, Appendix A can also applied 495 since these anycast prefixes are not required to reconstruct the 496 topology. 498 Authors' Addresses 499 Aijun Wang 500 China Telecom 501 Beiqijia Town, Changping District 502 Beijing 102209 503 China 505 Email: wangaj3@chinatelecom.cn 507 Acee Lindem 508 Cisco Systems 509 301 Midenhall Way 510 Cary, NC 27513 511 USA 513 Email: acee@cisco.com 515 Jie Dong 516 Huawei Technologies 517 Beijing 518 China 520 Email: jie.dong@huawei.com 522 Peter Psenak 523 Cisco Systems 524 Pribinova Street 10 525 Bratislava, Eurovea Centre, Central 3 81109 526 Slovakia 528 Email: ppsenak@cisco.com 530 Ketan Talaulikar 531 Cisco Systems 532 S.No. 154/6, Phase I, Hinjawadi 533 Pune 411 057 534 India 536 Email: ketant@cisco.com