Hi, comments inline. On 27.02.24 16:11, Rob Wilton (rwilton) wrote: > Yes possibly. Florian would you be interested in helping if we were to do > that?
Yes, of course! Let me know how I can help with that. > *From: *Scott Mansfield <scott.mansfi...@ericsson.com> > *Date: *Tuesday, 27 February 2024 at 14:16 > *To: *Rob Wilton (rwilton) <rwil...@cisco.com>, Florian Kauer > <florian.ka...@linutronix.de>, netmod@ietf.org <netmod@ietf.org> > *Subject: *RE: Modeling of veth pairs > > Could we add this case to the intf-ext work? > > We could use this as an example. If a new module is what is desired, I will > support that too. That would of course be very nice! > > > > Regards, > > -scott. > > > > *From:*Rob Wilton (rwilton) <rwil...@cisco.com> > *Sent:* Tuesday, February 27, 2024 8:55 AM > *To:* Florian Kauer <florian.ka...@linutronix.de>; netmod@ietf.org > *Cc:* Scott Mansfield <scott.mansfi...@ericsson.com> > *Subject:* Re: Modeling of veth pairs > > > > Hi Florian, > > > > Some very quick thoughts on this: > > I’m assuming that these Virtual Ethernet interfaces are really only Ethernet > emulations at layer 2 rather than layer 1. I.e., I presume that there is no > configuration for speed, duplex, flow-control, etc? But they would each have > their own a MAC address? I think that this would mean that these interfaces > are probably more ethernet-like as defined in > draft-ietf-netmod-intf-ext-yang-13 - Common Interface Extension YANG Data > Models <https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/>. In fact they even have speed, duplex setting etc., but AFAIK they have no impact on the behavior and these interfaces are actually emulations on L2. Each veth has its own MAC address so I think it is "ethernet-like". By the way, there is also the very recently added netkit ( https://lore.kernel.org/netdev/20231024214904.29825-1-dan...@iogearbox.net/ ) which from the network modeling point of view is quite the same as veth, but also supports an L3 mode. So supporting that L3 mode would also be nice, but I guess goes to far and we might want to focus on the L2 first. > I suspect that you will want to define a new IANA iftype for these > interfaces. The alternative would be ethernetCsmacd that is used for all > physical Ethernet interfaces but not LAG. But using that IANA iftype would > then mean that you would likely pickup the configuration for physical > Ethernet interfaces that I don’t think that you really want. I also thought about just using ethernetCsmacd, but the application processing the YANG config somehow needs to know if it has to search for a corresponding physical interface or setup a new virtual one. > You could use an Interface naming convention to represent the binding, e.g., > veth1-left, veth1-right, but it may be better to be more flexible, in which > case, I would probably recommend having new configuration under each v-eth > interface with a leaf-ref to indicate what its peer interface is. That could work, yes. > So, yes, I think that you would need to a new model to define these, but it > should be pretty small and simple. And if you did want to do something like > this in the IETF, then I suspect that NETMOD is probably the best WG. Thanks! I will look deeper into draft-ietf-netmod-intf-ext-yang and maybe it is possible to add a simple extension for these "peer" interfaces. Greetings, Florian _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
