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

[Vladimir Vassilev <[e-mail]>]

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).

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 [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.

Vladimir