Hi Krzysztof, Thank you for the review.
Can you please check and let us know if any further change is needed: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ntw-attachment-circuit&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-ntw-attachment-circuit.txt? Thanks. Please see inline. Cheers, Med > -----Message d'origine----- > De : Krzysztof Szarkowicz > <kszarkowicz=40juniper....@dmarc.ietf.org> > Envoyé : mercredi 15 mai 2024 14:41 > À : Joe Clarke (jclarke) <jcla...@cisco.com>; opsawg@ietf.org > Cc : opsawg-cha...@ietf.org > Objet : [OPSAWG]Shepherd review for draft-ietf-opsawg-ntw- > attachment-circuit > > > 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. [Med] I would mention in the writeup the following as well: To ensure cross-WG reviews: * The call for adoption and WGLC for the document were also cced to TEAS WG. * Progress status of the specification effort was shared with TEAS WG during IETF#116 (https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00)IETF#117) and (https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00). > > > > 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. > > [Med] Tweaked the figure so the aavg rendering works. > > > > 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. > > [Med] ACK. > > > > 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 > > [Med] ACK > > > > 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. > > [Med] Good catch. Changed the model to explicitly refer to active/passive for both ospf and isis. Thanks. > > > > Section 5.4 > > > > Model covers l2-tunnel-types like pseudowire, vpls or vxlan. > What about EVPN? > > [Med] We restricted the scope to what is supported in the L3NM/L2NM. The model can be augmented in the future if needed. > > > > > > 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. > > [Med] Not sure what we can add here given that a link-local address is required anyway per interface and will be automatically generated. > > 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. > > [Med] Fixed. > > > > 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. > > > > [Med] Added the units to echo those that are mentioned in the data model. > > > > > > > > Thanks, > > Krzysztof > > > > _______________________________________________ > OPSAWG mailing list -- opsawg@ietf.org > To unsubscribe send an email to opsawg-le...@ietf.org ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
