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

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 15 Jun 2017 13:59:30 +0200

Hello,

There is a problem with a mutually exclusive 'when' statements for the 
/interfaces/inteface/encapsulation container in 
[email-masked] 
(draft-ietf-netmod-intf-ext-yang-04) and 
[email-masked]  models causing error with our 
validation tools.

As defined in [email-masked]:

...

     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-masked]:

   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.

Vladimir

On 03/13/2017 08:38 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
>
>          Title           : Sub-interface VLAN YANG Data Models
>          Authors         : Robert Wilton
>                            David Ball
>                            Tapraj Singh
>                            Selvakumar Sivaraj
> 	Filename        : draft-ietf-netmod-sub-intf-vlan-model-01.txt
> 	Pages           : 27
> 	Date            : 2017-03-13
>
> Abstract:
>     This document defines YANG modules to add support for classifying
>     traffic received on interfaces as Ethernet/VLAN framed packets to
>     sub-interfaces based on the fields available in the Ethernet/VLAN
>     frame headers.  These modules allow configuration of Layer 3 and
>     Layer 2 sub-interfaces (e.g. attachment circuits) that can
>     interoperate with IETF based forwarding protocols; such as IP and
>     L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The
>     sub-interfaces also interoperate with VLAN tagged traffic orginating
>     from an IEEE 802.1Q compliant bridge.  Primarily the classification
>     is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
>     also has support for matching on some other layer 2 frame header
>     fields and is designed to be extensible to match on other arbitrary
>     header fields.
>
>     The model differs from an IEEE 802.1Q bridge model in that the
>     configuration is interface/sub-interface based as opposed to being
>     based on membership of an 802.1Q VLAN bridge.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Jun 2017 17:18:22 +0100

Hi Vladimir,

Thanks for raising this.

> '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

> .

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 16 Jun 2017 13:42:45 +0200

On 06/15/2017 06:18 PM, Robert Wilton wrote:

>> There is a problem with a mutually exclusive 'when' statements for 
>> the /interfaces/inteface/encapsulation container in 
> encapsulation when statement replacing the l2vlan, since 
> ethSubInterface derived from l2vlan anyway.
>
> Thanks,
> Rob
The "TODO" text you have placed in 
[email-masked] 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-masked] and 
[email-masked] 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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Jun 2017 14:51:13 +0100

On 16/06/2017 12:42, Vladimir Vassilev wrote:
> [email-masked] under the when statement "TODO 
> - Should we introduce an abstract type to make this extensible to new 
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.

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

> 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