A Common YANG Data Model for Attachment Circuits
draft-ietf-opsawg-teas-common-ac-15

Thank you to Watson Ladd for his secdir review.

# 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

Other than the following from nits no substantive comments:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'

  ** Downref: Normative reference to an Informational RFC: RFC 7348

  == Outdated reference: A later version (-13) exists of
     draft-ietf-opsawg-ac-lxsm-lxnm-glue-12

  == Outdated reference: A later version (-15) exists of
     draft-ietf-opsawg-ntw-attachment-circuit-14

  == Outdated reference: A later version (-19) exists of
     draft-ietf-opsawg-teas-attachment-circuit-18

# Orie Steele, ART AD, comments for draft-ietf-opsawg-teas-common-ac-14 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-14.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### md5

```
573	                +--:(md5)
574	                |  +-- md5-keychain?       key-chain:key-chain-ref
```

I assume there is no other choice?

https://www.rfc-editor.org/rfc/rfc8177.html#section-5

```
Similarly, the MD5 and SHA-1 algorithms have been proven to be
insecure ([Dobb96a], [Dobb96b], and [SHA-SEC-CON]), and usage is NOT
RECOMMENDED.  Usage should be confined to deployments where it is
required for backward compatibility.
```

## Nits

### this identity can _be_ used...

```
310	      type in an AC.  For example, this identity can used to indicate
```


### is _used_ to control...

```
321	   'l2-tunnel-type':  Uses to control the Layer 2 tunnel selection for
```

One minor comment / question:

Why the groupings split on addr family split, eg ipv4-static-rtg-entry and ipv6-static-rtg-entry ?
This causes a lot of almost identical duplication ? Couldn't the values just take (v4 or v6) ?

Thank you to Behcet Sarikaya for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-teas-common-ac-14
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Reza Rokui for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is rather light: being "valuable" is not enough to be a "standard".

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

Thanks for using SVG graphics, it makes reading the HTML rendering much easier and nicer.

### Abstract

Should 'model' be used rather than 'module' in `The document specifies a common attachment circuits (ACs) YANG module` in order to be consistent with the title ? I understand that a model can consist of a single module.

### Section 1

Should `ancillary node` be better explained as it can mean multiple things depending on the context?

Figure 1, when the text writes `The same CE may terminate multiple ACs.` it would help if the text mentioned CE3 & CE4 and the associated bearer (assuming that `b*` is for a bearer).

### Section 2

When defining "bearer", please associate  the previously defined terms (CE, CPE) with `customer node`.

### Section 3

Not really about this I-D, but I find the use of `ietf-ac-glue` rather than 'ietf-ac-bind' a little too trivial especially when the text is about `To bind Layer 2 VPN` ;-)

### Section 4

Thanks for splitting the whole tree in parts, it helps.

### Section 4.1

It is rather unclear what `server` means in this document, even if I can guess some controllers in the SP domain.

### Section 4.3

Should there be a `*l3*-tunnel-type` in addition to `*l2*-tunnel-type` ?

Should the layer of the next hop be specified in `local-defined-next-hop`?

Should there be reference to `UNI`and `NNI`?

About figure 5 explanations about ipv6-connection, should there be a possibility for multiple IPv6 addresses per service ? Should there be SLAAC for dynamic address allocation ?

Should there a choice on how to authenticate OSPFv3 either RFC 4552 or RFC 7166 ?

### Section 5

In the vxlan grouping, the modules writes `"Specifies the VXLAN access mode. By default, the peer mode is set to 'static-mode'.";` but I see nothing in the YANG module to set a default (unsure whether it is possible though).

## NITS (non-blocking / cosmetic)

s/Layer 2 VPN/layer-2 VPN/ ? same for layer 3 of course

****