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 <[email protected]> On Behalf Of Stephen Cheng Sent: 05 November 2019 02:30 To: [email protected] 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, [email protected]<mailto:[email protected]> 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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
