Hi Gunter, Thank you for the comments.
I adopted most of your suggested edits as you can see at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-common-ac.txt&url_2=https://boucadair.github.io/attachment-circuit-model/gunter-iesg-review/draft-ietf-opsawg-teas-common-ac.txt Also echoed the changes to Section 3 in the other documents of the AC I-Ds set. Cheers, Med > -----Message d'origine----- > De : Gunter Van de Velde via Datatracker <nore...@ietf.org> > Envoyé : vendredi 17 janvier 2025 13:04 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-opsawg-teas-common...@ietf.org; opsawg- > cha...@ietf.org; opsawg@ietf.org; rro...@ciena.com; > rro...@ciena.com > Objet : Gunter Van de Velde's No Objection on draft-ietf-opsawg- > teas-common-ac-14: (with COMMENT) > > > 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.) > > > > > ----------------------------------------------------------------- > COMMENT: > ----------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg- > teas-common-ac-14 > > > # 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 > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
