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