Change Details

## Overview D26436 introduced support for stacked vlans that changed the way we configure vlans. In particular, this change broke setups that have same-number vlans as subinterfaces. ### Vlan naming details There are two supported vlan naming format: "vlanX" and "ifaceX.Y". These can be configured in 3 different ways: 1. parameter-based creation (default, providing parent interface and vlan id as a separate options), works for both formats 2. name-based creation: works for ifaceX.Y 3. "base" creation: works for vlanX. ## Problem with the current approach Vlan support was initially created assuming "vlanX" semantics. In this paradigm, it looked like any other logical interface, so auto-cloning support (`ifconfig vlan create`) was the natural fit. With the global "vlan" namespace, it was pretty much the same as `ifconfig tun create` and `ifconfig tun25 create`. Later, vlan subinterface support was added, allowing to have the same vlan number on multiple devices, making things more complex. There Is no unified namespace anymore: each interface has its own and one can use both "vlanX" and "iface.X" vlans on the same interface. Auto-cloning support started to bring problems: `ix0.25` and `ix1.25` cannot use the same index in "vlan" namespace. It was worked around by making all such interfaces allocated first free index. This, in turn, led to the following problem: ``` ifconfig ix0.333 create -> index 1 ifconfig ix0.444 create -> index 2 ifconfig vlan2 create -> allocation failure ``` As a result, in order to support `ifconfig vlan create` usecase, we break mixed vlanX/vlan.X usecases. If we go with decoupling vlan tags from indexes, then, naturally, `ifconfig vlan create` usecase gets broken: resulting `vlanX` will provide no guarantee that tag `X` can be used. There are other potential options, like allocating namespaces per-interface. However, with vlan renaming, and potential mixture of `vlanX` and `iface.X` vlans, it looks like an overly complex piece of machinery. As a result, there is no good solution that will address all of the issues. ## Changes This review targets the following: * It restores name-based creation (2) to allow older binaries create subinterfaces as before. It was removed in D26436. * It reverts `ifc_name2unit()` changes from D26436 and stops using `ifc_name2unit()` for sub-interfaces * ~~It removes an ability to create unnamed vlans ("ifconfig vlan create")~~ * ~~It stops using unit allocation code (`ifc_alloc_unit()`) and replaces the ids with vlan ids~~

## Overview D26436 introduced support for stacked vlans that changed the way we configure vlans. In particular, this change broke setups that have same-number vlans as subinterfaces. ### Vlan naming details There are two supported vlan naming format: "vlanX" and "ifaceX.Y". These can be configured in 3 different ways: 1. parameter-based creation (default, providing parent interface and vlan id as a separate options), works for both formats 2. name-based creation: works for ifaceX.Y 3. "base" creation: works for vlanX. ## Problem with the current approach Vlan support was initially created assuming "vlanX" semantics. In this paradigm, it looked like any other logical interface, so auto-cloning support (`ifconfig vlan create`) was the natural fit. With the global "vlan" namespace, it was pretty much the same as `ifconfig tun create` and `ifconfig tun25 create`. Later, vlan subinterface support was added, allowing to have the same vlan number on multiple devices, making things more complex. There Is no unified namespace anymore: each interface has its own and one can use both "vlanX" and "iface.X" vlans on the same interface. Auto-cloning support started to bring problems: `ix0.25` and `ix1.25` cannot use the same index in "vlan" namespace. It was worked around by making all such interfaces allocated first free index. This, in turn, led to the following problem: ``` ifconfig ix0.333 create -> index 1 ifconfig ix0.444 create -> index 2 ifconfig vlan2 create -> allocation failure ``` As a result, in order to support `ifconfig vlan create` usecase, we break mixed vlanX/vlan.X usecases. If we go with decoupling vlan tags from indexes, then, naturally, `ifconfig vlan create` usecase gets broken: resulting `vlanX` will provide no guarantee that tag `X` can be used. There are other potential options, like allocating namespaces per-interface. However, with vlan renaming, and potential mixture of `vlanX` and `iface.X` vlans, it looks like an overly complex piece of machinery. As a result, there is no good solution that will address all of the issues. ## Changes This review targets the following: * It restores name-based creation (2) to allow older binaries create subinterfaces as before. It was removed in D26436. * It reverts `ifc_name2unit()` changes from D26436 and stops using `ifc_name2unit()` for sub-interfaces * ~~It removes an ability to create unnamed vlans ("ifconfig vlan create")~~ * ~~It stops using unit allocation code (`ifc_alloc_unit()`) and replaces the ids with vlan ids~~

## Overview D26436 introduced support for stacked vlans that changed the way we configure vlans. In particular, this change broke setups that have same-number vlans as subinterfaces. ### Vlan naming details There are two supported vlan naming format: "vlanX" and "ifaceX.Y". These can be configured in 3 different ways: 1. parameter-based creation (default, providing parent interface and vlan id as a separate options), works for both formats 2. name-based creation: works for ifaceX.Y 3. "base" creation: works for vlanX. ## Problem with the current approach Vlan support was initially created assuming "vlanX" semantics. In this paradigm, it looked like any other logical interface, so auto-cloning support (`ifconfig vlan create`) was the natural fit. With the global "vlan" namespace, it was pretty much the same as `ifconfig tun create` and `ifconfig tun25 create`. Later, vlan subinterface support was added, allowing to have the same vlan number on multiple devices, making things more complex. There Is no unified namespace anymore: each interface has its own and one can use both "vlanX" and "iface.X" vlans on the same interface. Auto-cloning support started to bring problems: `ix0.25` and `ix1.25` cannot use the same index in "vlan" namespace. It was worked around by making all such interfaces allocated first free index. This, in turn, led to the following problem: ``` ifconfig ix0.333 create -> index 1 ifconfig ix0.444 create -> index 2 ifconfig vlan2 create -> allocation failure ``` As a result, in order to support `ifconfig vlan create` usecase, we break mixed vlanX/vlan.X usecases. If we go with decoupling vlan tags from indexes, then, naturally, `ifconfig vlan create` usecase gets broken: resulting `vlanX` will provide no guarantee that tag `X` can be used. There are other potential options, like allocating namespaces per-interface. However, with vlan renaming, and potential mixture of `vlanX` and `iface.X` vlans, it looks like an overly complex piece of machinery. As a result, there is no good solution that will address all of the issues. ## Changes This review targets the following: * It restores name-based creation (2) to allow older binaries create subinterfaces as before. It was removed in D26436. * It reverts `ifc_name2unit()` changes from D26436 and stops using `ifc_name2unit()` for sub-interfaces * ~~It removes an ability to create unnamed vlans ("ifconfig vlan create")~~ * ~~It stops using unit allocation code (`ifc_alloc_unit()`) and replaces the ids with vlan ids~~