ALTO F. Zhou Internet-Draft X. Qian Intended status: Standards Track D. Yuan Expires: 25 April 2023 ZTE Corporation 22 October 2022 Database-based Open Resource Service Framework draft-zhou-alto-dbors-framework-00 Abstract This document proposes the framework of Database-based Open Resource Service. It contributes to the overall integration of network and cloud by providing fine-granularity differentiated services and increasing resource utilization rate over the cloud and network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Zhou, et al. Expires 25 April 2023 [Page 1] Internet-Draft DB-ORS Framework October 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DB-ORS Framework and Key Components . . . . . . . . . . . . . 3 4.1. DB-ORS Framework Description . . . . . . . . . . . . . . 3 4.2. DB-ORS Implementation Procedures . . . . . . . . . . . . 5 4.3. DB-ORS Handling Requirements . . . . . . . . . . . . . . 6 5. Illustration and Designs . . . . . . . . . . . . . . . . . . 6 5.1. Services Abstraction . . . . . . . . . . . . . . . . . . 7 5.1.1. VDlink . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. VTlink . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.3. Link Identification . . . . . . . . . . . . . . . . . 8 5.1.4. Link Employment . . . . . . . . . . . . . . . . . . . 9 5.2. Services Publishing . . . . . . . . . . . . . . . . . . . 9 5.3. Services Orchestration . . . . . . . . . . . . . . . . . 10 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Cloud Access Scenario . . . . . . . . . . . . . . . . . . 11 6.2. DCI Scenario . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Considerations in the Future . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction With the rapid development of cloud computing and profound utilization of mobile Internet, the cloud has become an increasingly popular platform for hosting software applications and daily information in a variety of domains such as e-retail, finance, news, and social networking. The demand to connect the clouds accelerates urgently for not only enterprises and companies but also government departments which leads to rapid growth of traffic between terminals and clouds or different data centers. However, gaps exist among current solutions including complexity in configuration, time-consuming provisioning cycle, constrained access and coarse-granularity services provisioning as clarified in [I-D.zhou-alto-dbors-requirement-usecase] . Therefore, a systematic architecture to perform integrated operation of clouds and the network for future scenarios which is defined as Database-based Open Resource Service is proposed in this draft, aiming to provide fine-granularity differentiated services and increase resource utilization rate over the cloud and network. Zhou, et al. Expires 25 April 2023 [Page 2] Internet-Draft DB-ORS Framework October 2022 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology * DB-ORS: Database-based Open Resource Service * SRv6: Segment Routing over IPv6 * VDLink: Virtual Direct Link * VTLink: Virtual Tunnel Link * SID: Segment Identifier * CPE: Customer Premise Equipment * DCI: Data Center Interconnection 4. DB-ORS Framework and Key Components 4.1. DB-ORS Framework Description Network functions are possible to be shared as services by abstracting and encapsulating its resources. Applications subscribe services on their interests and further binds them, so as to satisfy the fine-gained SLA requirements in the context of multiple clouds connected by a unique network area. DB-ORS abstracts the atomic service capabilities of the network and by introducing common database techniques, realizes service delivery which merely requires single point access. DB-ORS expands and enhances perception abilities of the network by successive procedures including the abstraction of services and capabilities, service publishment and re-orchestration of network services which is shown in Figure 1. Zhou, et al. Expires 25 April 2023 [Page 3] Internet-Draft DB-ORS Framework October 2022 +---------------------+ +--------------------+ | | +--------------------+ | | Cloud-Network | | | | | Orchestrator | | Cloud Application's| | | | | Terminal / CPE | | +---------------------+ | |-+ | ^ +--------------------+ v | ^ +------------+ Subscribe | | |-------------------------+ | Database |-----------------------+ | |<--------------------+ | +------------+ | | | ^ | | | | Network Cloud | | Subscribe | | Information Information | | Subscribe | | Export Export | | v | | | +-------------------------+ | | .-------. | Network Controller | | v( ) | | .-------. ) | Atomic Resource Services| ( ) )-- | +-------------------+ | ( ) Cloud 2 ) | | VDLink | | --( )-- ) | | VTLink | | ( Cloud 1 ) ) | +-------------------+ | ( ) ) | ^ | ( Cloud Controller ) ) | |Abstraction | ( +-----------------+ ) ) | | | ( | Computational | ) ) | Basic Physical Functions| ( | Scheduling | ) ) | +--------------------+ | ( | | ) ) | | Physical Link | | ( | Data Center | ) ) | | Tunnel | | ( | Interconnection | ) ) | +--------------------+ | ( +-----------------+ ) ) +-------------------------+ ( ^ ) ) ^ ( | ) ) | ( v ) ) v ( +-----------------+ ) ) +-------------------------+ ( | Cloud Resources | ) ) | | ( +-----------------+ ) ) | Underlay Networks | ( )---' | | ( ) +-------------------------+ '-----------------' Figure 1: DB-ORS Framework Zhou, et al. Expires 25 April 2023 [Page 4] Internet-Draft DB-ORS Framework October 2022 The key components are introduced as follows. * Network controller: the controller for the network domain, whose specially assigned duty in this framework is to draw an abstraction towards network basic physical functions like link and tunnel by extracting key attributes while neglecting unnecessary details, and further encapsulate them into a series of virtual services. Each service can be treated as an unique atomic element without interfering any other services. * Cloud-Network Orchestrator: an orchestrator for both the network domain and the cloud domain. * Database: a distributed Key-Value database owned by the Cloud- Network orchestor and shared by both the cloud and Network, with the publish/subscribe mechanism. * Application Terminal and CPE: terminals and customer premise equipment which turn out to be service customers, which subscribe their required services from the database. The key interfaces are introduced as follows. * The Northbound Interface (NBI) of the Network Controller: the network capabilities and physical functions is abstracted and exported via this interface to the distributed database, which will be translated into key-value schemes. * The Southbound Interface (SBI) of the Network Controller: the network physical topology and fine-granular network information are enforced via this interface from the underlay network. The candidate protocols for this interface are PCEP, BGP, YANG-based protocols, etc. 4.2. DB-ORS Implementation Procedures The network controller in the bearer network processes the service abstraction of network capabilities which translates basic networking functions into a series of open atomic services. The outcoming atomic services of bearer network are modeled by applying a key-value scheme and further stored into a designated database. Here, distributed databases, ETCD for instance, are recommended for which sustains strong consistency among its operators or visitors. Since the bearer network and cloud applications commonly communicates with the database, a typical subscribe/publish mechanism is applied. To be noted, the unification of a specific key-value scheme is indispensable since multiple manufacturers of network devices and cloud providers are possible to be involved and released information Zhou, et al. Expires 25 April 2023 [Page 5] Internet-Draft DB-ORS Framework October 2022 needs to be identified by every participants. So a schema description file is proposed and utilized to unify various descriptions as a template. The cloud controller subscribes the updated information of network's atomic services published by the network which stored in the database, and further parses them out referring to the schema description file. Then the cloud controller rearrange and bind the services according to designated principles. Mapping relationships and updated results can also be informed back to the database in need. 4.3. DB-ORS Handling Requirements Currently, clouds communicate with the network through specific interfaces, Restful for instance. Since the cloud and the network locates in separate domains, third-party infrastructures addressed as super controllers is highly demanded to orchestrate traffic bi- directionally. When a newly registered service capability is provided by the network to deliver to the cloud, a respective application program interface (API) is required which has deficiencies in scalability and simplicity. Also, as analyzed in [I-D.zhou-alto-dbors-requirement-usecase] , fine-granular service provisioning and enhanced resources utilization is urgently required. Thus, DB-ORS handles the mentioned requirements: * With network capabilities abstracted as atomic services, fine- granularity service identification, provisioning can be achieved. * With services subscribed by orchestrators, explicit information of the network domain reveals which enables intelligent traffic orchestration and scheduling and increases network resources utilization. * Since the database communicates the network domain and the cloud and the inherent publish/subscribe mechanism, the communication framework is flattened and thus the interactions is relatively simplified which brings a profound integration and convergence of cloud and network. 5. Illustration and Designs Zhou, et al. Expires 25 April 2023 [Page 6] Internet-Draft DB-ORS Framework October 2022 5.1. Services Abstraction Cloud applications are regarded to be important customers of bearer network. In order to meet the customized requirements from different cloud applications at the same time, the bearer network needs to reserve link resources (layer 2) or topology resources (layer 3) in advance respectively, and enable the corresponding cloud applications to invoke the resources allocated to them exclusively. The resources reserved by the bearer network can be abstracted into the following atomic services: * virtual direct link (VDLink) * virtual tunnel link (VTLink) 5.1.1. VDlink VDLink is a virtual direct link abstracted from a physical direct link. With the definition physical direct link of BGP-LS in [RFC7752] , VDLink is identified by local node descriptor, remote node descriptor, local interface address, remote interface address, and other fields about its resource capabilities. The attributes of VDLink include: Logic ID, Local Node Descriptor, Local Node Interface Address, Remote Node Descriptor, Remote Node Interface Address, Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay, Maximal Reservable Link Bandwidth, Unidirectional Link Loss, IGP Metric, TE Metric, END.X SID. The definitions of Logic ID, Local Node Descriptor, Local Node Interface Address, Remote Node Descriptor, Remote Node Interface Address, Maximal Reservable Link Bandwidth, IGP Metric and TE Metric are described in [RFC7752] . The definitions of Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay and Unidirectional Link Loss are illustrated in [RFC8571] . The definitions of End.X SID are stated in [I-D.ietf-idr-bgpls-srv6-ext] and [RFC9086] . 5.1.2. VTlink VTLink is a virtual tunnel. There are multiple tunnel types over different dataplanes and SRv6 dataplane is analyzed as an instance in this draft. A VTLink can be abstracted from a SRv6 policy tunnel and its attributes include: Logic ID, Local Node Descriptor, Remote Node Descriptor, Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay, Maximal Reservable Link Bandwidth, Unidirectional Link Loss, IGP Metric, TE Metric, Binding SID. The definitions of mentioned attributes are described in [RFC7752] , [RFC8571] , Zhou, et al. Expires 25 April 2023 [Page 7] Internet-Draft DB-ORS Framework October 2022 [I-D.ietf-idr-bgpls-srv6-ext] and [RFC9086] . Among them, Maximal Reservable Link Bandwidth is the maximum constrained bandwidth in SRv6 Policy reserved for the VTLink. It should be substracted from physical bandwidth when any VTLink is allocated, which is similar to the process in VDLink. Minimal/Maximal Unidirectional Link Delay is the accumulation of the minimal/maximal delay of each node and each segment in segment-list. If multiple sigment-lists are applied, the largest accumalation among all segment-lists is adopted. IGP Metric is the accumulation of IGP metric of each segment in segment-list. If there are multiple segment-lists in a path, the largest accumulation among all segment-lists is adopted. TE Metric is the accumulation of TE metric of each segment in segment-list. If there are multiple segment-lists in a path, the largest accumulation among all segment-lists is adopted. Unidirectional Link Loss is the quotient of the total packets lost in each segment in segment-lists divided by the total number of sent packets. If there are multiple segment-lists in a path, the largest quotient among all segment-lists is adopted. Regarded as a virtual SRv6 policy tunnel, VTLink can be abstracted as a link whose granularity is optional according to service scenario. For instance, for the scenarios of interconnection between data centers, the number of required nodes orchestrated in the segment- list is 2 or 3. However, fulfillment of communications between a teminal and applications in clouds, a VTLink may be a complete SRv6 policy path, and the number of required nodes orchestrated in the segment-list may reach 10. 5.1.3. Link Identification To facilitate path calculation and routing in cloud, a new logic-id is defined to identify a VDLink or VTLink. The logic-id should be globally unique in the network domain. Its data type is unsigned integer. The format of virtual link identifier is shown below. Bit 0 to 4: Cloud-ID (CI), which is used to differentiate applications (such as different cloud service providers). Bit 5 and 6 are reserved bits for future usage. Zhou, et al. Expires 25 April 2023 [Page 8] Internet-Draft DB-ORS Framework October 2022 Bit 7: Link Type(LT), value 0 stands for VDLink while value 1 stands for VTLink. Bit 8 to 31: the value of Logic-id, thich ranges from 1 to 16777215 and value 0 is reserved. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cloud-ID|R LT| Logic-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of Virtual Link Identifier 5.1.4. Link Employment On the basis of the original physical link, VDLink and VTLink are abstracted, and by identifying designated logic-id and cloud-ID, different virtual links and cloud applications can be distinguished. For a particular virtual link, cloud applications may only focus on the upper bound of the SLA attributes. For example, the maximum value of the original physical link represents the metric and delay. Bandwidth resources of virtual link SHOULD be reserved in the original physical link. Therefore, cloud controller directly orchestrates VDLink and VTLink instead of orginal physical link and a unique network logical topology is constituted for cloud applications. 5.2. Services Publishing The bearer network models the abstracted network atomic services in a key-value scheme and writes them into a database. Since network devices may be produced by different manufacturers while cloud applications may also be provided from different cloud vendors, network atomic services need to be described in a unified schema in order to enable interoperability among different device manufacturers and cloud vendors. The key-value database adopts publishing/subscription mechanism to publish network atomic services. The information stored and published in the database include but are not limited to: Zhou, et al. Expires 25 April 2023 [Page 9] Internet-Draft DB-ORS Framework October 2022 * VDLink: As described in 5.1.1. * VTLink: As described in 5.1.2. * Cross domain link: The bearer network collects the following information about the link between the network and cloud gateway which is a cross AS link and writes it into the database, including: cross domain link ID, source node ROUTEID, source AS, destination node ROUTEID, destination AS, PeerNode SID, PeerAdj SID, local interface address, remote interface address, delay, bandwidth, packet loss rate, TE metric. * Node: The information of head node and tail node in a real layer 3 link, including, IGP ROUTE ID, AS index, etc. 5.3. Services Orchestration Based on the published network atomic services, unified service orchestration, path calculation and routing can be fulfilled at an integrated layer of the cloud and the network by an overall cloud- network orchestrator as shown in Figure 1. In a typical scenario of data center inteconnection, the cloud have relatively powerful processing capabilities compared to network terminals. When the cloud controller is informed of its lateset assigned virtual links from the bearer network through a subscription scheme, it combines the network information with the collected cloud information and further performs an integrated orchestration. Under current conditions, various services running in the cloud raise respective differetiated requirements for the network. As mentioned above, the cloud is configured as a starting point of the service which also obtains the network open atomic services. After re- orchestration, various paths that satisfy the requirements of different services respectively are calculated. The binding relationship between paths and specific service traffic which help to achieve fine-grained perception for network services. In another scenario when terminals access cloud services, some POP points or terminals do not have sufficient capabilities to process complex calculation. Information about virtual links like VTLink or VDLink will not published to the network domain. As a substitute, the Cloud-Network orchestrator maps virtual links to an specific identifier, namely a SAN-ID described in [I-D.service-identification-header-of-san] . The SAN-ID represents the SLA information of the network, which is published to a terminal or a CPE. The terminal or CPE carries the SAN-ID in the IPv6 packet as described in [I-D.encapsulation-of-san-header] , and the network edge router forwards it according to the SAN-ID matching the required Zhou, et al. Expires 25 April 2023 [Page 10] Internet-Draft DB-ORS Framework October 2022 network path in reference to [I-D.computing-segment-for-service-routing] and [I-D.compute-aware-advertise-route-san-database] . 6. Use Cases 6.1. Cloud Access Scenario As shown in Figure 3, when terminals access the cloud to acquire specific applications, the orchestration process within the architecture of DB-ORS mainly includes: * A Cloud-Network orchestrator is deployed over the network and cloud domain, and a key-value sheme database is configured. The cloud controller informs the running status of computing resources and service SLA requirements to the database. * The bearer network allocates exclusive resource for the cloud application which is abstracted as open atomic services like VTLink and is further written into the database. * Based on the information collected from the cloud and the network, the Cloud-Network orchestrator implements path calculation, generates appropriate SRv6 policies and assigns a unique SAN-ID to bind respective policies. Then, the SRv6 policy and SAN-ID are written into the database in a key-value scheme. * Terminals to access the cloud obtains a specific SAN-ID from the database by subscription while the bearer network controller obtains the SRv6 policy and SAN-ID and advertises the information to all edge routers which serve as traffic entrance by BGP, NETCONF or other feasible means. * Service traffic to the cloud sent from the terminal is encapsulated with SAN-ID at CPE. When receiving a packet, edge routers of the bearer network match a specific policy by the identified SAN-ID, and forward the packet to the gateway of the cloud. Zhou, et al. Expires 25 April 2023 [Page 11] Internet-Draft DB-ORS Framework October 2022 .-----. .-----. ( ) ( ) .--( )--. .--( )--. ( ) ( ) ( SaaS_A1 ) ( SaaS_A2 ) ( ) ( ) ( ) ( ) .-----------------. .-----------------. ^ ^ | | | | +-----+-----+ +--------------+ +-----+-----+ | gateway +<--------+ Orchestrator +-------->+ gateway | +-----+-----+ +---+---+---+--+ +-----+-----+ ^ | | | ^ | +----------+ | | | +----------+ | | | database +<-+ | +->+ database | | .-----. +----^-----+ | +----^-----+ .-----. ( ) | | | ( ) .--( )-----+ v +-----( )--. ( ) +------+ ( ) ( underlay network1 )<--------+ edge |-------->( underlay network2 ) ( ) +------+ ( ) .--( )--. ^ ^ .--( )--. ( ) | | ( ) .-----. | | .-----. | | +-------+ | | +-------+ | APP_1 +--+ +--+ APP_2 | +-------+ +-------+ Figure 3: Cloud Access Scenario 6.2. DCI Scenario As shown in Figure 4, When data centers interconnects with each other, the orchestration process within the architecture of DB-ORS mainly includes: * Based on the demand for the interconnection between data centers, the bearer network allocates exclusive resources respectively which are abstracted as atomic services and stored in a key-value scheme database. Zhou, et al. Expires 25 April 2023 [Page 12] Internet-Draft DB-ORS Framework October 2022 * Respective controllers subscribe concerning information, and observes variations promptly including additions, deletions and modifications. * Controllers perform analysis through the unified schema template to obtain the latest network atomic services like VTLink and VDLink. Based on the latest visible topology within both the inner and outer domain of the cloud, the re-orchestration and path calculation can be achieved for the interconnection between data centers. +------------+ +----->+ database +<-----+ | +------------+ | | | | | | | | .--------. .-----. ( ) .-----. ( ) .--( )--. ( ) .--( )--. ( SRv6 Core ) .--( )--. ( ) ( ) ( ) ( SaaS_A1 )------( DCI Network )------( SaaS_A2 ) ( ) .--( )--. ( ) .---------------. ( ) .---------------. .--------. Figure 4: DCI Scenario 7. Security Considerations Considering the network domain, revealing internal resources obviously brings security problems that must be considered. The exposure of internal topologies, metrics and other privacies in the network is possible to encounter more malicious attacks. The unawakened security drawbacks within database or cloud will also increase the risk. So security protection measures such as anti DDOS attack methods, network security audit, database anti attack schemes, database intrusion detections, access authorization and verification of the database, and other necessary techniques SHOULD be applied. Specific methods will be discussed in detail in the future. Zhou, et al. Expires 25 April 2023 [Page 13] Internet-Draft DB-ORS Framework October 2022 8. Considerations in the Future The framework of DB-ORS described in this document takes the cloud and the network as a whole for resource allocation and service orchestration, thus improving the service delivery efficiency and enhancing user experiences. Furthermore, It is easy to expand more opened services beyond the link resource services described in this document, such as topology services, security resource services, and deterministic QoS services, which make the framework of DB-ORS be capable of satisfying future requirements appearing with the trend of the convergence of the cloud and the network. 9. Acknowledgements TBA. 10. IANA Considerations TBA. 11. Normative References [I-D.compute-aware-advertise-route-san-database] Zhou, F. and D. Yuan, "Computing Status Awareness, Advertisement and Service Routing methods of SAN Based on Databases", Work in Progress, Internet-Draft, draft- compute-aware-advertise-route-san-database-00, 10 October 2022, . [I-D.computing-segment-for-service-routing] Zhou, F. and D. Yuan, "Computing Segment for Service Routing in SAN", Work in Progress, Internet-Draft, draft- computing-segment-for-service-routing-00, 9 October 2022, . [I-D.encapsulation-of-san-header] Ma, L., Zhao, D., and F. Zhou, "Encapsulation of SAN Header", Work in Progress, Internet-Draft, draft- encapsulation-of-san-header-00, 18 August 2022, . [I-D.ietf-idr-bgpls-srv6-ext] Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., Bernier, D., and B. Decraene, "BGP Link State Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf- Zhou, et al. Expires 25 April 2023 [Page 14] Internet-Draft DB-ORS Framework October 2022 idr-bgpls-srv6-ext-11, 14 October 2022, . [I-D.service-identification-header-of-san] Ma, L., Zhou, F., and H. Li, "Service Identification Header of Service Aware Network", Work in Progress, Internet-Draft, draft-service-identification-header-of- san-00, 18 August 2022, . [I-D.zhou-alto-dbors-requirement-usecase] Zhou, F., Wang, S., and D. Yuan, "Requirements and Use Cases of DB-ORS (Database-based Open Resource Service)", Work in Progress, Internet-Draft, draft-zhou-alto-dbors- requirement-usecase-00, 22 October 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, . Authors' Addresses Zhou, et al. Expires 25 April 2023 [Page 15] Internet-Draft DB-ORS Framework October 2022 Fenlin Zhou ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: zhou.fenlin@zte.com.cn Xiaocong Qian ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: qian.xiaocong@zte.com.cn Dongyu Yuan ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: yuan.dongyu@zte.com.cn Zhou, et al. Expires 25 April 2023 [Page 16]