Hi Med, Looks good now. From my perspective, no further changes are required.
Cheers, Krzysztof On May 15, 2024, at 17:08, mohamed.boucad...@orange.com wrote: [External Email. Be cautious of content] Hi Krzysztof, Thank you for the review. Can you please check and let us know if any further change is needed: https://urldefense.com/v3/__https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-ntw-attachment-circuit&url_2=https:**Aboucadair.github.io*attachment-circuit-model*draft-ietf-opsawg-ntw-attachment-circuit.txt*__;Ly8vLz8!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFF6VwdZY0$ Thanks. Please see inline. Cheers, Med -----Message d'origine----- De : Krzysztof Szarkowicz <kszarkowicz=40juniper....@dmarc.ietf.org<mailto:kszarkowicz=40juniper....@dmarc.ietf.org>> Envoyé : mercredi 15 mai 2024 14:41 À : Joe Clarke (jclarke) <jcla...@cisco.com<mailto:jcla...@cisco.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : opsawg-cha...@ietf.org<mailto: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://urldefense.com/v3/__https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-circuits-saps-00)IETF*117__;Iw!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFF1qqf14p$ ) and (https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00__;!!NEt6yMaO-gk!DkQJWv6uzEQEP65hEQsVEdtBOKjK5LJ7hLQTVJeas9NBcwHpETrWQ_i9pqj-nnpCPb5fUucenj425kmWHJwdDnvFFy9ou1_8$ ). 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<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto: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
