On 06/15/2017 06:18 PM, Robert Wilton wrote:
Hi Vladimir,
Thanks for raising this.
On 15/06/2017 12:59, Vladimir Vassilev wrote:
Hello,
There is a problem with a mutually exclusive 'when' statements for
the /interfaces/inteface/encapsulation container in
[email protected]
(draft-ietf-netmod-intf-ext-yang-04) and
[email protected] models causing error with our
validation tools.
As defined in [email protected]:
...
container encapsulation {
when
"derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type,
'ianaift:ieee8023adLag') or
derived-from-or-self(../if:type, 'ianaift:pos') or
derived-from-or-self(../if:type,
'ianaift:atmSubInterface') or
derived-from-or-self(../if:type, 'ethSubInterface')" {
...
and here augmented in [email protected]:
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" {
when "../if:type = 'ianaift:l2vlan' and
derived-from-or-self(../if-cmn:forwarding-mode,
'if-cmn:network-layer')" {
Short term fix I use is to add "or derived-from-or-self(../if:type,
'ianaift:l2vlan')" to the ietf-interfaces-common definition.
I suspect that probably the reverse fix is probably better.
I.e. add derived-from-or-self(../if:type, 'ethSubInterface' to the
encapsulation when statement replacing the l2vlan, since
ethSubInterface derived from l2vlan anyway.
Thanks,
Rob
The "TODO" text you have placed in
[email protected] under the when statement "TODO -
Should we introduce an abstract type to make this extensible to new
interface types, or vendor specific interface types?" for me is a hint
that a better long term solution is under consideration (replacing the
list of technology specific references).
My understanding is that only the subset of all sub-interfaces based on
encapsulation will have encapsulation container. Identity derived from
sub-interface -> encapsulation-sub-interface could be the abstract type,
right?
Examples of practical use of the sub-interface abstraction and
/interfaces/interface/encapsulation for the most common cases (e.g.
l2vlan bridge configuration) is something that should be presented. If
not as part of the draft on the mailing list as proof of concept.
IMO [email protected] and
[email protected] along with the
/interfaces/interface/encapsulation container definition can be merged
into single module called ietf-sub-intf-vlan.yang where the
encapsulation-sub-interface identity and the encapsulation container are
defined.
Vladimir
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
