Resending to the WG list
> On May 2, 2024, at 11:26, Krzysztof Szarkowicz <kszarkow...@juniper.net> > wrote: > > Hi, > > > 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. > > > > > > Thanks, > Krzysztof > _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
