idnits 2.17.1 draft-lachos-multi-domain-sfc-alto-01.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 (March 9, 2020) is 1507 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8459' is mentioned on line 180, but not defined == Missing Reference: '----AS1----' is mentioned on line 382, but not defined == Missing Reference: '-----AS2-----' is mentioned on line 382, but not defined == Missing Reference: '-----AS3-----' is mentioned on line 382, but not defined == Unused Reference: 'RFC2119' is defined on line 582, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-lachosrothenberg-alto-brokermdo-00 == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-05 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-11 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-04 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-03 == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-03 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-01 == Outdated reference: A later version (-08) exists of draft-li-sfc-hhsfc-05 == Outdated reference: A later version (-05) exists of draft-bernardos-nfvrg-multidomain-04 Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG D. Lachos 3 Internet-Draft Unicamp 4 Intended status: Informational Q. Xiang 5 Expires: September 10, 2020 Tongji/Yale University 6 C. Rothenberg 7 Unicamp 8 Y. Yang 9 Tongji/Yale University 10 March 9, 2020 12 Multi-domain Service Function Chaining with ALTO 13 draft-lachos-multi-domain-sfc-alto-01 15 Abstract 17 The delivery of network services often require service functions and 18 their specific order, called a service function chain (SFC). A SFC 19 request is usually composed by distributed resources which are 20 expected to available across multiple domains with different 21 technology and/or administration. This document describes different 22 standardization activities and research projects addressing the 23 challenges posed by SFC across multiple domains (specifically, 24 multiple administrative domains). In addition, this document 25 presents an initial approach to realize inter-domain service chains 26 leveraging the Application Layer Traffic Optimization (ALTO) 27 protocol. Finally, another important concern of this document is to 28 initiate a discussion (ALTO, SFC as well as other WGs) regarding if, 29 how, and under what conditions ALTO can be useful to improve the 30 multi-domain SFC process. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 10, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Context and Motivation . . . . . . . . . . . . . . . . . . . 4 69 3.1. Standardization Activities . . . . . . . . . . . . . . . 4 70 3.1.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1.2. ETSI . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.3. MEF . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Research projects . . . . . . . . . . . . . . . . . . . . 5 74 4. ALTO for Multi-domain SFC . . . . . . . . . . . . . . . . . . 6 75 4.1. Advantages of using ALTO . . . . . . . . . . . . . . . . 7 76 4.1.1. Inter-domain info discovery with ALTO Property Map . 7 77 4.1.2. Inter-domain path computation with ALTO Cost Map . . 7 78 4.2. Motivating Use Cases . . . . . . . . . . . . . . . . . . 8 79 4.2.1. ALTO as part of the SFC eXchange Platform . . . . . . 8 80 4.2.2. Resource Orchestration for Multi-Domain, Geo- 81 Distributed Data Analytics . . . . . . . . . . . . . 10 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 13 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 9.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The delivery of end-to-end services often requires various Service 94 Functions (SFs). Service Function Chaining (SFC) is an abstracted 95 view of a service that defines a set of required SFs as well as the 96 order in which they must be executed [RFC7665]. Multi-domain SFC is 97 the ability to deploy SFC across multiple domains with different 98 technology and/or administration. To do so, an inter-domain 99 communication process between different organizations is necessary in 100 order to (i) exchange abstract topology, resource and service 101 information, and then (ii) compute inter-domain service function 102 paths. 104 Nowadays, different standardization efforts (e.g., IETF, MEF, ETSI) 105 and research projects activities (e.g., 5GEx [H2020.5GEX], 5G- 106 Transformer [H2020-5G-TRANSFORMER], T-NOVA [T-NOVA]) have been 107 focused on multi-domain network service chaining. Standarization is 108 essential to provide recommendations to create interoperable 109 architectures with standardized protocols, and solutions (being 110 developed by different projects) are addressing a diverse range of 111 requirements to provide network services provided using multiple 112 administrative domains. 114 More recently, the ALTO WG started to discuss the uses of ALTO as an 115 information model for representing network resource and services in 116 multi-domain scenarios: 118 o [DRAFT-ALTO-BROKER-MDO] proposes an ALTO-based Broker-assisted 119 architecture where a broker plane works as a coordinator between a 120 set of top-level control planes, i.e., Multi-domain Orchestrator 121 (MdOs). The ALTO services (with the proposed extensions) provides 122 abstract maps with a simplified, yet enough information view about 123 MdOs involved in the federation. This information includes the 124 abstract network topology, resource availability (e.g., CPUs, 125 Memory, and Storage) and capabilities (e.g., supported NFs). 127 o The document [DRAFT-ALTO-UNICORN] presents Unicorn, a resource 128 orchestration framework for multi-domain, geo-distributed data 129 analytics. This work resorts in ALTO as the information model to 130 support the accurate, yet privacy-preserving resource discovery 131 across different domains. The key information to be provided by 132 the use of ALTO including different types of resources, e.g., the 133 computing, storage, and networking resources. 135 In summary, this document offers (i) an overview reference of several 136 initiatives (standardization efforts and projects) behind building a 137 complete multi-domain SFC, and (ii) concrete use case examples of how 138 ALTO can be incorporated in the multi-domain SFC architecture. 140 The overall rationale of this document is to begin a discussion 141 between the SFC and the ALTO WG (other WGs are welcome) concerning 142 if, how, and under which conditions ALTO will be helpful in the SFC 143 traversing different administrative domains. 145 2. Terminology 147 This document makes use of the terminology defined 148 in [DRAFT-HH-MDSFC], [DRAFT-ALTO-UNICORN], [DRAFT-ALTO-BROKER-MDO], 149 and [RFC7665]. 151 3. Context and Motivation 153 In order to offer a complete end-to-end network service, the multi- 154 domain approach involves two different aspects: multiple 155 administrations or multi-domain single 156 administrations [DRAFT-MD-VIRT]. 158 o Multiple Administrations: Market fragmentation results from having 159 different operators focused on a specific region. This makes 160 difficult to deploy new services, for example, virtual 161 connectivity spanning multiple countries. 163 o Multi-domain Single Administrations: Technology fragmentation 164 creates multi-domain single administration. For example, 165 different parts of a network could be created as different domains 166 using separate technologies. 168 This section summarizes, on the one hand, main standardization 169 efforts delivering collections of norms and recommendations 170 (architectures, frameworks, protocols), while on the other hand it 171 also provides an overview of several projects formed to develop 172 network services across multiple domains. 174 3.1. Standardization Activities 176 3.1.1. IETF 178 SFC that span domains owned by single or multiple administrative 179 entities are being proposed. The Hierarchical Service Function 180 Chaining (hSFC) [RFC8459], for example, defines an architecture to 181 deploy SFC in large networks. This RFC proposes to decompose the 182 network into smaller domains (domains under the control of a single 183 organization). Another proposed initiative is [DRAFT-HH-MDSFC] that 184 describes SFC crossing different domains owned by various 185 organizations (e.g., ISPs) or by a single organization with 186 administration partitions. The proposed architecture uses a SFC 187 eXchange Platform (SXP) to collect and exchange information 188 (topology, service states, policies, etc.) between different 189 organizations and it works both in centralized (Multiple SFC domains 190 connected by a logical SXP) and distributed (SXP server as a broker) 191 environments. 193 Another initiative is the Network Function Virtualization Research 194 Group (NFVRG). The draft "Multi-domain Network Virtualization" 195 [DRAFT-MD-VIRT] envisions a complete end-to-end logical network as 196 stitching services offered by multiple domains from multiple 197 providers. It also points to the need for creating solutions that 198 enable the exchange of relevant information (resources and 199 topologies) across different providers. 201 3.1.2. ETSI 203 The ETSI NFV ISG is paving the way toward viable architectural 204 options supporting the efficient placement of functions in different 205 administrative domains. More specifically, the document 206 [ETSI-NFV-IFA028] reports different NFV MANO architectural approaches 207 with use cases related to network services provided using multiple 208 administrative domains. Besides, it gives a non-exhaustive list of 209 key information to be exchanged between administrative domains 210 (monitoring parameters, topology view, resource capabilities, etc.) 211 and recommendations related to security to permit the correct and 212 proper operation of the final service. 214 3.1.3. MEF 216 With its work on the Service Operations Specification MEF 217 55 [MEF-SOE-MEF55], MEF has defined a reference architecture and 218 framework for describing functional management entities (and 219 interfaces between them) needed to support Lifecycle Service 220 Orchestration (LSO). This LSO architecture enables automated 221 management and control of E2E connectivity services across multiple 222 operator networks. The automated service management includes 223 fulfillment, control, performance, assurance, usage, security, 224 analytics, and policy capabilities that make it possible, for 225 example, expanding the footprint of service providers to interact 226 with potentially several operators to manage and control the access 227 portions of E2E services. 229 3.2. Research projects 231 Several projects include an architectural model integrating NFV 232 management with SDN control capabilities to address the challenges 233 towards flexible, dynamic, cost-effective, and on-demand service 234 chaining. 236 [H2020.5GEX] aims to integrate multiple administrations and 237 technologies through the collaboration between operators in the 238 context of emerging 5G networking. [VITAL][T-NOVA] follow a 239 centralized approach where each domain advertises its capabilities to 240 a federation layer which will act as a broker. In order to avoid one 241 network operator per country or regions, [H2020-5G-NORMA] proposes 242 the use of management and control into a single virtual domain. 243 Also, the 5G-Transformer project [H2020-5G-TRANSFORMER] is defining 244 flexible slicing and federation of transport networking and computing 245 resources across multiple domains. 247 4. ALTO for Multi-domain SFC 249 A "dialogue" between potential domains that will provide multi-domain 250 SFC could be beneficial for a more efficient use of resources and 251 increasing the SFC performance. However, constrained knowledge of 252 the network services and underlying network topology based only on 253 localized views from the point of view of a single domain limits the 254 potential and scope for multi-domain SFC. 256 Note: The examples used in this document are based on architectures 257 and assumptions currently being proposed in the SFC 258 WG [DRAFT-HH-MDSFC] and in the ALTO 259 WG [DRAFT-ALTO-BROKER-MDO] [DRAFT-ALTO-UNICORN]. 261 To enable a highly customized multi-domains SFC, [DRAFT-HH-MDSFC] 262 proposes a SFC eXchange Platform to realize inter-domain 263 communication between top-level control planes. The SXP is a logical 264 entity deployed in future Software-defined IXP (as a trusted third- 265 party platform) or built by a single owner between different 266 networks. 268 On a high level, the scope of the SXP contains two main tasks: 270 o Provide end-to-end visibility through the collection of topology 271 information, service states, and policies from different domains. 273 o Compute inter-domain service function path to select the service 274 function location from multiple candidate domains. 276 The ALTO protocol [RFC7285] provides abstract network information in 277 the form of map services that can be consumed by applications in 278 order to become network-aware and to take optimized decisions 279 regarding traffic flows. Recently, ALTO is also being considered in 280 multi-domain orchestration scenarios [DRAFT-ALTO-UNICORN] 281 [DRAFT-ALTO-BROKER-MDO], in which an ALTO server can convey inter- 282 domain network resource and topology information. 284 In this context, the SXP can take advantage of multi-domain ALTO 285 services to obtain important inter-domain information to "guide" the 286 resource/service provider selection process in that the "best" domain 287 or candidate domains (according to established policies) can be 288 intelligently selected. The following ALTO services can be 289 identified: 291 4.1. Advantages of using ALTO 293 ALTO (and customized ALTO extensions) can be used to offer 294 aggregated/abstracted views on various types of information including 295 domain-level topology, storage resources, computation resources, 296 networking resources and PNF/VNF capabilities. This generic 297 representation contributing to a more simple and scalable solution 298 for resource and service discovery in multi-domain, multi-technology 299 environments. 301 In case of Multi-domain SFC, the following ALTO services could be 302 identified: 304 4.1.1. Inter-domain info discovery with ALTO Property Map 306 Each domain needs a global view of other potential candidate domains 307 to know who can provide part of the SF in the SFC. A brief list of 308 information to be exchanged between different domains includes: 310 o Resource capabilities, applicable to both IT (computing and 311 storage) and networking resources participant of the multi-domain 312 SFC, to assist on the decision of SFs placement. 314 o Access information (e.g., URL) to the orchestrator entry points 315 and Service Access Points (SAPs) for a corresponding network/ 316 domain. 318 The ALTO Property Map Service [DRAFT-ALTO-PM] can provide a clear 319 global view of the resource information offered by other domains. 320 This information allows discovering which candidate domains may be 321 contacted to deliver the remaining requirements of a requested end- 322 to-end service deployment. 324 4.1.2. Inter-domain path computation with ALTO Cost Map 326 Once the candidate domains are discovered, it is necessary to compute 327 inter-domain service function path to select the service function 328 location from those different candidate domains. 330 The connectivity information among discovered domains can be 331 retrieved by an ALTO Cost Map service, responding, for instance, a 332 path vector with the AS-level topology distance between the source 333 domain and candidate domains. Moreover, path vector constraints (as 334 described in the Multi-Cost Map [RFC8189]) can be applied to filter 335 out the list of unqualified domains. 337 In case of the Hybrid Hierarchical SFC architecture [DRAFT-HH-MDSFC], 338 the SXP (or the Path Calculation Element in the top-level control 339 plane) could use this information to compute multi-domain service 340 function paths. 342 4.2. Motivating Use Cases 344 4.2.1. ALTO as part of the SFC eXchange Platform 346 As mentioned earlier, [DRAFT-HH-MDSFC] defines a multi-domain SFC 347 architecture that combines control planes to be deployed either into 348 a large domain consisting of smaller sub-domains owned by the same 349 organization or into multiple large domains with different ownership. 350 Figure 1 shows a SXP connecting three different domains (AS1, AS2, 351 AS3). Each domain provides different SFs: AS1 -> SF1; AS2 -> SF2 and 352 SF3; AS3 -> SF3. The SXP includes an ALTO server component to 353 provide abstract topology, resource, and service information for the 354 high-level control plane in each domain. 356 SFC eXchange 357 Platform 358 +--------------------+ 359 | +--------+ | 360 | | ALTO | | 361 | | Server | | 362 | +--------+ | 363 +----> <-----+ 364 | +----------^---------+ | 365 | | | 366 | | | 367 | | | 368 +----v---+ +-----v--+ +------v-+ 369 |Control | |Control | |Control | 370 |Plane | |Plane | |Plane | 371 +--------+ +--------+ +--------+ 372 | | | 373 | | | 374 | | | 375 +--------+ +--------+ +--------+ 376 |Data | |Data | |Data | 377 |Plane -------Plane -------Plane | 378 +--------+ +--------+ +--------+ 379 SF1 SF2 SF3 380 SF3 382 [----AS1----][-----AS2-----][-----AS3-----] 384 Figure 1: ALTO as part of the SFC eXchange Platform 386 Every domain has a local Information Base Element; this component can 387 be used by the SXP to create hierarchical databases containing inter- 388 domain resource and topology information. This information source is 389 used by the ALTO server to create two different ALTO Map Services: 390 (i) Property Map and (ii) Cost Map. 392 The Property Map includes a property value grouped by Autonomous 393 System (AS), this value contains the supported network functions. 394 Additional properties could be considered such as resource 395 availability (e.g., CPUs, Memory, and Storage), orchestrator entry 396 points, etc. An example of the Property Map in our basic scenario 397 is: 399 +-----+--------------+-------------+-----+-----+---------+-----+ 400 | | Capabilities | Entry Point | CPU | MEM | Storage | ... | 401 +-----+--------------+-------------+-----+-----+---------+-----+ 402 | AS1 | {SF1} | http://... | ... | ... | ... | ... | 403 | AS2 | {SF2, SF3} | http://... | ... | ... | ... | ... | 404 | AS3 | {SF3} | http://... | ... | ... | ... | ... | 405 +-----+--------------+-------------+-----+-----+---------+-----+ 407 Table 1: ALTO Property Map 409 The Cost Map defines a path vector as an array of ASes, representing 410 the AS-level topological distance for a given SFC request. Table 2 411 below shows a brief example of a service request and its inter-domain 412 service function path response containing a list of potential domains 413 to be traversed to deliver such service. 415 +---------------+---------------------------------------+ 416 | SFC Request | Multi-domain Service Function Path(s) | 417 +---------------+---------------------------------------+ 418 | SF1->SF2->SF3 | 1:{AS1:SF1->AS2:SF2->AS2:SF3} | 419 | | 2:{AS1:SF1->AS2:SF2->AS3:SF3} | 420 +---------------+---------------------------------------+ 422 Table 2: ALTO Cost Map 424 4.2.2. Resource Orchestration for Multi-Domain, Geo-Distributed Data 425 Analytics 427 In addition to commercial SFC, ALTO is also used as a core 428 information model for collaborative data science networks. The 429 document [DRAFT-ALTO-UNICORN] presents the design of Unicorn, a 430 unified resource orchestration framework for multi-domain, geo- 431 distributed data analytics, currently being developed and deployed in 432 the CMS network, one of the largest scientific experiments in the LHC 433 network. 435 ALTO is well suited as a fundamental component in Unicorn for 436 providing a generic representation that (1) allows different types of 437 data analytics jobs to accurately describe their resource 438 requirements and (2) allows member networks to provide accurate 439 information on different types of resources they own and at the same 440 time maintain their privacies. 442 .-------------. .-------------. 443 |Application 1| ... |Application N| 444 '-------------' '-------------' 445 \ / 446 .- - - - - - - -\- - - - - - - - - - - -/- - - - - - - - - - - - - - -. 447 | Unicorn \ / | 448 | .-----------------------. | 449 | | Resource Orchestrator | .----------------------.| 450 | | | |Distributed Hash Table|| 451 | | .-----------. |---- | of Computing and || 452 | | |ALTO Client| | | Storage Resources || 453 | | '-----------' | '----------------------'| 454 | '-----------------------' | 455 | / | \ | 456 | / | \ | 457 | .-------------. .-----------. .-------------. | 458 | |ALTO Server 1| | Execution | |ALTO Server M| | 459 | '-------------' | Agents | '-------------' | 460 | | '-----------' | | 461 | | / \ | | 462 | .----------------./ \ .----------------. | 463 | | Site 1 | . . | Site N | | 464 | '----------------' '----------------' | 465 '- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -' 467 Figure 2: Architecture of Unicorn. 469 Figure 2 presents the architecture of Unicorn. Specifically, for 470 each member network, one or more ALTO servers are deployed to provide 471 accurate, yet privacy-preserving information of different types of 472 resources owned by the corresponding network. Examples of such 473 information include the link bandwidth between endpoints, the memory 474 I/O bandwidth and the CPU utilization at computing endpoints and the 475 storage space at storage endpoints. In addition to the basic ALTO 476 services defined in [RFC7285], The ALTO servers in Unicorn also 477 provide ALTO extension services such as the ALTO Multi-Cost Service 478 [RFC8189], the ALTO Server-Sent Event Service [DRAFT-ALTO-INCR-UPD] 479 and the ALTO Path Vector Service [DRAFT-ALTO-PV] to provide fine- 480 grained resource information. 482 Because the ALTO Path Vector service may expose additional private 483 information of each network, Unicorn develops an obfuscating protocol 484 which ensures that nor the orchestrator or any member networks can 485 associate any path vector information with a corresponding network. 487 To better address the scalability issue of multi-domain resource 488 discovery, Unicorn also develops a proactive full-mesh discovery 489 mechanism, which precomputes network-level ALTO path vector 490 information and performs projection using such information to compute 491 the fine-grained resource information in response to orchestrator's 492 resource discovery requests. 494 Details of the obfuscating protocol and the proactive full-mesh 495 discovery mechanism developed in Unicorn can be found in the 496 [DRAFT-ALTO-UNICORN] document. 498 5. IANA Considerations 500 This document includes no request to IANA. 502 6. Security Considerations 504 The ALTO base protocol has an extensive discussion on potential 505 security and privacy issues. Using the ALTO base protocol to support 506 multi-domain SFC will not raise new security and privacy issue. 507 However, the information provided by the ALTO base protocol are 508 considered coarse-grained in several recent use cases. As a result, 509 several ALTO extension services have been designed to provide fine- 510 grained network information to the application. Using these ALTO 511 extension services for multi-domain SFC would raise new security and 512 privacy concerns. Next we list these issues on a per extension 513 basis. 515 The ALTO unified property extension [DRAFT-ALTO-PM] generalizes the 516 concept of endpoint properties to other entity domains, such as 517 abstract network element. The properties of these entities may 518 contain sensitive service-function-specific information. Exposing 519 such information may discourage networks to provide fine-grained 520 information to support multi-domain SFC. 522 The ALTO performance cost metrics extension [DRAFT-ALTO-METRICS] 523 proposes a set of ALTO cost metrics derived from traffic engineering 524 tools and protocols. It is stated in this extension that "sharing 525 network TE metric values in numerical mode requires full mutual 526 confidence between the entities managing the ALTO Server and Client." 527 In multi-domain SFC use case, such mutual confidence is needed not 528 only between ALTO server and client, but also among all networks, and 529 third-parties such as broker and a global orchestrator. How to 530 achieve such mutual confidence in multi-domain SFC use case requires 531 further investigation. 533 The ALTO path vector extension [DRAFT-ALTO-PV] allows ALTO clients to 534 query network information such as capacity region for a given set of 535 flows. Several related studies have shared concerns that this 536 extension may reveal more network internal structures than the more 537 abstract single-node abstraction used in the ALTO base protocol. In 538 multi-domain SFC, this concern will further be amplified as third- 539 party participants may access such information. The recent designed 540 Unicorn system proposes an obfuscating protocol that prevent the 541 receiver of the capacity region information from associating this 542 region to any network. This protocol sheds light for addressing the 543 privacy issue brought by the ALTO path vector extension. 545 The ALTO cost calendar [DRAFT-ALTO-CALENDAR] and the ALTO incremental 546 update [DRAFT-ALTO-INCR-UPD] extensions allows the ALTO client to get 547 temporal network information. The intention of these extensions is 548 to allow applications to make flexible decisions on when to use 549 network information. However, both extensions expose temporal policy 550 and traffic information of network so that a user may know when the 551 network is most vulnerable for overloading. This issue need to be 552 carefully addressed in order for both extensions to be used for 553 multi-domain SFC. 555 7. Summary and Outlook 557 This document introduced initiatives and solutions being proposed in 558 the context of SFC traversing different domains. It is also provided 559 initial arguments why ALTO is a meaningful protocol in such multi- 560 domain scenario, and it presented use case examples about the how 561 ALTO can be used to advertise and discover abstract topology, 562 resource and service information from different domains, and then 563 compute inter-domain service function paths. 565 The overall objective of this document is to arouse discussions in 566 the SFC WG in order to assess the suitability of the ALTO as a useful 567 protocol for multi-domain SFC scenarios. The result of such 568 discussions will be captured in future versions of this draft. 570 8. Acknowledgments 572 This work is supported by the Innovation Center of Ericsson S.A., 573 Brazil (grant agreement UNI.64). 575 Many thanks to Sabine Randriamasy, and Lyle Bertz for their feedback 576 on this draft. 578 9. References 580 9.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997, 584 . 586 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 587 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 588 "Application-Layer Traffic Optimization (ALTO) Protocol", 589 RFC 7285, DOI 10.17487/RFC7285, September 2014, 590 . 592 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 593 Chaining (SFC) Architecture", RFC 7665, 594 DOI 10.17487/RFC7665, October 2015, 595 . 597 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 598 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 599 DOI 10.17487/RFC8189, October 2017, 600 . 602 9.2. Informative References 604 [DRAFT-ALTO-BROKER-MDO] 605 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 606 Multi-domain Orchestration", draft-lachosrothenberg-alto- 607 brokermdo-00 (work in progress), March 2018. 609 [DRAFT-ALTO-CALENDAR] 610 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 611 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 612 calendar-05 (work in progress), June 2018. 614 [DRAFT-ALTO-INCR-UPD] 615 Roome, W., Yang, Y., and S. Chen, "ALTO Incremental 616 Updates Using Server-Sent Events (SSE)", draft-ietf-alto- 617 incr-update-sse-11 (work in progress), June 2018. 619 [DRAFT-ALTO-METRICS] 620 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 621 "ALTO Performance Cost Metrics", draft-ietf-alto- 622 performance-metrics-04 (work in progress), June 2018. 624 [DRAFT-ALTO-PM] 625 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 626 Zhang, "Unified Properties for the ALTO Protocol", draft- 627 ietf-alto-unified-props-new-03 (work in progress), March 628 2018. 630 [DRAFT-ALTO-PV] 631 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 632 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 633 Vector Cost Type", draft-ietf-alto-path-vector-03 (work in 634 progress), March 2018. 636 [DRAFT-ALTO-UNICORN] 637 Xiang, Q., Le, F., Yang, Y., Newman, H., and d. 638 duhaizhou@gmail.com, "Unicorn: Resource Orchestration for 639 Multi-Domain, Geo-Distributed Data Analytics", draft- 640 xiang-alto-multidomain-analytics-01 (work in progress), 641 March 2018. 643 [DRAFT-HH-MDSFC] 644 Li, G., Li, G., Li, T., Xu, Q., and H. Zhou, "Hybrid 645 Hierarchical Multi-Domain Service Function chaining", 646 draft-li-sfc-hhsfc-05 (work in progress), April 2018. 648 [DRAFT-MD-VIRT] 649 Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., 650 Li, X., Paolucci, F., Sgambelluri, A., Martini, B., 651 Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, 652 "Multi-domain Network Virtualization", draft-bernardos- 653 nfvrg-multidomain-04 (work in progress), March 2018. 655 [ETSI-NFV-IFA028] 656 ETSI, "Report on architecture options to support multiple 657 administrative domains V3.1.1", Jan 2018, 658 . 661 [H2020-5G-NORMA] 662 H2020, "5G-NORMA -- 5G Novel Radio Multiservice adaptive 663 network Architecture", 2015, . 665 [H2020-5G-TRANSFORMER] 666 H2020, "5G-Transformer -- 5G Mobile Transport Platform for 667 Vertical", 2017, . 669 [H2020.5GEX] 670 Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon, 671 C., and R. Szabo, "5G Exchange (5GEx)--Multi-domain 672 Orchestration for Software Defined Infrastructures", 673 focus vol. 4, no.5, p.2, 2015. 675 [MEF-SOE-MEF55] 676 Metro Ethernet Forum, "Lifecycle Service Orchestration 677 (LSO): Reference Architecture and Framework", Mar 2016, 678 . 681 [T-NOVA] FP7 project T-NOVA, "T-NOVA Project, Network Functions as 682 a Service over Virtualised Infrastructures", 2014, 683 . 685 [VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid 686 satellite-TerrestriAl systems for resilient and fLexible 687 future networks", 2015, . 689 Authors' Addresses 691 Danny Alex Lachos Perez 692 University of Campinas 693 Av. Albert Einstein 400 694 Campinas, Sao Paulo 13083-970 695 Brazil 697 Email: dlachosp@dca.fee.unicamp.br 698 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 700 Qiao Xiang 701 Tongji/Yale University 702 51 Prospect Street 703 New Haven, CT 704 USA 706 Email: qiao.xiang@cs.yale.edu 708 Christian Esteve Rothenberg 709 University of Campinas 710 Av. Albert Einstein 400 711 Campinas, Sao Paulo 13083-970 712 Brazil 714 Email: chesteve@dca.fee.unicamp.br 715 URI: https://intrig.dca.fee.unicamp.br/christian/ 716 Y. Richard Yang 717 Tongji/Yale University 718 51 Prospect St 719 New Haven, CT 720 USA 722 Email: yang.r.yang@gmail.com