idnits 2.17.1 draft-dunbar-lsr-5g-edge-compute-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 15, 2022) is 833 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LSR-FlexAlgo' is mentioned on line 135, but not defined == Missing Reference: 'A-ER' is mentioned on line 202, but not defined == Missing Reference: 'RFC8174' is mentioned on line 259, but not defined == Missing Reference: 'RFC8362' is mentioned on line 332, but not defined == Missing Reference: 'RFC5305' is mentioned on line 346, but not defined == Missing Reference: 'RFC5308' is mentioned on line 347, but not defined == Missing Reference: 'RFC5120' is mentioned on line 351, but not defined == Missing Reference: 'RFC8920' is mentioned on line 381, but not defined ** Obsolete undefined reference: RFC 8920 (Obsoleted by RFC 9492) == Missing Reference: '5GC' is mentioned on line 482, but not defined == Unused Reference: 'RFC2328' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC8326' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC9012' is defined on line 434, but no explicit reference was found in the text == Unused Reference: '3GPP-EdgeComputing' is defined on line 441, but no explicit reference was found in the text == Unused Reference: '5G-StickyService' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'LSR-Flex-Algo-BW' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'SDWAN-EDGE-Discovery' is defined on line 465, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 5521 ** Downref: Normative reference to an Proposed Standard RFC: RFC 7684 ** Downref: Normative reference to an Proposed Standard RFC: RFC 8362 (ref. 'RFC8326') ** Downref: Normative reference to an Proposed Standard RFC: RFC 9012 -- No information found for draft-dunbar-6man-5g-ec-sticky-service - is the name correct? == Outdated reference: A later version (-14) exists of draft-dunbar-idr-5g-edge-compute-app-meta-data-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 == Outdated reference: A later version (-10) exists of draft-ietf-lsr-flex-algo-bw-con-01 == Outdated reference: A later version (-04) exists of draft-dunbar-idr-sdwan-edge-discovery-00 Summary: 5 errors (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft H. Chen 3 Intended status: Standard Futurewei 4 Expires: July 15, 2022 Aijun Wang 5 China Telecom 6 January 15, 2022 8 IGP Extension for 5G Edge Computing Service 9 draft-dunbar-lsr-5g-edge-compute-04 11 Abstract 12 This draft describes using additional site-costs and 13 preference related metrics to influence the SPF and using 14 Flexible Algorithms to indicate the constraints. The 15 purpose is to differentiate multiple paths with similar 16 routing distance to one destination in 5G Local Data 17 Network (LDN)to achieve optimal performance. 19 Status of this Memo 20 This Internet-Draft is submitted in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 This Internet-Draft is submitted in full conformance with 24 the provisions of BCP 78 and BCP 79. This document may not 25 be modified, and derivative works of it may not be created, 26 except to publish it as an RFC and to translate it into 27 languages other than English. 29 Internet-Drafts are working documents of the Internet 30 Engineering Task Force (IETF), its areas, and its working 31 groups. Note that other groups may also distribute working 32 documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of 35 six months and may be updated, replaced, or obsoleted by 36 other documents at any time. It is inappropriate to use 37 Internet-Drafts as reference material or to cite them other 38 than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 Internet-Draft LSR Extension for 5G EC Service 45 The list of Internet-Draft Shadow Directories can be 46 accessed at http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on April 7, 2021. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as 53 the document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's 56 Legal Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the 58 date of publication of this document. Please review these 59 documents carefully, as they describe your rights and 60 restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD 62 License text as described in Section 4.e of the Trust Legal 63 Provisions and are provided without warranty as described 64 in the Simplified BSD License. 66 Table of Contents 68 1. Introduction........................................... 3 69 1.1. Unbalanced Distribution due to UE Mobility........ 4 70 1.2. ANYCAST in 5G EC Environment...................... 4 71 1.3. Scope of the Document............................. 5 73 2. Conventions used in this document...................... 5 75 3. Solution Overview...................................... 6 77 4. New Flags added to FAD Flags Sub-TLV................... 7 79 5. Characteristics of the Site Cost Metric................ 7 81 6. "Site-Cost" Advertisement in OSPF...................... 8 83 7. "Site-Cost" Advertisement in IS-IS..................... 8 85 Internet-Draft LSR Extension for 5G EC Service 87 8. Alternative method for Distributing Aggregated Cost.... 9 89 9. Manageability Considerations........................... 9 91 10. Security Considerations............................... 9 93 11. IANA Considerations................................... 9 95 12. References........................................... 10 96 12.1. Normative References............................ 10 97 12.2. Informative References.......................... 11 99 13. Appendix:5G Edge Computing Background................ 12 101 14. 5G EC LDN Characteristics for the Constraint SPF. Error! 102 Bookmark not defined. 103 14.1. IP Layer Metrics to Gauge EC Server Running Status 104 ...................................................... 13 105 14.2. App Metrics Constrained Shortest Path First. Error! 106 Bookmark not defined. 107 14.3. Reason for using IGP Based Solution............. 14 108 14.4. Flow Affinity to an ANYCAST server.............. 15 110 15. Acknowledgments...................................... 15 112 1. Introduction 114 In 5G Edge Computing (EC) environment, it is common for an 115 application that needs low latency to be instantiated on 116 multiple servers close in proximity to UEs (User 117 Equipment). Those applications instances can be behind one 118 or multiple application-layer load balancers. When they 119 have relatively short flows that can go to any instance, 120 having the cluster of them at different locations share the 121 same IP address can minimize the impact to DNS and achieve 122 optimal forwarding that leverages network conditions. E.g., 123 Kubernetes for data center networking uses one single 124 Virtual IP address for a cluster of instances of 125 microservices so that the network can forward via multiple 126 paths towards one single destination. 128 Internet-Draft LSR Extension for 5G EC Service 130 This draft describes using additional site costs to 131 influence the shortest path computation for a specific set 132 of prefixes. As there are a small number of egress routers 133 having those prefixes (or destinations) that need to 134 incorporate site costs in SPF computation, Flexible 135 Algorithms [LSR-FlexAlgo] is used to indicate the need for 136 the site costs to be considered for the specific 137 topologies. Flexible algorithms provide mechanisms for 138 topologies to use different IGP path algorithms. 140 1.1. Unbalanced Distribution due to UE Mobility 142 UEs' frequent moving from one 5G site to another can make 143 it difficult to plan where the App Servers should be 144 hosted. When a group of App servers at one location, which 145 can be behind an application-layer load balancer, are 146 heavily utilized, the instances for the same application at 147 another location can be under-utilized. The difference in 148 the routing distance to reach multiple sites where the 149 application instances are instantiated might be relatively 150 small in 5G LDN environment. The site capacity and 151 preferences can be more significant than the routing 152 distance from the application's latency and performance 153 perspective. 155 Since the condition can change in days or weeks, it is 156 difficult for the application controller to anticipate the 157 moving and adjusting relocation of application instances. 159 1.2. ANYCAST in 5G EC Environment 161 ANYCAST is assigning the same IP address for multiple 162 instances at different locations. Using ANYCAST can 163 eliminate the single point of failure and bottleneck at 164 load balancers or DNS. Another benefit is removing the 165 dependency on how UEs resolve IP addresses for their 166 applications. Some UEs (or clients) might use stale cached 167 IP addresses for an extended period. 169 But having the same IP address at multiple locations of the 170 5G Edge Computing environment can be problematic because 171 all those locations can be close in proximity. There might 172 be a tiny difference in the routing distance to reach an 173 application instance attached to a different edge router. 175 Internet-Draft LSR Extension for 5G EC Service 177 1.3. Scope of the Document 179 The draft is for scenarios where applications or micro 180 services are instantiated at multiple locations behind 181 multiple application layer load balancers. They have 182 relative short flows that can go to any instances. 184 Under this scenario, multiple instances for the same type 185 of services can be assigned with the same IP address, so 186 that network condition can be utilized to achieve optimal 187 forwarding. 189 From IP network perspective, application layer load 190 balancers and app servers all appear as IP addresses. 191 Throughout this document, the term "app server" can 192 represent the load balancer in front of a cluster of app 193 server instances, app server instances, or app server. 195 Note: for the ease of description, the EC (Edge Computing) 196 server, Application server, App server are used 197 interchangeably throughout this document. 199 2. Conventions used in this document 201 A-ER: Egress Edge Router to an Application Server, 202 [A-ER] is used to describe the last router that 203 the Application Server is attached. For 5G EC 204 environment, the A-ER can be the gateway router 205 to a (mini) Edge Computing Data Center. 207 Application Server: An application server is a physical or 208 virtual server that hosts the software system 209 for the application. 211 Application Server Location: Represent a cluster of servers 212 at one location serving the same Application. 213 One application may have a Layer 7 Load 214 balancer, whose address(es) are reachable from 215 an external IP network, in front of a set of 216 application servers. From IP network 217 perspective, this whole group of servers is 218 considered as the Application server at the 219 location. 221 Internet-Draft LSR Extension for 5G EC Service 223 Edge Application Server: used interchangeably with 224 Application Server throughout this document. 226 EC: Edge Computing 228 Edge Hosting Environment: An environment providing the 229 support required for Edge Application Server's 230 execution. 232 NOTE: The above terminologies are the same as 233 those used in 3GPP TR 23.758 235 Edge DC: Edge Data Center, which provides the Edge 236 Computing Hosting Environment. It might be co- 237 located with 5G Base Station and not only host 238 5G core functions, but also host frequently 239 used Edge server instances. 241 gNB next generation Node B 243 LDN: Local Data Network 245 PSA: PDU Session Anchor (UPF) 247 SSC: Session and Service Continuity 249 UE: User Equipment 251 UPF: User Plane Function 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 254 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 255 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 256 be interpreted as described in BCP 14 [RFC2119] [RFC8174] 257 when, and only when, they appear in all capitals, as shown 258 here. 260 3. Solution Overview 262 The proposed solution is for the egress edge router (A-ER) 263 with the application instances directly attached to 265 Internet-Draft LSR Extension for 5G EC Service 267 - advertise the "Site-Cost" via IP prefix reachability 268 TLV associated with the (anycast) prefix. 270 - use a Flag in the Flexible Algorithm TLV to indicate 271 that "site-cost" needs to be included for the 272 constrained SPF to reach the Prefix 274 The "Site-Cost" associated with a prefix (i.e., ANYCAST 275 prefix) is computed based on the Capacity Index, the 276 Preference Index, and other constraints by a consistent 277 algorithm across all A-ERs. The capacity and preference 278 indexes are configured to the A-ER. 280 The solution assumes that the 5G EC controller or 281 management system is aware of the EC ANYCAST addresses that 282 need optimized forwarding. To minimize the processing, only 283 the addresses that match with the ACLs configured by the 5G 284 EC controller will have their Site-Cost collected and 285 advertised. 287 4. New Flags added to FAD Flags Sub-TLV 289 A New flag is added to indicate a constrained SPF compute 290 method is needed for the prefix. 292 Flags: 294 0 1 2 3 4 5 6 7... 295 +-+-+-+-+-+-+-+-+... 296 |M|P| | ... 297 +-+-+-+-+-+-+-+-+... 299 P-flag: Site-Cost Metrics is included in deriving 300 Constrained IGP path to the prefix. 302 5. Characteristics of the Site Cost Metric 304 The "Site Cost" associated with a prefix (i.e., ANYCAST 305 prefix) can be a value configured on the router to which 306 the prefix is attached. The "site Cost" can be computed 307 based on an algorithm configured on router for specific 308 prefixes. The actual mechanism of assigning "Site Cost" or 309 the detailed algorithm is out of the scope of document. It 311 Internet-Draft LSR Extension for 5G EC Service 313 is important that the "site cost" metric doesn't change too 314 frequently to avoid route oscillation within the network. 316 The "site cost" change rate is comparable with the rate 317 that the application controller adds or removes the 318 application instances at locations to adjust the workload 319 distribution. Typically, the rate of change could be in 320 days. On rare occasions, there might need rate changes in 321 hours. 323 6. "Site-Cost" Advertisement in OSPF 325 - IPv4: OSPFv2 326 A new Aggregated Cost Sub-TLV needs to be added to 327 OSPFv2 Extended Prefix TLV [RFC7684] 329 - IPv6: OSPFv3 330 A new sub-TLV can be appended to the E-Intra-Area- 331 Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External- 332 LSA, and E-Type-7-LSA [RFC8362] to carry the 333 Aggregated Cost. 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |AggCostSubTLV | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | AggCost to the App Server | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 1: Aggregated cost Advertisement in IS-IS 343 7. "Site-Cost" Advertisement in IS-IS 345 Aggregated Cost can be appended as subTLV to the Extended 346 IP Reachability TLV 135 for IPv4 [RFC5305] and 236 for IPv6 347 [RFC5308]. 349 For Multi-Topology with non-zero IDs, the Aggregated Cost 350 SubTLV can be carried by Multi-topology TLV 235 for IPv4 351 and 237 for IPv6 [RFC5120]. 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |AggCostSubTLV | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Internet-Draft LSR Extension for 5G EC Service 359 | AggCost to the App Server | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 2: Aggregated cost Advertisement in IS-IS 363 8. Alternative method for Distributing Aggregated Cost 365 Section 6 and Section 7 demonstrate different ways for 366 OSPFv2, OSPFv3, and ISIS to propagate the aggregated cost. 367 It would be better if the aggregated cost could be 368 advertised the same way, regardless of OSPFv2, OSPFv3, or 369 ISIS. 371 Draft [draft-wang-lsr-stub-link-attributes] introduces the 372 Stub-Link TLV for OSPFv2/v3 and ISIS protocol respectively. 373 Considering the interfaces on an edge router that connects 374 to the EC servers are normally configured as passive 375 interfaces, these IP-layer App-metrics can also be 376 advertised as the attributes of the passive/stub link. The 377 associated prefixes can then be advertised in the "Stub- 378 Link TLV" that is defined in [draft-wang-lsr-stub-link- 379 attributes]. All the associated prefixes share the same 380 characteristic of the link. Other link related sub-TLVs 381 defined in [RFC8920] can also be attached and applied to 382 the calculation of path to the associated prefixes." 384 Section 6 for the advertisement of AppMetaData Metric can 385 also utilize the Stub-Link TLV that defined in [draft-wang- 386 lsr-stub-link-attributes] 388 9. Manageability Considerations 390 To be added. 392 10. Security Considerations 394 To be added. 396 11. IANA Considerations 398 The following Sub-TLV types need to be added by IANA to 399 FlexAlgo. 401 Internet-Draft LSR Extension for 5G EC Service 403 - AggCostSubTLV Type for ISIS, OSPF (TBD1): IPv4 or IPv6 405 P-flag added to FAD Flags Sub-TLV to indicate that the 406 Site-Cost Metrics is included in deriving Constrained IGP 407 path to the prefix. 409 12. References 411 12.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to 414 Indicate Requirement Levels", BCP 14, RFC 2119, 415 March 1997. 417 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 419 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation 420 Subsequent Address Family Identifier (SAFI) and 421 the BGP Tunnel Encapsulation Attribute", April 422 2009. 424 [RFC7684] P. Psenak, et al, "OSPFv2 Prefix/Link Attribute 425 Advertisement", RFC 7684, Nov. 2015. 427 [RFC8200] S. Deering R. Hinden, "Internet Protocol, Version 428 6 (IPv6) Specification", July 2017. 430 [RFC8326] A. Lindem, et al, "OSPFv3 Link State 431 advertisement (LSA0 Extensibility", RFC 8362, 432 April 2018. 434 [RFC9012] E. Rosen, et al "The BGP Tunnel Encapsulation 435 Attribute", April 2021. 437 Internet-Draft LSR Extension for 5G EC Service 439 12.2. Informative References 441 [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation 442 Partnership Project; Technical Specification 443 Group Services and System Aspects; Study on 444 enhancement of support for Edge Computing in 5G 445 Core network (5GC)", Release 17 work in progress, 446 Aug 2020. 448 [5G-StickyService] L. Dunbar, J. Kaippallimalil, "IPv6 449 Solution for 5G Edge Computing Sticky Service", 450 draft-dunbar-6man-5g-ec-sticky-service-00, work- 451 in-progress, Oct 2020. 453 [BGP-5G-AppMetaData] L. Dunbar, K. Majumdar, H. Wang, "BGP 454 App Metadata for 5G Edge Computing Service", 455 draft-dunbar-idr-5g-edge-compute-app-meta-data- 456 03, work-in-progress, Sept 2020. 458 [LSR-Flex-Algo] P. Psenak, et al, "IGP Flexible Algorithm", 459 draft-ietf-lsr-flex-algo-17, July 2021. 461 [LSR-Flex-Algo-BW] S. Hegde, et al, "Flexible Algorithms: 462 Bandwidth, Delay, Metrics and Constraints", 463 draft-ietf-lsr-flex-algo-bw-con-01, July 2021. 465 [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. 466 Majumdar, "BGP UPDATE for SDWAN Edge Discovery", 467 draft-dunbar-idr-sdwan-edge-discovery-00, work- 468 in-progress, July 2020. 470 Internet-Draft LSR Extension for 5G EC Service 472 13. Appendix A:5G Edge Computing Background 474 The network connecting the 5G EC servers with the 5G Base 475 stations consists of a small number of dedicated routers 476 that form the 5G Local Data Network (LDN) to enhance the 477 performance of the EC services. 479 When a User Equipment (UE) initiates application packets 480 using the destination address from a DNS reply or its 481 cache, the packets from the UE are carried in a PDU session 482 through 5G Core [5GC] to the 5G UPF-PSA (User Plan Function 483 - PDU Session Anchor). The UPF-PSA decapsulates the 5G GTP 484 outer header, performs NAT sometimes, before handing the 485 packets from the UEs to the adjacent router, also known as 486 the ingress router to the EC LDN, which is responsible for 487 forwarding the packets to the intended destinations. 489 When the UE moves out of coverage of its current gNB (next- 490 generation Node B) (gNB1), the handover procedure is 491 initiated, which includes the 5G SMF (Session Management 492 Function) selecting a new UPF-PSA [3GPP TS 23.501 and TS 493 23.502]. When the handover process is complete, the IP 494 point of attachment is to the new UPF-PSA. The UE's IP 495 address stays the same unless moving to different operator 496 domain. 5GC may maintain a path from the old UPF to the new 497 UPF for a short time for SSC [Session and Service 498 Continuity] mode 3 to make the handover process more 499 seamless. 501 Internet-Draft LSR Extension for 5G EC Service 503 +--+ 504 |UE|---\+---------+ +------------------+ 505 +--+ | 5G | +---------+ | S1: aa08::4450 | 506 +--+ | Site +--++---+ +----+ | 507 |UE|----| A |PSA| Ra| | R1 | S2: aa08::4460 | 508 +--+ | +---+---+ +----+ | 509 +---+ | | | | | S3: aa08::4470 | 510 |UE1|---/+---------+ | | +------------------+ 511 +---+ |IP Network | L-DN1 512 |(3GPP N6) | 513 | | | +------------------+ 514 | UE1 | | | S1: aa08::4450 | 515 | moves to | +----+ | 516 | Site B | | R3 | S2: aa08::4460 | 517 v | +----+ | 518 | | | S3: aa08::4470 | 519 | | +------------------+ 520 | | L-DN3 521 +--+ | | 522 |UE|---\+---------+ | | +------------------+ 523 +--+ | 5G | | | | S1: aa08::4450 | 524 +--+ | Site +--++-+--+ +----+ | 525 |UE|----| B |PSA| Rb | | R2 | S2: aa08::4460 | 526 +--+ | +--++----+ +----+ | 527 +--+ | | +-----------+ | S3: aa08::4470 | 528 |UE|---/+---------+ +------------------+ 529 +--+ L-DN2 530 Figure 10: App Servers in different edge DCs 532 13.1. Metrics to change traffic flow patterns 534 When UEs pattern changes, the Application controller can 535 instantiate more instances at certain locations to 536 accommodate higher demand. 538 However, network layer can offer a simpler solution. By 539 adjusting the site cost for the prefix at specific egress 540 routers, IGP distribution of those site cost plus the flex 541 algorithm can increase (or decrease) flows for the specific 542 prefixes towards the certain locations. 544 Internet-Draft LSR Extension for 5G EC Service 546 - Capacity Index: 547 a numeric number, configured on all A-ERs in the 548 domain consistently, is used to represent the capacity 549 of an EC server attached to an A-ER. The IP addresses 550 exposed to the A-ER can be the App Layer Load 551 balancers that have many instances attached. At other 552 sites, the IP address exposed is the server itself. 553 - Site preference index: 554 Is used to describe some sites are more preferred than 555 others. For example, a site with less leasing cost has 556 a higher preference value. Note: the preference value 557 is configured on all A-ERs in the domain consistently 558 by the Domain Controller. 560 13.2. Reason for using IGP Based Solution 562 Here are some benefits of using IGP to propagate the IP 563 Layer App-Metrics: 564 - Intermediate routers can utilize the aggregated cost to 565 reach the EC Servers attached to different egress edge 566 nodes, especially: 567 - The path to the optimal egress edge node can be 568 more accurate or shorter. 569 - Convergence is shorter when there is any failure 570 along the way towards the optimal ANYCAST server. 571 - When there is any failure at the intended ANYCAST 572 server, all the packets in transit can be optimally 573 forwarded to another App Server attached to a 574 different egress edge router. 575 - Doesn't need the ingress nodes to establish tunnels with 576 egress edge nodes. 578 There are limitations of using IGP too, such as: 580 - The IGP approach might not suit well to 5G EC LDN 581 operated by multiple ISPs. 582 For LDN operated by multiple IPSs, BGP should be used. 583 [BGP-5G-AppMetaData] describes the BGP UPDATE message to 584 propagate IP Layer App-Metrics crossing multiple ISPs. 586 Internet-Draft LSR Extension for 5G EC Service 588 13.3. Flow Affinity to an ANYCAST server 590 When multiple servers with the same IP address (ANYCAST) 591 are attached to different A-ERs, Flow Affinity means 592 routers sending the packets of the same flow to the same A- 593 ER even if the cost towards the A-ER is no longer optimal. 595 Many commercial routers support some forms of flow affinity 596 to ensure packets belonging to one flow be forwarded along 597 the same path. 599 Editor's note: for IPv6 traffic, Flow Affinity can be 600 achieved by routers forwarding the packets with the same 601 Flow Label extracted from the IPv6 Header along the same 602 path. 604 14. Acknowledgments 606 Acknowledgements to Peter Psenak, Les Ginsberg, Robert 607 Raszuk, Acee Lindem, Shraddha Hegde, Tony Li, Gyan Mishra, 608 Jeff Tantsura, and Donald Eastlake for their review and 609 suggestions. 611 This document was prepared using 2-Word-v2.0.template.dot. 613 Authors' Addresses 615 Linda Dunbar 616 Futurewei 617 Email: ldunbar@futurewei.com 619 Huaimo Chen 620 Futurewei 621 Email: huaimo.chen@futurewei.com 623 Aijun Wang 624 China Telecom 625 Email: wangaj3@chinatelecom.cn