date:20240227

[netmod] Deviating in circles

2024-02-27 Thread Jan Lindblad (jlindbla)

Dear NETMODers,

I'm on site at the annual EANTC interop-event in Berlin, and came across an 
interesting case relating to import and deviations that I'd like the views of 
the list on.

According to RFC 7950:

   There MUST NOT be any circular chains of imports.  For example, if
   module "a" imports module "b", "b" cannot import "a".

This is clear and I believe most people find this reasonable enough.

With this rule in mind, I can make two modules a and b, where a imports b. 
Module b does not and cannot import a.

module a {
yang-version 1.1;
namespace "http://example.com/ns/a";;
prefix a;

import b {
prefix b;
}

typedef A {
type uint32;
}

leaf aa {
type A;
}
leaf ab {
type b:B;
}
}

module b {
yang-version 1.1;
namespace "http://example.com/ns/b";;
prefix b;

typedef B {
type uint32;
}

leaf bb {
type B;
}
}

Now let's add a deviation in a separate module d. The deviation module can 
import both a and b (since neither a or b imports d), and it changes the 
structure so that module b now refers to a type in module a.

module d {
yang-version 1.1;
namespace "http://example.com/ns/d";;
prefix d;

import a {
prefix a;
}
import b {
prefix b;
}

deviation /b:bb {
deviate replace {
type a:A;
}
}
}

As far as I can tell, this follows all the explicit YANG rules regarding 
deviations and imports. Still, it would not have been possible to create this 
YANG structure without a deviation. Module b cannot refer to types or objects 
in module a without an outside intervention.

Is the construct in module d legal? RFC 7950 is not very clear on the subject, 
but it does say:

   After applying all deviations announced by a server, in any order,
   the resulting data model MUST still be valid.

If "applying" means actually replacing the original module text with the 
deviated text, then I'm fairly sure module d would violate the rule against 
circular imports. If "applying" is something that happens on a more "global" or 
"logical" level, then maybe this should be allowed?

By allowing deviations of this kind, we might create a temptation for people to 
use deviations for their own modules in order to create YANG structures 
otherwise not possible. I find this problematic, since I don't like deviations 
much. On the other hand, allowing deviations of this kind increases the freedom 
of expression in the YANG world. I think many would regard a moratorium as 
another YANG CLR (crappy little rule).

If we were to decide that this sort of deviation is allowed, wouldn't a logical 
conclusion be that we should drop the circular imports rule? Compilers could 
very well track which modules have already been imported (like in python), and 
not go into unbounded spin just because there is a circular reference loop.

As a side note, recent versions of the OpenConfig model have fallen into this 
YANG-module reference trap. Some OC modules violate RFC 7950 rules because 
their authors were not able to plan ahead and divide their modules properly 
into layers. They have skipped importing modules that they are using because 
their compiler errors out if they do the import, but the compiler they use 
misses/tolerates the illegal reference without the needed import. If modules 
could mutually import each other, this problem would be easily solved. Several 
major vendors of YANG-based servers have navigated around this problem by 
essentially using a single module (namespace) for most of their functionality. 
Then there are no restrictions for what part of the model can reference what 
else, but everything ends up in a single (rather huge) namespace.

Thoughts?

Best Regards,
/jan

___
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

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

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)

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 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

[netmod] About /hardware/component/class in ietf-hardware.yang

2024-02-27 Thread Liangrui Zhou

Hi Network Modeling WG
In ietf-hardware.yang, /hardware/component/class is configurable. But in 
RFC8348, this node is mapped to ENTITY-MIB object entPhysicalClass and 
entPhysicalVendorType which are read only.
As my understanding, this node is expected to be set by device vendor. And for 
device management system, it’s read only.
Could you please explain the reason/purpose to define it as configurable in 
ietf-hardware.yang?

Best Regards

Zhou Liangrui (周梁瑞)
(+86)13681241024
RAN OAM System Engineer


This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Deviating in circles

[netmod] Modeling of veth pairs

Re: [netmod] Modeling of veth pairs

Re: [netmod] Modeling of veth pairs

Re: [netmod] Modeling of veth pairs

Re: [netmod] Modeling of veth pairs

[netmod] About /hardware/component/class in ietf-hardware.yang

7 matches

Site Navigation

Mail list logo

Footer information