Gunter Van de Velde has entered the following ballot position for draft-ietf-opsawg-teas-common-ac-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg-teas-common-ac-14 # the referenced line numbers are derived from the idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-14.txt # This is a well written document. I have few non-blocking editorial comments #DETAILED COMMENTS #================= 92 Connectivity services are provided by networks to customers via 93 dedicated terminating points (e.g., Service Functions (SFs), Customer 94 Premises Equipment (CPEs), Autonomous System Border Routers (ASBRs), 95 data centers gateways, or Internet Exchange Points). A connectivity 96 service is basically about ensuring data transfer received from (or 97 destined to) a given terminating point to (or from) other terminating 98 points that belong to the same customer/service, an interconnection 99 node, or an ancillary node. A set of objectives for the connectivity 100 service may eventually be negotiated and agreed upon between a 101 customer and a network provider. For that data transfer to take 102 place within the provider network, it is assumed that adequate setup 103 is provisioned over the links that connect customer terminating 104 points and a provider network (a Provider Edge (PE), typically) so 105 that data can be successfully exchanged over these links. The 106 required setup is referred to in this document as an attachment 107 circuits (ACs), while the underlying link is referred to as "bearer". " Connectivity services are provided to customers by networks via dedicated terminating points (e.g., Service Functions (SFs), Customer Premises Equipment (CPEs), Autonomous System Border Routers (ASBRs), data center gateways, or Internet Exchange Points). A connectivity service ensures that data transferred from (or destined to) a given terminating point can reach (or originate from) other terminating points belonging to the same customer or service, or associated with an interconnection node or ancillary node. Objectives for such a connectivity service may be negotiated and agreed upon between a customer and a network provider. For data to traverse the provider network, it is assumed that appropriate provisioning is in place over the links connecting the customer’s terminating points to the provider network (typically, a Provider Edge (PE)), thereby enabling successful data exchange. This necessary provisioning is referred to in this document as “attachment circuits (ACs),” while the underlying link is referred to as the “bearer.” " 109 When a customer requests a new service, the service can be bound to 110 existing attachment circuits or trigger the instantiation of new 111 attachment circuits. Whether these attachment circuits are specific 112 for a given service or are shared to deliver a variety of services is 113 deployment-specific. " When a customer requests a new service, that service can be associated with existing attachment circuits or may require the instantiation of new attachment circuits. Whether these attachment circuits are dedicated to a particular service or shared among multiple services depends on the specific deployment. " 115 An example of attachment circuits is depicted in Figure 1. A 116 Customer Edge (CE) may be a physical node or a logical entity. A CE 117 is seen by the network as a peer Service Attachment Point (SAP) 118 [RFC9408]. CEs may be dedicated to one single service (e.g., Layer 3 119 Virtual Private Network (VPN) or Layer 2 VPN) or host multiple 120 services (e.g., Service Functions [RFC7665]). A single AC (as seen 121 by a network provider) may be bound to one or multiple peer SAPs 122 (e.g., "CE1" and "CE2"). For example, and as discussed in [RFC4364], 123 multiple CEs can be attached to a PE over the same attachment 124 circuit. This is typically implemented if the Layer 2 infrastructure 125 between the CE and the network provides a multipoint service. The 126 same CE may terminate multiple ACs. These ACs may be over the same 127 or distinct bearers. " An example of attachment circuits is depicted in Figure 1. A Customer Edge (CE) may be realized as a physical node or a logical entity. From the network’s perspective, a CE is treated as a peer Service Attachment Point (SAP) [RFC9408]. CEs can be dedicated to a single service (e.g., Layer 3 Virtual Private Network (VPN) or Layer 2 VPN) or can host multiple services (e.g., Service Functions [RFC7665]). A single AC, as viewed by the network provider, may be bound to one or more peer SAPs (e.g., “CE1” and “CE2”). For instance, as discussed in [RFC4364], multiple CEs can attach to a PE over the same attachment circuit. This approach is typically deployed when the Layer 2 infrastructure between the CE and the network supports a multipoint service. A single CE may also terminate multiple ACs, which may be carried over the same bearer or over distinct bearers. " 149 This document specifies a common module ("ietf-ac-common") for 150 attachment circuits (Section 5). The model is designed with the 151 intent to be reusable by other models and, therefore, ensure 152 consistent AC structures among modules that manipulate ACs. For 153 example, the common model can be reused by service models to expose 154 AC-as-a-Service (ACaaS) (e.g., 155 [I-D.ietf-opsawg-teas-attachment-circuit]), service models that 156 require binding a service to a set of ACs (e.g., Network Slice 157 Service [I-D.ietf-teas-ietf-network-slice-nbi-yang])), network models 158 to provision ACs (e.g., [I-D.ietf-opsawg-ntw-attachment-circuit]), 159 device models, etc. " This document specifies a common module, "ietf-ac-common," for attachment circuits (see Section 5). The module is designed to be reusable by other models, thereby ensuring consistent AC structures across modules that manipulate ACs. For example, the common module can be reused by service models to expose AC-as-a-Service (ACaaS) (e.g., [I-D.ietf-opsawg-teas-attachment-circuit]) or by service models that require binding a service to a set of ACs (e.g., the Network Slice Service [I-D.ietf-teas-ietf-network-slice-nbi-yang]). It can also be employed by network models to provision ACs (e.g., [I-D.ietf-opsawg-ntw-attachment-circuit]) and by device models, among others. " 269 "ietf-ac-common" is imported by "ietf-bearer-svc", "ietf-ac-svc", and 270 "ietf-ac-ntw". Bearers managed using "ietf-bearer-svc" may be 271 referenced in the service ACs managed using "ietf-ac-svc". 272 Similarly, a bearer managed using "ietf-bearer-svc" may list the set 273 of ACs that use that bearer. In order to ease correlation between an 274 AC service requests and the actual AC provisioned in the network, 275 "ietf-ac-ntw" uses the AC references exposed by "ietf-ac-svc". To 276 bind Layer 2 VPN or Layer 3 VPN services with ACs, "ietf-ac-glue" 277 augments the LxSM and LxNM with AC service references exposed by 278 "ietf-ac-svc" and AC network references exposed by "ietf-ac-ntw". " The "ietf-ac-common" module is imported by "ietf-bearer-svc," "ietf-ac-svc," and "ietf-ac-ntw." Bearers managed via "ietf-bearer-svc" may be referenced by service ACs managed using "ietf-ac-svc." Likewise, a bearer managed by "ietf-bearer-svc" may list the set of ACs that use that bearer. To facilitate correlation between an AC service request and the AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by "ietf-ac-svc." Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, "ietf-ac-glue" augments the LxSM and LxNM with AC service references exposed by "ietf-ac-svc" and AC network references exposed by "ietf-ac-ntw." " Many thanks again for this document, Kind Regards, Gunter Van de Velde, RTG AD _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
