Re: [netmod] Modeling of veth pairs

2024-02-27 Thread Florian Kauer 
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 
> *Date: *Tuesday, 27 February 2024 at 14:16
> *To: *Rob Wilton (rwilton) , Florian Kauer 
> , 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) 
> *Sent:* Tuesday, February 27, 2024 8:55 AM
> *To:* Florian Kauer ; netmod@ietf.org
> *Cc:* Scott Mansfield 
> *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 .

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

Re: [netmod] Modeling of veth pairs

2024-02-27 Thread Rob Wilton (rwilton) 
Yes possibly.  Florian would you be interested in helping if we were to do that?

Regards,
Rob

From: Scott Mansfield 
Date: Tuesday, 27 February 2024 at 14:16
To: Rob Wilton (rwilton) , Florian Kauer 
, 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) 
Sent: Tuesday, February 27, 2024 8:55 AM
To: Florian Kauer ; netmod@ietf.org
Cc: Scott Mansfield 
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.

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 
mailto:florian.ka...@linutronix.de>>
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org 
mailto:netmod@ietf.org>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.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
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

Re: [netmod] Modeling of veth pairs

2024-02-27 Thread Scott Mansfield 
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) 
Sent: Tuesday, February 27, 2024 8:55 AM
To: Florian Kauer ; netmod@ietf.org
Cc: Scott Mansfield 
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.

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 
mailto:florian.ka...@linutronix.de>>
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org 
mailto:netmod@ietf.org>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.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
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

Re: [netmod] Modeling of veth pairs

2024-02-27 Thread Rob Wilton (rwilton) 
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.

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 
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org 
Cc: Rob Wilton (rwilton) , 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
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

[netmod] Modeling of veth pairs

2024-02-27 Thread Florian Kauer 
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
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