[netmod] Re: Updated sub-intf-vlan and intf-ext drafts

[Florian Kauer]

Hi,
thanks a lot!

One comment regarding the peer-interface proposal:
In the meantime, I was made aware that the "IEC/IEEE 60802 TSN Profile for 
Industrial Automation" actually has a very similar use case and they actually 
solved it via the ilan approach I mentioned in the initial discussion:

6.4.2.3 Internal LAN connection model
The modeling of internal connections between C-VLAN components within an 
IA-station is
aligned to IEEE Std 802.1Q-2022, 17.3.2.2, which includes an I-LAN interface. 
As shown in
Figure 17, the I-LAN interface is modeled as an ilan IETF interface object (see 
IETF RFC 7224)
together with appropriate higher-layer-if and lower-layer-if reference objects 
to
describe the internal connection

They also noted the related problem of using higher-layer-if and lower-layer-if 
directly instead of draft-ietf-netmod-intf-ext-yang's parent-interface:
"NOTE The CNC cannot configure the lower-layer-if reference because it is 
defined read-only in the ietf-interfaces
YANG module." (under 6.4.2.5).

I don't know if it makes sense to align these two approaches in one or the 
other direction.

Apart from that, the current proposal looks good and I was (nearly) able to 
reproduce the validation. 
One nit:
ietf-if-vlan-encapsulat...@2023-01-26.yang and 
ietf-if-flexible-encapsulat...@2023-01-26.yang
both refer to a specific revision 2022-01-19 for ieee802-dot1q-types
which is not only outdated, but due to that AFAIK also not available via 
https://github.com/YangModels/yang
Do we really need that reference to a specific revision for ieee802-dot1q-types?

Thanks,
Florian

On 8/1/24 13:33, Scott Mansfield wrote:
> Greetings Netmod,
> 
>  
> 
> Common Interface Extension YANG Data Models
> 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ 
> 
> 
> Has been updated adding a section on “peer interface configuration”, and 
> updating and validating (using yanglint) the seven examples.
> 
>  
> 
> Sub-interface VLAN YANG Data Models
> 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ 
> 
> 
> Has been updated to remove the pointer to an expired draft and to update and 
> validate (using yanglint) the two examples.
> 
>  
> 
> Unless Rob says anything different, the editors/caretakers (Rob and myself) 
> are looking for any further discussion on these two drafts so we can get 
> these moving in the IETF process.
> 
>  
> 
> Regards,
> 
> -scott.
> 
> 
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] Modeling of veth pairs

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

[netmod] Modeling of veth pairs

[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] IEEE Std 802.1Qcw invalidates trivial YANG data tree

[Florian Kauer]

Hi,
thanks a lot Lada! This is exactly the change that fixes the issue (see below 
for the full diff)
and with that we were able to use the YANG model in our implementation.
But what now, do we need a Corrigendum for IEEE 802.1Qcw-2023? What is the next 
step?

Greetings,
Florian

--- schemas/standard/ieee/published/802.1/ieee802-dot1q-sched.yang  
2024-02-02 09:50:22.135503812 +0100
+++ ieee802-dot1q-sc...@2024-01-30.yang 2024-02-02 14:54:24.290563673 +0100
@@ -33,6 +33,10 @@
 
 This version of this YANG module is part of IEEE Std 802.1Q; see the
 standard itself for full legal notices.";
+  revision 2024-01-30 {
+description
+  "Draft for fixing incorrect must statements.";
+  }
   revision 2023-10-22 {
 description
   "Published as part of IEEE Std 802.1Qcw-2023.
@@ -77,7 +81,7 @@
   }
   refine "gate-control-entry/time-interval-value" {
 must
-  "(. <= ../../../supported-interval-max )";
+  "not (. > ../../../supported-interval-max )";
   }
   augment "gate-control-entry" {
 description
@@ -187,9 +191,9 @@
   }
   container admin-control-list {
 must
-  "(count(./gate-control-entry) <= ../supported-list-max)" {
+  "not(count(./gate-control-entry) > ../supported-list-max)" {
   error-message
-"Number of elements in admin-control-list must not be greater"+
+"Number of elements in admin-control-list must not be greater "+
 "than supported-list-max";
 }
 description
@@ -202,9 +206,9 @@
   }
   container oper-control-list {
 must
-  "(count(./gate-control-entry) <= ../supported-list-max)" {
+  "not(count(./gate-control-entry) > ../supported-list-max)" {
   error-message
-"Number of elements in oper-control-list must not be greater"+
+"Number of elements in oper-control-list must not be greater "+
 "than supported-list-max";
 }
 config false;
@@ -217,7 +221,7 @@
   }
   container admin-cycle-time {
 must
-  "(./numerator div ./denominator <= "+
+  "not (./numerator div ./denominator > "+
   "../supported-cycle-max/numerator div "+
   "../supported-cycle-max/denominator )" {
   error-message
@@ -235,7 +239,7 @@
   }
   container oper-cycle-time {
 must
-  "(./numerator div ./denominator <= "+
+  "not (./numerator div ./denominator > "+
   "../supported-cycle-max/numerator div "+
   "../supported-cycle-max/denominator )" {
   error-message


On 15.12.23 10:48, Ladislav Lhotka wrote:
> Hi Florian,
> 
> Florian Kauer  writes:
> 
>> Hi,
>> I know this is bad timing since Qcw was just published, but - at least with 
>> libyang - the following YANG data tree that specifies nothing Qcw related is 
>> no longer valid when just loading the Qcw YANG models:
>>
>> interface.json:
>> {
>>   "ietf-interfaces:interfaces": {
>> "interface": [
>>   {
>> "if-index": 1,
>> "name": "eth0",
>> "type": "iana-if-type:ethernetCsmacd",
>> "oper-status": "down",
>> "admin-status": "down",
>> "statistics": {
>>   "discontinuity-time": "2023-12-15T10:04:12.345+00:00"
>> }
>>   }
>> ]
>>   }
>> }
>>
>> yanglint interface.json ieee802-dot1q-sched.yang 
>> ieee802-dot1q-sched-bridge.yang ieee802-types.yang ieee802-dot1q-types.yang 
>> ieee802-dot1q-bridge.yang iana-if-t...@2023-01-26.yang 
>> ietf-interfa...@2018-02-20.yang
>>
>> results into
>>
>> libyang err : Number of elements in admin-control-list must not be 
>> greaterthan supported-list-max (Data location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin-control-list".)
>> libyang err : Number of elements in oper-control-list must not be 
>> greaterthan supported-list-max (Data location 
>> "/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-control-list".)
>> libyang err : admin-cycle-time must not be greater than supported-cycle-max 
>> (Data location 
>> "/ietf-inte

[netmod] IEEE Std 802.1Qcw invalidates trivial YANG data tree

[Florian Kauer]

Hi,
I know this is bad timing since Qcw was just published, but - at least with 
libyang - the following YANG data tree that specifies nothing Qcw related is no 
longer valid when just loading the Qcw YANG models:

interface.json:
{
  "ietf-interfaces:interfaces": {
"interface": [
  {
"if-index": 1,
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "down",
"admin-status": "down",
"statistics": {
  "discontinuity-time": "2023-12-15T10:04:12.345+00:00"
}
  }
]
  }
}

yanglint interface.json ieee802-dot1q-sched.yang 
ieee802-dot1q-sched-bridge.yang ieee802-types.yang ieee802-dot1q-types.yang 
ieee802-dot1q-bridge.yang iana-if-t...@2023-01-26.yang 
ietf-interfa...@2018-02-20.yang

results into

libyang err : Number of elements in admin-control-list must not be greaterthan 
supported-list-max (Data location 
"/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin-control-list".)
libyang err : Number of elements in oper-control-list must not be greaterthan 
supported-list-max (Data location 
"/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-control-list".)
libyang err : admin-cycle-time must not be greater than supported-cycle-max 
(Data location 
"/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/admin-cycle-time".)
libyang err : oper-cycle-time must not be greater than supported-cycle-max 
(Data location 
"/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/oper-cycle-time".)
YANGLINT[E]: Failed to parse input data file "interface.json".

My first expectation was a bug in libyang, but Michal is convinced that 
libyang's behavior is correct in this regard:
https://github.com/CESNET/libyang/issues/2140

I have not enough experience in YANG to properly argue if either the YANG model 
or libyang needs to be changed, but I don't think we want to force every 
interface to specify a
/ietf-interfaces:interfaces/interface[name='eth0']/ieee802-dot1q-bridge:bridge-port/ieee802-dot1q-sched-bridge:gate-parameter-table/supported-list-max
etc. just because the Qcw YANG models are loaded.

I hope I have just a misunderstanding and I am looking forward to your 
responses!

Greetings,
Florian

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod