On 16/06/2017 12:42, Vladimir Vassilev wrote:
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).
Yes, my original idea was to define more types like "ethSubInterface"
that derive from base iftypes like l2vlan. However, this doesn't actual
solve my goal of allowing the models to be more extensible, and instead
I think that the solution might almost be the reverse.
We could define some property identities like:
- sub-interface,
- ethernet-like,
- point-to-point,
- multicast/broadcast,
- physical,
- virtual
We would then update iana-if-type.yang to also derive from these new
property identities, which is a backwards compatible change.
So, for example, in the other discussion about interface statistics, the
broadcast/multicast counters could be conditional as to whether the
iftype inherits the multicast/broadcast property.
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?
I was thinking that every sub-interface would probably always need an
encapsulation, because it necessary to know how to demultiplex packets
from the parent interface to the child.
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.
I will add examples to the draft, and updated before the next IETF.
Others have raised this as well.
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.
I'll think this over. I wanted to enable maximum flexibility as to what
devices implement, although of course feature keywords is also an option.
Thanks,
Rob
Vladimir
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
