Yes possibly. Florian would you be interested in helping if we were to do that?
Regards, Rob 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. 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/>. 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. 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. 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. Regards, Rob // As a contributor/author of draft-ietf-netmod-intf-ext-yang. From: Florian Kauer <florian.ka...@linutronix.de<mailto:florian.ka...@linutronix.de>> Date: Tuesday, 27 February 2024 at 09:02 To: netmod@ietf.org<mailto:netmod@ietf.org> <netmod@ietf.org<mailto:netmod@ietf.org>> Cc: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>, scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com> <scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com>> Subject: Modeling of veth pairs Hi, I would like to model a veth pair in YANG, preferrably without proprietary models. In Linux, these veth pairs are basically just this: +------+ +------+ |Socket| |Socket| +------+ +------+ | | +------+ +------+ |Stack | |Stack | +------+ +------+ | | +------+ +------+ |veth1 | |veth2 | +------+ +------+ | | +----------+ So all packets that egress veth1, appear at the ingress of veth2 and vice versa, i.e. similar to two physical interfaces of the same device directly connected via a cable. Also see https://man7.org/linux/man-pages/man4/veth.4.html The only thing I specifically found regarding veths and YANG was https://doc.6wind.com/turbo-router-2.x/user-guide/cli/network-interface/types/veth.html<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-00890e5f712ca52f&q=1&e=b797b9fa-a764-402f-bcce-ceb3cfffca50&u=https%3A%2F%2Fdoc.6wind.com%2Fturbo-router-2.x%2Fuser-guide%2Fcli%2Fnetwork-interface%2Ftypes%2Fveth.html> where they seem to use a proprietary model that provides "link-interface" to link the two interfaces together. The other option I thought about was to represent the "virtual cable" as Internal LAN, i.e. IANA type 247 (ILAN). This would look like this: +------+ +------+ |Socket| |Socket| +------+ +------+ | | +------+ +------+ |Stack | |Stack | +------+ +------+ | | +------+ +------+ |veth1 | |veth2 | +------+ +------+ | | +-----------------+ | ilan0 | +-----------------+ However, that would still require to specify the link between the veth1 and ilan0 as well as veth2 and ilan0 with some kind of parent/child or higher/lower layer interface link. The higher-layer-if and lower-layer-if of RFC 8343 is only ro and while draft-ietf-netmod-intf-ext-yang provides "parent-interface", it would not work here because ilan0 has two parents (i.e. we would need a "child-interface" or a way to specify multiple parent interfaces). Also, what could be the interface type of veth1 and veth2? Any ideas on this? Or do we need to specify something new to support this? Thanks, Florian
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
