From: Mahesh Jethanandani <[email protected]> Sent: 23 September 2025 01:43
Hi Rob, I will proceed with the draft as-is. In the next update, if you can tag the examples as suggested with <CODE START> and <CODE END>, it would be great. <tp> Um. But 'draft-ietf-netmod-rfc8407bis-28' fails to say what the code markers for examples should be, the same as for module code or something else. I note that you do not use the CODE BEGINS and CODE ENDS tags that apply to module code and am unclear if you are saying that example code should use something close but different. Tom Petch Thanks. On Sep 3, 2025, at 7:50 AM, Reshad Rahman <[email protected]<mailto:[email protected]>> wrote: AFAIK this is fairly new. From 3.12 of 8407bis: In order to ease extraction and validation of examples, it is RECOMMENDED to use code markers. On Wednesday, September 3, 2025 at 07:42:45 AM EDT, Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: Hi Mahesh, We have just posted draft-ietf-netmod-intf-ext-yang-17 and draft-ietf-netmod-sub-intf-vlan-model-16. We think that these address all of your AD review comments except for (1): > Thanks for extensive and useful complete examples. It would be helpful if > these were tagged with <CODE START> and <CODE ENDS> tag to enable extraction > of them from the document and validate them against the model. I looked at other RFCs that had been published (although some may be a few years ago), and I didn’t see these CODE START/END tags for the examples, only the YANG modules, and hence I wasn’t sure that we should add them. Please let me know if you are happy to leave them how they are, or you still want me to change them. Kind regards, Rob From: Mahesh Jethanandani <[email protected]<mailto:[email protected]>> Date: Thursday, 31 July 2025 at 19:44 To: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Cc: NetMod WG <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] AD review of draft-ietf-netmod-intf-ext-yang-16 Hi Rob, Inline with [mj]. On Jul 30, 2025, at 7:59 AM, Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: Hi Mahesh, Please see inline … From: Mahesh Jethanandani <[email protected]<mailto:[email protected]>> Date: Wednesday, 30 July 2025 at 01:05 To: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Cc: NetMod WG <[email protected]<mailto:[email protected]>>, Scott Mansfield <[email protected]<mailto:[email protected]>> Subject: Re: AD review of draft-ietf-netmod-intf-ext-yang-16 Hi Rob, Following up on your responses. On Tue, Jul 15, 2025 at 9:55 AM Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: HI Mahesh, Thanks for the review. We have only given quick answers for the moment – Scott and I will need in Madrid (Tuesday morning) to meet/propose text and then give you more concrete answers and text proposals, so please expect a more detailed follow up. From: Mahesh Jethanandani <[email protected]<mailto:[email protected]>> Date: Saturday, 26 April 2025 at 00:19 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: NETMOD Group <[email protected]<mailto:[email protected]>> Subject: AD review of draft-ietf-netmod-intf-ext-yang-16 Hi Authors, Thanks first of all for working on this document. It has been a long time coming. Please see my comments on the document, which I hope will go towards improving the document. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- Section 2.5, paragraph 0 > A maximum frame size configuration leaf (max-frame-size) is provided > to specify the maximum size of a layer 2 frame that may be > transmitted or received on an interface. The value includes the > overhead of any layer 2 header, the maximum length of the payload, > and any frame check sequence (FCS) bytes. If configured, the max- > frame-size leaf on an interface also restricts the max-frame-size of > any child sub-interfaces, and the available MTU for protocols. If we are providing the ability to configure maximum frame size, should we providing a counter for packets that are discarded because the max size was exceeded? This one probably needs a bit more thought/discussion. For Ethernet interfaces, there is already the in-error-oversize-frames counter defined in 802.3.2. For other interfaces, I suspect that this would mostly be caught by an MRU/MTU check. Hence, we don’t think that adding another counter is the right approach because it likely wouldn’t be enforced. Normally, this would be handled at other forwarding layers, if required. Ok. On second thought, I do agree that this can only be counted at the physical interface level, and if it is being done as part of the 802.3 YANG model, we should be good. Section 2.6, paragraph 0 > The sub-interface feature specifies the minimal leaves required to > define a child interface that is parented to another interface. I find the definition of sub-interface to be under specified. For example, if an implementation wants to enable configuration of a sub-interface that takes a ip-address, how would they go about it? And how would that relationship be tied to the parent-interface definition here? An example that shows how this can be enabled can go a long way in making this draft very useful for addressing a very common implementation. Ah, yes. You are right, this document doesn’t contain an example, but draft-ietf-netmod-sub-intf-vlan-model does. Possibly referencing that document as an example would be helpful. Or the example could be reproduced in this document as well. We’ll also check whether any more descriptive prose or additional text in the model is needed. I took a look at the example(s), but I it does not quite cover what I had in mind. What you have as an example is subinterfaces with vlan tag, with the IP address is configured on the interface, not on the subinterface. One of the more common implementation that I have seen is where the IP address is configured on the subinterface as follows. I do not see how this model covers that use case. The example in 7.1 of draft-ietf-netmod-sub-intf-vlan-model covers configuring an IPv6 address on the sub-interface. Specifically, in the JSON below, the name of the sub-interface is “eth0.1” which is a sub-interface of “eth0”, and as you can see the IETF IPv6 configuration model just works with sub-interfaces without requiring any changes. This will be the same for any IETF YANG configuration model that augments "/if:interfaces/if:interface". This is because in this YANG model a sub-interface *is* also an interface, like Ethernet, LAG or tunnel interfaces, …. Hence interface configuration works the same way for both interfaces and sub-interfaces. Neat, no? ;-) [mj] Ahh! I missed that. I now understand the statement that subinterfaces (and other interfaces such as bond) are nothing but another type of interface. It is neat indeed. { "name": "eth0.1", // This is a sub-interface in the /if:interfaces/if:interface list "type": "iana-if-type:l2vlan", "oper-status": "up", "statistics": { "discontinuity-time": "2023-12-15T09:04:00-05:00" }, "ietf-if-extensions:encapsulation": { "ietf-if-vlan-encapsulation:dot1q-vlan": { "outer-tag": { "tag-type": "ieee802-dot1q-types:s-vlan", "vlan-id": 10 }, "second-tag": { "tag-type": "ieee802-dot1q-types:c-vlan", "vlan-id": 20 } } }, "ietf-if-extensions:parent-interface": "eth0", // This is sub-interface’s parent interface (also in the interfaces list) "ietf-ip:ipv6": { "enabled": true, "forwarding": true, "address": [ { "ip": "2001:db8:11::1", // Configuring an IPv6 address on the sub-interface, exactly as you would on any other type of interface. "prefix-length": 48 } ] } }, interfaces interface X type ethernetCsmacd subinterface Y vlan vlan-id Y ipv4 address Z prefix-length A ipv6 address B prefix-length C subinterface D vlan vlan-id E ipv4 address F prefix-length G ipv6 address H prefix-length I I do realize that the issue is with ietf-ip and how it augments, i.e., an augmentation of the interfaces model, which essentially rules out IP addresses being configured under the subinterface. How would you propose we solve for that use case using this model? Already solved and illustrated in the example. The document introduces the concept of a sub-interface as a logical interface that handles a subset of the traffic received by the parent interface. However, it stops short of defining a container for it that could contain attributes specific to the sub-interface. As I see it, the sub-interface will need some kind of index or id that uniquely identifies it. That index or id can come in the form of VLAN. To configure the VLAN, the ietf-if-vlan-encapsulation model could be used except that it dot1q-vlan is at an interface level, not at a sub-interface level. Similarly, if an ip-address needs to configured, ietf-ip module could have been used, but like the vlanencapsulation, the IP address can only be specified at the interface level. This is common implementation, but this model and other related models fall short of supporting such an implementation. The key part of the design of this model is that a sub-interface is just a type of interface, which appears in the standard list of interfaces. E.g., you might have an entry called “Ethernet0/1” in the interfaces list, and an entry called “Ethernet0/1.1” in the interface list that represents a sub-interface of “Ethernet0/1”. It would have type l2vlan, a parent-interface of “Ethernet0/1”. Hence, the VLAN encapsulation would be configured under the “Ethernet0/1.1” entry in the interface list, as would the IP address, using the ietf-ip YANG model with no additional changes required. See my example above. I see ietf-ip augmenting the interfaces modules as follows: augment "/if:interfaces/if:interface" { description "IP parameters on interfaces. How would the subinterface be configured for IP address? See above. This just works for sub-interfaces as well. Your confusion may arise from the OpenConfig YANG models that do this differently, where sub-interfaces are not interfaces, and hence the models end up being more complex to handle that design decision. Please let me know if that clarifies or if a short call to explain would be helpful. [mj] I am good with the explanation. Thanks for providing it. At this point I will await an updated I-D with any changes we agreed upon for me to progress the draft. Cheers. Kind regards, Rob Cheers. Note, the approach in this draft differs from OpenConfig where a sub-interface is not an interface object, but a different object in the data model that exists in a different list under the interface. The benefit of the approach in this draft, is that all other models that add functionality or reference interfaces just work with sub-interfaces without needing any changes. If this document considers all the work of defining a sub-interface to be out-of-scope, it should remove this section and let another document define it. No, this using this draft and the dot1q draft (for the case of VLAN sub-interfaces) should be sufficient for configuring L2 and L3 VLAN sub-interfaces. They should also be sufficient for generically modelling other types of sub-interfaces, although other sub-interface specific fields may be required or useful (e.g., as per the draft-ietf-netmod-sub-intf-vlan-model that adds in the extra properties for VLAN sub-interfaces). Section 2.7, paragraph 1 > The forwarding mode leaf provides additional information as to what > mode or layer an interface is logically operating and forwarding > traffic at. The implication of this leaf is that for traffic > forwarded at a given layer that any headers for lower layers are > stripped off before the packet is forwarded at the given layer. > Conversely, on egress any lower layer headers must be added to the > packet before it is transmitted out of the interface. I am assuming that 'forwarding-mode' applies to both the physical as well as the logical (sub-interface) level. Can that be made clear? Also, if we are identifying the forwarding mode, can it support counters related to them, e.g., VLAN discards or IP discards etc.? For the first part of your question, we could do, but that might be best done in the example, rather than in the normative text. Explicitly calling out that this configuration also applies to sub-interface may make it appear to be special in some way, as opposed to all regular interface augmentations also applying to sub-interfaces because they are just another type of interface. For your second question, I think that it would be best covered by forwarding specific counters. E.g., IETF interfaces already defined an in-unknown-protos. An IP forwarding model should have an invalid destination IP address, the L2VPN model could report drops due to unknown MAC address (or perhaps VLAN) depending on whether the MAC address are dynamically learned or not. Section 4, paragraph 9 > "WG Web: <http://tools.ietf.org/wg/netmod/> Please update the link to the datatracker link. Will do, thanks. Section 4, paragraph 26 > presence > "Enable interface link flap dampening with default settings > (that are vendor/device specific)."; Not clear on how "default settings" can be vendor/device specific? Are default values not specified in the model with the vendor/device overriding the default values if necessary? We think that it may be hard to get exact agreement on what these default settings should be because they are not defined by any IETF protocol and are likely to differ by vendor. In these sorts of cases the OpenConfig group, who have more deployment experience, seem to have reached the conclusion that it is better to leave such defaults out of the models. As you say, this still leaves the choice to the vendors to augment in their default values if they wish. Section 4, paragraph 26 > leaf half-life { > type uint32; > units seconds; > description > "The time (in seconds) after which a penalty would be half > its original value. Once the interface has been assigned > a penalty, the penalty is decreased at a decay rate > equivalent to the half-life. For some devices, the > allowed values may be restricted to particular multiples > of seconds. The default value is vendor/device > specific."; > reference "RFC XXXX, Section 2.3.2 Half-Life Period"; > } Same comment as above. Thanks. Answer also as above. Section 5, paragraph 8 > "WG Web: <http://tools.ietf.org/wg/netmod/> Please update the link to the datatracker link. We will do. Section 5, paragraph 18 > leaf in-pkts-64-octets { > type yang:counter64; > units frames; > description > "The total number of packets (including bad packets) > received that were 64 octets in length (excluding framing > bits but including FCS octets). Is the unit "frames" or "packets"? The description uses "packets". Can we be consistent? Good catch. Probably using packets is fine, and this would be consistent with the equivalent counters in RFC 2819. Section 6.1, paragraph 2 > { > "ietf-interfaces:interfaces": { > "interface": [ > { > "name": "eth0", > "type": "iana-if-type:ethernetCsmacd", > "oper-status": "up", > "statistics": { > "discontinuity-time": "2023-12-15T09:04:00-05:00" > }, > "ietf-if-extensions:link-flap-suppression": { > "down": 0, > "up": 50 > } > } > ] > } > } Thanks for extensive and useful complete examples. It would be helpful if these were tagged with <CODE START> and <CODE ENDS> tag to enable extraction of them from the document and validate them against the model. We will add these. Section 6.3, paragraph 6 > { > "ietf-interfaces:interfaces": { > "interface": [ > { > "name": "eth0", > "type": "iana-if-type:ethernetCsmacd", > "phys-address": "00:00:5E:00:53:30", > "oper-status": "up", > "admin-status": "up", > "if-index": 1, > "ietf-if-ethernet-like:ethernet-like": { > "mac-address": "00:00:5E:00:53:30", > "bia-mac-address": "00:00:5E:00:53:30" > }, > "statistics": { > "discontinuity-time": "2023-12-15T09:04:00-05:00" > } > } > ] > } > } > > The following example shows the intended configuration for interface > eth0 with an explicit MAC address configured. > > { > "ietf-interfaces:interfaces": { > "interface": [ > { > "name": "eth0", > "type": "iana-if-type:ethernetCsmacd", > "ietf-if-ethernet-like:ethernet-like": { > "mac-address": "00:00:5E:00:53:30" > } > } > ] > } > } > > After the MAC address configuration has been successfully applied, > the operational state datastore reporting the interface MAC address > properties would contain the following, with the mac-address leaf > updated to match the configured value, but the bia-mac-address leaf > retaining the same value - which should never change. > > { > "ietf-interfaces:interfaces": { > "interface": [ > { > "name": "eth0", > "type": "iana-if-type:ethernetCsmacd", > "phys-address": "00:00:5E:00:53:35", > "oper-status": "up", > "admin-status": "up", > "if-index": 1, > "ietf-if-ethernet-like:ethernet-like": { > "mac-address": "00:00:5E:00:53:35", > "bia-mac-address": "00:00:5E:00:53:30" > }, > "statistics": { > "discontinuity-time": "2023-12-15T09:04:00-05:00" > } > } > ] > } > } These examples are confusing, if they are related, as it appears from the description. Maybe part of the confusion is stemming from the fact that same MAC addresses are reused in the example. The first example is that of the operational datastore before any config is applied and shows both "mac-address" and "bia-mac-address" as "00:00:5E:00:53:30”. The second example is of for intended configuration datastore and is trying to set the "mac-address" to "00:00:5E:00:53:30". Could a different MAC address be used here to demonstrate the change, e.g., "00:00:5E:00:53:35" or something other than what is already showed in the first example. The third example appears to be the state of the operational datastore once the above configuration is applied. According to the example, the "mac-address" does not seem to have changed from before because the address being configured is "00:00:5E:00:53:30", while the operational datastore is showing the mac-address as "00:00:5E:00:53:35". On the other hand, the bia-mac-address seems to have changed to "00:00:5E:00:53:30" because that is the address that is configured in the config example, when BIA MAC addresses are never supposed to change. Good catch. I think that there is a mistake in the examples, the intention was that the :35 was used for the configured MAC address. With that change, I think that the examples all become consistent with each other. Section 9, paragraph 0 > The YANG module defined in this memo is designed to be accessed via > the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is > the secure transport layer and the mandatory to implement secure > transport is SSH RFC 6242 [RFC6242]. The NETCONF access control > model RFC 8341 [RFC8341] provides the means to restrict access for > particular NETCONF users to a pre-configured subset of all available > NETCONF protocol operations and content. Please update this to reflect the latest changes in the template as documented in rfc8407bis. We will do. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 3 > Several of the augmentations defined here are not backed by any > formal standard specification. Instead, they are for features that > are commonly implemented in equivalent ways by multiple independent > network equipment vendors. The aim of this document is to define > common paths and leaves for the configuration of these equivalent > features in a uniform way, making it easier for users of the YANG > model to access these features in a vendor independent way. Where > necessary, a description of the expected behavior is also provided > with the aim of ensuring vendors implementations are consistent with > the specified behavior. RFC 7950 does not use leaves. When referring to the plural of leaf, it uses leafs. I would suggest: s/leaves/leafs/ in this paragraph and the rest of the document. We will change. Section 4, paragraph 11 > "This module contains common definitions for extending the IETF > interface YANG model (RFC 8343) with common configurable layer 2 > properties. Maybe one too many "common" occurances in the above statement? We will elide the first “common”. Section 4, paragraph 48 > Discontinuities in the values of this counter can occur at > re-initialization of the management system, and at other > times as indicated by the value of the 'discontinuity-time' > leaf defined in the ietf-interfaces YANG module > (RFC 8343). > "; Does the closing quote and semicolon need to be on a newline? We will fix. These URLs point to tools.ietf.org<http://tools.ietf.org/>, which has been taken out of service: * http://tools.ietf.org/wg/netmod/ We will fix to point to datatracker. Section 2, paragraph 12 > tate transition that occurs and reverts back within the specified time inter > ^^^^^^^^^^^^ Consider using just "reverts". Section 4, paragraph 28 > specific. The penalty value for a link up->down state change is 1000 units." > ^^^^^^^ When "link-up" is used as a noun or modifier, it needs to be hyphenated. Section 4, paragraph 28 > specific. The penalty value for a link up->down state change is 1000 units." > ^^^^^^^ When "link-up" is used as a noun or modifier, it needs to be hyphenated. Section 4, paragraph 39 > f the number of frames that were well formed, but otherwise discarded because > ^^^^^^^^^^^ This word is normally spelled with a hyphen. This I think is for well-formed. We will fix. Section 5, paragraph 31 > iption "The 'burnt-in' MAC address. I.e the default MAC address assigned to > ^^^ The abbreviation "i.e." (= that is) requires two periods. Section 5, paragraph 33 > f the number of frames that were well formed, but otherwise discarded because > ^^^^^^^^^^^ This word is normally spelled with a hyphen. We will fix these. Thanks for the careful review. Kind regards, Scott & Rob Mahesh Jethanandani [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
