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
