Hi Alia, authors,
Separately when doing the NMDA conversion on the VRRP module, I noted
that it is directly augmenting the "/interfaces-state" container (rather
than "/interfaces-state/interface" directly with "VRRP-global"
container, which looked a bit odd to me (and broke my conversion tool ;-).
E.g.
augment /if:interfaces-state:
+--ro vrrp-global
+--ro virtual-routers? uint32
+--ro interfaces? uint32
+--ro statistics
+--ro discontinuity-datetime? yang:date-and-time
+--ro checksum-errors? yang:counter64
+--ro version-errors? yang:counter64
+--ro vrid-errors? yang:counter64
+--ro ip-ttl-errors? yang:counter64
This naively seems like the wrong place to me, and I think that it would
be better to place this either as a top level "vrrp" container, or
perhaps put under the routing tree (e.g.
/routing/control-plane-protocols/vrrp).
I would have thought that putting this directly under
the/interfaces-state container would mean that the /interfaces-state
container could hold an interleaved mix of interface list entries and
the vrrp-global container!?!
E.g. I think that with the model the existing design then this following
XML would be allowed - cc Martin in case I am wrong :-)
<interfaces-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>down</admin-status>
<oper-status>down</oper-status>
...
</interface>
<vrrp-global>
....
</vrrp-global>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
....
</interface>
<interface>
<name>eth1.10</name>
<type>ianaift:l2vlan</type>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
....
</interface>
</interfaces-state>
Thanks,
Rob
On 20/09/2017 17:35, Alia Atlas wrote:
As is customary, I have done my AD review of
draft-ietf-rtgwg-yang-vrrp-04. First, I would like to thank the
authors, Xufeng, Athanasios, Ravi, Acee,and Mingui, as well as the WG
for their work on this draft. It is clear and well-written.
My one issue is that it does not conform to the NMDA guidelines. I
know that the transformation can be done largely programmatically -
and Acee & Xufeng are quite familiar with the details. I've also cc'd
Rob Wilton who has some tooling to potentially help.
From the shepherd's report, I understand that there is an
implementation. That implies that the existing model should be in the
appendix.
I would be delighted to forward this draft to IETF Last Call (and my
apologies for the long delay in review) after it has been updated.
Thanks,
Alia
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
