Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt

[Robert Wilton <[e-mail]>]

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 
>>> [e-mail] 
>>> (draft-ietf-netmod-intf-ext-yang-04) and 
>>> [e-mail]  models causing error with our 
>>> validation tools.
>>>
>>> As defined in [e-mail]:
>>>
>>> ...
>>>
>>>     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 [e-mail]:
>>>
>>>   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 
> [e-mail] 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 [e-mail] and 
> [e-mail] 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
>
> .
>