Document: draft-ietf-netmod-sub-intf-vlan-model Title: Sub-interface VLAN YANG Data Models Reviewer: Darren Dukes Review result: Ready with Issues
I've been asked to do an early review of draft‑ietf‑netmod‑sub‑intf‑vlan‑model by int-dir. The following are my observations. Document: draft‑ietf‑netmod‑sub‑intf‑vlan‑model‑17 Overview: This document defines a YANG data model for configuring sub-interfaces with VLAN encapsulation on network devices. It includes models for classifying incoming frames based on VLAN tags and rewriting tags on egress frames. The model supports flexible encapsulation, including single and double VLAN tagging, and allows for asymmetric tagging behavior between ingress and egress directions. Review Disposition: The document is well written and mostly complete. I've reviewed it and identified several issues/questions that may impact consistent implementation across different vendors, but see no major issues that would impact the document's progression. ## 1. Issues ### 1.1 Normative Consistency Issues I noticed at least 10 instances where RFC 2119 keywords are not used but are required to avoid ambiguity in implementation. Some examples are: #### Section 4 - Interface Flexible Encapsulation Model - Current: "Ingress frames that do not match the encapsulation are dropped and counted against the 'in-discard-unknown-encaps' counter" - Suggest: "Ingress frames that do not match the encapsulation MUST be dropped and MUST be counted against the 'in-discard-unknown-encaps' counter" - Current: "Egress frames MUST conform to the encapsulation." - OK #### Section 5 - VLAN Encapsulation YANG Module - Current: "Only frames matching the classification configured on a sub-interface/interface are processed on that sub-interface/interface." - Suggest: "Frames matching the classification configured on a sub-interface/interface MUST be processed on that sub-interface/interface." The authors should do a complete pass through all description text in both YANG modules to ensure all behavioral requirements use appropriate RFC 2119 keywords. ### 1.2 Classification precedence is under-specified The document says "If a frame could be classified to multiple sub-interfaces then they get classified to the sub-interface with the most specific match." However, "most specific match" is not completely defined. Some examples are given but they are not exhaustive. For example, if one sub-interface matches on a single VLAN tag and another matches on both tags, the latter is more specific. What if both match the same number of tags but differ in tag values/ranges (i think this is possible) how is more specific determined in that case? Suggest: Add a formal definition of "most specific match" including tie-breaker rules to ensure deterministic behavior. ### 1.3 Ambiguity around tag‑stack depth and match‑exact‑tags. The model states that it matches and rewrites a tag stack of up to two tags (section 4, paragraph 3). In the flexible VLAN‑tagged case, a leaf match‑exact‑tags indicates whether extra VLAN tags beyond those explicitly matched are permitted. When this leaf is absent, the description implies that additional 802.1Q tags may follow the matched tags. This seems inconsistent with the stated two‑tag limit. Are devices expected to ignore any extra tags during classification? How does this interact with the rewriting operation (which only operates on the outermost one or two tags)? For implementations to behave consistently, the draft should clarify the classification rules with respect to match-exact-tags being set or not when additional tags are present. ### 1.4 Feature interactions are not fully defined. The module defines three features: flexible‑rewrites, asymmetric‑rewrites and dot1q‑tag‑rewrites. If I understand this correctly: - the rewrite container is guarded by flexible‑rewrites - the presence of dot1q‑tag‑rewrite is guarded by dot1q‑tag‑rewrite. - the asymmetrical case is guarded by asymmetric‑rewrites. But can't tell if dot1q‑tag‑rewrites implies support for both symmetrical AND asymmetric rewrites, or if implementations must also support the other two features? Furthermore, the module defines pop‑tags and push‑tags outside any if‑feature statements within the dot1q‑tag‑rewrite grouping. Can an implementation set flexible‑rewrites but disable dot1q‑tag‑rewrites, leading to a rewrite container with no child statements? ### 1.5 Default encapsulation container local-traffic-default-encaps allows specifying default tags for locally sourced traffic when the match criteria include ranges or any. However, the draft does not describe if/when this container is mandatory. For instance 1. if the match is a range of VLANs and no default is configured, how should locally originated frames be tagged? 2. if match‑exact‑tags is set, does the default still apply? Is there some default behavior i've missed? ### 1.6 Handling of VLAN ID 0 and 4095. ieee802-dot1q-types.yang defines vlan-id as a range from 1 to 4094. Are there no cases where filtering or rewrite might need to handle VLAN ID 0 (priority tagged) or 4095 (reserved)? _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
