## 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"Vlan support was initially created assuming "vlanX" semantics. In this paradigm, automatic number assignment supported by cloning (ifconfig vlan create) was a natural fit.
These can be configured in 3 different waysWhen "ifaceX.Y" support was added, allowing to have the same vlan number on multiple devices, cloning code became more complex, as the is no unified "vlan" namespace anymore. Such interfaces got the first spare index from "vlan" cloner. This, in turn, led to the following problem:
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 replacesfor the ids with vlan ids~~sub-interfaces.