[OPSAWG]Gunter Van de Velde's No Objection on draft-ietf-opsawg-teas-common-ac-14: (with COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

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