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.