Vlan_pool config should apply only for service tags or we should provide a new option for that

[italovalcy]

Hi,

Currently, Kytos-ng provides an option called vlan_pool which is described as:

# VLAN pool settings
#
# The VLAN pool settings is a dictionary of datapath id, which contains
# a dictionary of of_port numbers with the respective vlan pool range
# for each port number. See the example below, which sets the vlan range
# [1, 5, 6, 7, 8, 9] on port 1 and vlan range [3] on port 4 of a switch
# that has a dpid '00:00:00:00:00:00:00:01'

The description above does not provide enough information on the expected/covered use cases.

Blueprint EP012 gives an idea about the expected use case: https://github.com/kytos-ng/kytos/blob/master/docs/blueprints/EP012.rst#interface-tags-pool-mechanism

From the blueprint EP012 it looks like we should provide two mechanisms for vlan_pool: one for UNIs and another one for Links (that applies for both NNI that compose a Link).

If that is true, we should review the vlan_pool or Link.get_next_available_tag() (which is massively being used by mef_eline)

At AmLight we have a very important use case which is Links with VLAN restrictions (ethernet links provided by partners, where they only make available a range of VLANs for AmLight). In those cases, we would like to use that link as a possible component of a Path in Kytos (applying the VLAN restriction) and in the same time use a more flexible range for possible UNIs with the partner.

When a request for a VLAN overlaps, we should prioritize the Link/NNI vlan pool, because it looks like negociating the customer VLAN can be easier than the Service VLAN.

Cc'ing @jab1982 and @viniarck for more discussion.

[italovalcy]

The way it is currently, we set the VLAN pool for the Service VLANs, and we don't have a way to dynamically add Customer VLANs on the particular interfaces.

The following workaround was identified for situations where this is necessary:

1. Edit the config on Kytos to include the new Customer VLAN you want. For instance:

Original setting:

# grep vlan_pool /etc/kytos/kytos.conf
vlan_pool = {"00:00:00:00:00:00:00:02": {"3": [[100, 200]]}, "00:00:00:00:00:00:00:03": {"2":[[100, 200]]}}

After adding the customer VLAN (let's say 1799):

# grep vlan_pool /etc/kytos/kytos.conf
vlan_pool = {"00:00:00:00:00:00:00:02": {"3": [[100, 200], [1799, 1800]]}, "00:00:00:00:00:00:00:03": {"2":[[100, 200]]}}

Observe that even though we only want VLAN 1799, the config must be [1799, 1800] because of the way this setting is being processed.

2. Despite the config above, we also need apply an additional step so that Kytos running instance can load the new setting. This can be done only through Kytos console (ie. kytosd -f, if you started Kytos in background mode, you will have to restart kytos anyway -- that is why we recommend using kytos with console leveraging tmux for detach from current terminal as we are doing on Kytos docker image). The following steps should be executed on the console:

kytos $> current = [tag.value for tag in controller.switches["00:00:00:00:00:00:00:02"].interfaces[3].available_tags]
kytos $> controller.switches["00:00:00:00:00:00:00:02"].interfaces[3].set_available_tags([*current, 1799])

Observe that the setup above does not persists the new available tag... I beleive this won't be an issue, because if Kytos restarts, the core will first load from kytos.conf file (that is why you do need step 1 above).

[viniarck]

@italovalcy, good catch, in the future, it's worth covering this with e2e testing this too.

From the blueprint EP012 it looks like we should provide two mechanisms for vlan_pool: one for UNIs and another one for Links (that applies for both NNI that compose a Link).

Right. I was also reviewing this part and looking into git history as well, and the implementation diverged only keeping available_vlans for an interface. The current implementation seems reasonable to me, since a link associates two interfaces, so using the interfaces available_tags seems fine, and we also need to discuss to start consuming available_tags from UNIs too, especially if we introduce vlan range in the future.

Regarding configuring available_tags on interfaces

We could potentially specify and refine new a new endpoint on topology to be able to specify the ranges of the pool. Also, considering the order how it's loaded and topology being responsible for it, it'd be easier to maintain on topology, and then we could deprecate and remove this vlan_pool option on kytos conf settings.

When it comes to setting the available_tags, this potential new endpoint should only allow to decrease the pool if whatever is being excluded isn't being used, if it's being used then it should reject the request informing the user to remove the services (EVCs) that are already using VLANS.

What do you think?

[italovalcy]

This vlan_pool behavior is becoming a very problematic limitation for some links with only a few VLANs available and that may eventually be used as UNI.

To document, since using the kytos.conf seems to cause many other troubles, we stopped using it and decided to configure the available VLANs on Kytos console, by using something similar to (work around):

dpid = '00:00:00:00:00:00:00:01'                                                                                                                                                
port_id = 4                                                                                                                                                                     
intf_id = f"{dpid}:{port_id}"
new_range = list(range(100, 200))
controller.switches[dpid].interfaces[port_id].set_available_tags(new_range)
controller.napps[('kytos', 'topology')].topo_controller.bulk_upsert_interface_details([(intf_id, {"_id": intf_id, "available_vlans": new_range})])

Additionally, if you want to create a EVC having a NNI as UNI (and the NNI has a certain vlan range out of the defined range), you could also follow the work around below (suppose you want to create a EVC with tag 1799 in an NNI interface which have only the range 100-199):

kytos $> current = [tag.value for tag in controller.switches[dpid].interfaces[port_id].available_tags]
kytos $> controller.switches[dpid].interfaces[port_id].set_available_tags([*current, 1799])

## Create the EVC here!

kytos $> from kytos.core.interface import TAG, TAGType
kytos $> controller.switches[dpid].interfaces[port_id].use_tag(TAG(TAGType.VLAN, 1799))

Even though this work around works pretty well, it has a very important drawback: if you restart Kytos, the EVC won't be loaded again because it will complain the VLAN is not available (so you have to perform the same steps again on Kytos console)

[italovalcy]

@italovalcy, good catch, in the future, it's worth covering this with e2e testing this too.

From the blueprint EP012 it looks like we should provide two mechanisms for vlan_pool: one for UNIs and another one for Links (that applies for both NNI that compose a Link).

Right. I was also reviewing this part and looking into git history as well, and the implementation diverged only keeping available_vlans for an interface. The current implementation seems reasonable to me, since a link associates two interfaces, so using the interfaces available_tags seems fine, and we also need to discuss to start consuming available_tags from UNIs too, especially if we introduce vlan range in the future.

Regarding configuring available_tags on interfaces

We could potentially specify and refine new a new endpoint on topology to be able to specify the ranges of the pool. Also, considering the order how it's loaded and topology being responsible for it, it'd be easier to maintain on topology, and then we could deprecate and remove this vlan_pool option on kytos conf settings.

When it comes to setting the available_tags, this potential new endpoint should only allow to decrease the pool if whatever is being excluded isn't being used, if it's being used then it should reject the request informing the user to remove the services (EVCs) that are already using VLANS.

What do you think?

sounds good to me, but pay attention that the suggestion you made brings a new aspect: we should keep track of what is the configured available range and what is being used. Having that separated information would be beneficial not only technically speaking but also would help the network operator document and remember what was the range defined before.

[viniarck]

sounds good to me, but pay attention that the suggestion you made brings a new aspect: we should keep track of what is the configured available range and what is being used. Having that separated information would be beneficial not only technically speaking but also would help the network operator document and remember what was the range defined before.

Right, indeed. Let's keep this in mind when the issue discussion is addressed (either in this issue here or in another actual GitHub discussion). @Alopalao will lead the effort for this epic epic_topology_vlanpool.

Great stuff, great brainstorm ideas so far.

[Alopalao]

I created a discussion to continue this conversation. There I compiled the ideas discussed here and added some more for other cases that this issue is related to.

[viniarck]

Aldo has implemented this feature, it has landed on master and it'll be shipped on 2023.2. For future, readers, check out the changelog of kytos, mef_eline, topology and of_lldp. I'll go ahead and close this issue.