Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Acee,

No, not yet.  But I have added an issue to track this, so this doesn’t get forgotten.

I think that probably all of the published IEEE standard YANG modules should be added to the search path.

Thanks,
Rob


From: Acee Lindem (acee) <[e-mail]>
Sent: 05 November 2019 12:01
To: Rob Wilton (rwilton) <[e-mail]>; Stephen Cheng <[e-mail]>; [e-mail]
Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Rob,

Any update on getting the YANG tools issue resolved with the ieee802-dot1q-types.yang model in the search path?

Thanks,
Acee

From: netmod <[e-mail]<mailto:[e-mail]>> on behalf of "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 5, 2019 at 4:50 AM
To: Stephen Cheng <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

Hi Stephen,

I’ve just posted an updated version of this document.

The document is in WGLC, and I’m hoping that I can address any outstanding comments (including yours) over the next couple of weeks.

Kind regards,
Rob


From: netmod <[e-mail]<mailto:[e-mail]>> On Behalf Of Stephen Cheng
Sent: 05 November 2019 02:30
To: [e-mail]<mailto:[e-mail]>
Subject: [netmod] Mail regarding draft-ietf-netmod-sub-intf-vlan-model


Authors  of draft-ietf-netmod-sub-intf-vlan-model,

I noticed that the draft has expired, is there any intention to publish a new version in new future?

Secondly, I notice a possible problem in the examples in section 7.1/7.2.

In current (expired) draft, in section 7.1. we have in the example

       <interface>
         <name>eth0.1</name>
         <type>ianaift:l2vlan</type>
         <if-cmn:parent-interface>eth0</if-cmn:parent-interface>
         <if-cmn:encapsulation>
           <dot1q-vlan
            xmlns="urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan">
             <outer-tag>
               <tag-type>dot1q-types:s-vlan</tag-type>
               <vlan-id>10</vlan-id>
             </outer-tag>

The type of of eth0.1 interface is defined as a l2vlan.

L2vlan is defined in RFC 7224 as follows, which means that l2vlan does not derive from ethernetCsmacd nor ieee8023adLag nor ethSubInterface:

identity l2vlan {

       base iana-interface-type;

       description

         "Layer 2 Virtual LAN using 802.1Q.";

     }


However in the current (expired) draft, [e-mail]<mailto:[e-mail]> says

     /*

      * Add support for the 802.1Q VLAN encapsulation syntax on layer 3

      * terminated VLAN sub-interfaces.

      */

     augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +

             "if-cmn:encaps-type" {

       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,

                                 'if-cmn:ethSubInterface')" {

         description

           "Applies only to Ethernet-like interfaces and

            sub-interfaces";

       }



       description

         "Augment the generic interface encapsulation with an

          basic 802.1Q VLAN encapsulation for sub-interfaces.";



       /*

        * Matches a single VLAN Id, or a pair of VLAN Ids to classify

        * traffic into an L3 service.

        */

       case dot1q-vlan {

         container dot1q-vlan {

           must

             'count(../../if-cmn:forwarding-mode) = 0 or ' +

             'derived-from-or-self(../../if-cmn:forwarding-mode,' +

                                   '"if-cmn:layer-3-forwarding")' {

               error-message

                 "If the interface forwarding-mode leaf is set then it

                  must be set to an identity that derives from

                  layer-3-forwarding";



               description

                 "The forwarding-mode leaf on an interface can

                  optionally be used to enforce consistency of

                  configuration";

             }





           description

             "Match VLAN tagged frames with specific VLAN Ids";

           container outer-tag {

             must

               'tag-type = "dot1q-types:s-vlan" or ' +

               'tag-type = "dot1q-types:c-vlan"' {



               error-message

                   "Only C-VLAN and S-VLAN tags can be matched";



               description

               "For IEEE 802.1Q interoperability, only C-VLAN and

                    S-VLAN tags can be matched";

             }



             description

               "Classifies traffic using the outermost VLAN tag on the

                frame.";



             uses dot1q-types:dot1q-tag-classifier-grouping;

           }


As such if the type of eth 0.1 is l2vlan should outer-tag etc be available to this interface, since l2vlan would not satisfy the “when” clause?

I believe there are similar issues for other interfaces too in section 7.1/7.2 examples.

Warm regards,
Stephen Cheng