2 modules in this draft: - ietf-ac-svc@2023-11-13.yang - ietf-bearer-svc@2023-11-13.yang YANG compiler errors or warnings (pyang 2.6.0, yanglint 3.1.0) - No compiler errors or warnings for tree outputs/instance-data validation Summary: This is a last-call review to a previous early review of these related modules from 2024-01-10. For the most part the modules are in good shape but there have been some changes needing clarification (below) between the -03 and -14 versions of the draft. These modules were reviewed and validated (stub instance-data) in conjunction with draft-ietf-opsawg-teas-common-ac-12 General comments on the modules: - ietf-bearer-svc: There is a top-level container added named `locations`. Should this not be a keyed list rather? In addition, no need to repeat the prefix `location-` in `location-name` as we already know this is a list of locations. `name` is sufficient here. - ietf-bearer-svc: Is the `type` for the leaf-list `bearer-lag-member` correct in referencing another bearer is all? (Same as bearer-parent-ref) - Nit: Feel free to update the revision dates with each publish - Nit: ietf-ac-svc: Why not remain consistent and name `s/child-ac-ref/ac-child-ref/` to align with the other `ac-hierarchy` leaf-list of `ac-parent-ref`? - Nit: ietf-ac-svc: container `bgp-max-prefix` is already nested under BGP. No reason to prefix as such so if you want to encapsulate in a container for future growth, I would suggest something like `./prefix-limit/max-prefixes`. In addition, is this fine to be this generic and not per AFI/SAFI? - Nit: ietf-bearer-svc: For the addition of the 2 new identities (syncPHY-type, syncE), is there any reason to diverge casing? - Nit: ietf-bearer-svc L#154 `s/Reusabel/reusable/` Example Validated Instance Data: Features enabled: * ietf-vpn-common:ipv4,ipv6,rtg-bgp,rtg-vrrp,rtg-rip,rtg-isis,rtg-ospf,bfd,encryption,inbound-bw,outbound-bw,qos,placement-diversity * ietf-ac-common:layer2-ac,layer3-ac,server-assigned-reference KC1 KC1 Description 131001 hmac-sha-512 AGP1 SPP1 SPP2 vpn-common:ethernet-type AGP2 SPP1 1.1.1.1 2.2.2.2 31 ac-common:static-address
ID1 10.1.1.1
2001:db8:1000::1 2001:db8:ffff::ffff 127 ac-common:static-address
ID1 2001:db8:dead::beef
RP1 vpn-common:bgp-routing EPI5 vpn-common:import-export PG1 65000 65001 vpn-common:ipv4 10.1.1.1 true true KC1 N1 SR1 10.2.2.2 10.1.1.1 PG1 vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z RP2 vpn-common:vrrp-routing vpn-common:ipv4 RP3 vpn-common:rip-routing vpn-common:ipv4 RP4 vpn-common:isis-routing vpn-common:ipv4 49.0000.0001.0000 RP5 vpn-common:ospf-routing vpn-common:ipv4 0.0.0.0 100 RP6 vpn-common:static-routing 2001:db8:1234:ffff::/64 LT1 ac-common:local-link SID1 10.1.1.1 10.2.1.1 EPI3 180 vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z true layer3 KC1 9000 vpn-common:bw-per-service 10000 10000 10000 10000 10000 10000
vpn-common:pop-diverse GID1 AC1 CUSTOMER1 Attachment Circuit #1 2023-12-30T14:52:51.353Z 2025-12-30T00:00:00.000Z 2023-12-30T15:02:10.003Z ac-common:nni PSID1 AGP2 AC2 AC3 GID1 ac-common:primary vpn-common:l3vpn SID1 SAR1 SPP1 2001:db8::1 2001:db8::2 128 ac-common:static-address EPI2 vpn-common:both EPI4 AC2 AC3
EPI1 EPI2 EPI3 EPI4 EPI5 SPP1 SPP2 CN1 ac-common:nni 65000 1000 LOC1 network-termination-hint G1 vpn-common:pop-diverse vpn-common:pe-diverse B1 Description for B1 G1 Op comment B2 B2 true true syncE LR1 site-and-device-id devid1 SJC01
555 Anystreet
95123 CA San Jose US
ethernet AC1 2023-12-30T14:52:51.353Z 2025-12-30T00:00:00.000Z 2023-12-30T15:02:10.003Z vpn-common:admin-up 2023-12-30T15:02:11.353Z vpn-common:op-up 2023-12-30T15:02:11.353Z
B2