A Network YANG Data Model for Attachment Circuits
draft-ietf-opsawg-ntw-attachment-circuit-16

[Ballot comment]
# Internet AD comments for draft-ietf-opsawg-ntw-attachment-circuit-15
CC @ekline

* 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

### S5.4

* Should there be any mention of Provider Backbone Bridging (PBB) in here,
  or would that go somewhere else as a network operations implementation
  detail?

[Ballot comment]
Thanks to Russ Housley for his GenArt review (even if this was mistaken for a secdir review).  I agree with his opinions on Security Considerations, but since that section is completely mandated a template, there is no point in commenting.

(note I'm not sending this message to the list).

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-ntw-attachment-circuit-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-ac-ntw
URI: urn:ietf:params:xml:ns:yang:ietf-ac-ntw
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-ac-ntw
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-ntw
Prefix: ac-ntw
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-12-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-ntw-attachment-circuit@ietf.org, kszarkowicz@juniper.net, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Network YANG Data Model for Attachment Circuits) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A Network
YANG Data Model for Attachment Circuits'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-12-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a network model for attachment circuits.  The
  model can be used for the provisioning of attachment circuits prior
  or during service provisioning (e.g., VPN, Network Slice Service).  A
  companion service model is specified in the YANG Data Models for
  Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf-
  opsawg-teas-attachment-circuit).

  The module augments the base network ('ietf-network') and the Service
  Attachment Point (SAP) models with the detailed information for the
  provisioning of attachment circuits in Provider Edges (PEs).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/



No IPR declarations have been submitted directly on this I-D.

I have been asked to do the shepherd's review for draft-ietf-opsawg-ntw-attachment-circuit document, with the intended traget status "Standards Track". "Standards Track" is the appropriate track for drafts defining Yang models, so it is appropriate for this draft.

In general, the document is in a good shape. It is clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director. I believe this draft (in combination with 3 other AC related drafts: I-D.ietf-opsawg-teas-common-ac, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-opsawg-ac-lxsm-lxnm-glue) for AC provisioning, which decouples the bearer from the services itself is very useful for service/AC provisioning, including use cases like for example network slicing or services with SLA provisioning.

Feedback in the WG mailing list for this draft is positive, and there is a broad agreement for support of this draft, without strong controversy or extreme discontent.

The OPSA WG AC work was discussed externally and is cross-referenced by 3GPP (3GPP TS 28.541 Rel 18.5 onwards), O-RAN Alliance (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has undergone RTGDIR LC, as well as Yangdoctors early reviews, which declared the draft to be ready.

The IPR call for the draft was issued, with responses from relevant parties (authors, contributors). Authors/contributors agreed to be listed in the draft. There are five authors listed in the draft, which adheres to general IETF rule fo maximum five authors.

One of the normative reference [IEEE802.1Qcp] might not be freely available to anyone. However, typically, the community have sufficient access to review this reference. Two other normative references are IETF drafts. However, undergoing WG LC at the same time as this draft.

Publication of this draft will not change status of existing RFCs. All aspects of the draft requiring IANA assignments are associated with the appropriate reservations in IANA registries. Any referenced IANA registries have been clearly identified. Each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).



I have just some nits and some minor clarification questions.






Section 1

Figure 1 must be corrected in html version of the document (near right SAP in PE1 and two right SAPs in PE4). In text version this figure is OK.


Section 4

s/Typically, AS Border Routers (ASBRs) of each network is directly connected to an ASBR of a neighboring network/Typically, AS Border Routers (ASBRs) of each network are directly connected to ASBRs of a neighboring network

Figure 4 in html version connects network 2# and Network 3#, while in text version doesn't interconnect these networks. Must be fixed in html version.


Section 5.1

s/a SAP is an abstraction of the network reference points/a SAP is an abstraction of the network reference point

s/Indicate for each individual ACs one or a subset of the CEs/Indicate for each individual AC one or a subset of the CEs


Section 5.3.

IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long (in the model uint16 is used) -> this must be fixed in the model

IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.4

Model covers l2-tunnel-types like pseudowire, vpls or vxlan. What about EVPN?



Section 5.5

For IPv6 two address allocation schemes are mentioned: dynamic and static. What, if automatically assigned IPv6 link-local addresses are used/desired? I think, some discussion about modelling IPv6 link-local addresses would be beneficial.

Section 5.6.3

IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.6.4

IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long (in the model uint16 is used) ->  this must be fixed in the model

Another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.9

I would add a short note, what units (bps, Bps, bits, Bytes) are used for BW (CIR/PIR/EIR) and burst sizes (CBS/EBS/PBS), to avoid any interop problems.

I have been asked to do the shepherd's review for draft-ietf-opsawg-ntw-attachment-circuit document, with the intended traget status "Standards Track". "Standards Track" is the appropriate track for drafts defining Yang models, so it is appropriate for this draft.

In general, the document is in a good shape. It is clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director. I believe this draft (in combination with 3 other AC related drafts: I-D.ietf-opsawg-teas-common-ac, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-opsawg-ac-lxsm-lxnm-glue) for AC provisioning, which decouples the bearer from the services itself is very useful for service/AC provisioning, including use cases like for example network slicing or services with SLA provisioning.

Feedback in the WG mailing list for this draft is positive, and there is a broad agreement for support of this draft, without strong controversy or extreme discontent.

The OPSA WG AC work was discussed externally and is cross-referenced by 3GPP (3GPP TS 28.541 Rel 18.5 onwards), O-RAN Alliance (O-RAN.WG9.XTRP-MGT.0-R003-v08.00 onwards) and TEAS WG draft-ietf-teas-ietf-network-slice-nbi-yang. This draft has undergone RTGDIR LC, as well as Yangdoctors early reviews, which declared the draft to be ready.

The IPR call for the draft was issued, with responses from relevant parties (authors, contributors). Authors/contributors agreed to be listed in the draft. There are five authors listed in the draft, which adheres to general IETF rule fo maximum five authors.

One of the normative reference [IEEE802.1Qcp] might not be freely available to anyone. However, typically, the community have sufficient access to review this reference. Two other normative references are IETF drafts. However, undergoing WG LC at the same time as this draft.

Publication of this draft will not change status of existing RFCs. All aspects of the draft requiring IANA assignments are associated with the appropriate reservations in IANA registries. Any referenced IANA registries have been clearly identified. Each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).



I have just some nits and some minor clarification questions.






Section 1

Figure 1 must be corrected in html version of the document (near right SAP in PE1 and two right SAPs in PE4). In text version this figure is OK.


Section 4

s/Typically, AS Border Routers (ASBRs) of each network is directly connected to an ASBR of a neighboring network/Typically, AS Border Routers (ASBRs) of each network are directly connected to ASBRs of a neighboring network

Figure 4 in html version connects network 2# and Network 3#, while in text version doesn't interconnect these networks. Must be fixed in html version.


Section 5.1

s/a SAP is an abstraction of the network reference points/a SAP is an abstraction of the network reference point

s/Indicate for each individual ACs one or a subset of the CEs/Indicate for each individual AC one or a subset of the CEs


Section 5.3.

IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long (in the model uint16 is used) -> this must be fixed in the model

IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.4

Model covers l2-tunnel-types like pseudowire, vpls or vxlan. What about EVPN?



Section 5.5

For IPv6 two address allocation schemes are mentioned: dynamic and static. What, if automatically assigned IPv6 link-local addresses are used/desired? I think, some discussion about modelling IPv6 link-local addresses would be beneficial.

Section 5.6.3

IS-IS has 'mode', while OSPF doesn't have 'mode'. In both cases (IS-IS and OSPF), 'mode' (e.g. active/passive) is meaningful. Further, another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.6.4

IS-IS link metric is 24-bit, while IS-IS path/prefix metric is 32-bit long (in the model uint16 is used) ->  this must be fixed in the model

Another type of interface mode is e.g. point-to-point, broadcast, ... Again, in both cases (IS-IS and OSPF) this is meaningful. For model consistency, 'mode' should be included in both IS-IS and OSPF, or excluded in both IS-IS and OSPF.


Section 5.9

I would add a short note, what units (bps, Bps, bits, Bytes) are used for BW (CIR/PIR/EIR) and burst sizes (CBS/EBS/PBS), to avoid any interop problems.