feature: having different vlan pool allocations for UNIs and NNIs

[viniarck]

Currently, available_tags belongs to the interface, but currently, it's supported that an EVC can also be created in a NNI interface, which starts acting as a UNI for that EVC. In this case, since it uses the same pool, link down events for the NNI being used by other EVCs might allocate the UNI s vlan if that ever gets released by the EVC (by changing it or deleting), so changing certain configurations might cause this dispute that can be cumbersome for network operators.

Ultimately, it's desired to have an explicit non overlapping pool for UNIs and NNIs of a given interface. That will be discussed when this gets prioritized, making sure if meets the current usages that well known in production. We're not too far away from this, it's mostly a matter of having a separate pool while still allocating.

Related prior discussions: kytos-ng/kytos#406

[Ktmi]

I've been writing a some documents regarding this and other issues, here's a bit of it. What do you think @viniarck?

Rethinking How We Define the Topology

Some of our terminology is a bit confusing with how we use it, considering the context that we are trying to resolve. Part of that is the rigidity that the terminology suggests. Network-to-Network interface(NNI) and User-to-Network Interface (UNI), which both suggest a physical interface connecting to a single destination. However, we know that this is not always the case, so let's take some steps to redefine a few terms.

First, we'll be considering all of this terminology and how its used in the unidirectional case, unless otherwise specified. It's simpler to explain, and ultimately bidirectional network traffic flow is just an abstraction for a pair of unidirectional network traffic flows.

Second, we will be replacing the terms UNI and NNI. They don't really give us the full picture on what's going on. Instead we are going to be using the following terminology:

• A switch has a set of Ingress and Egress rules. Some Ingress rules have an expected source, and some egress rules have an expected destination.
• When you have an egress rule which we can reasonably expect its traffic to received by a particular ingress rule, you then have a Transport.
• From an ingress, egress, or transport, we can select a subset of the traffic going through them through a Slice. These slices are just another ingress/egress/transport, but with additional parameters on the expected traffic.
• When we want to route packets match by a particular ingress rule to an egress rule, we must define a Connection between the two.