Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle VLAN updates #123

Open
Tracked by #214
sajith opened this issue Jun 28, 2023 · 2 comments
Open
Tracked by #214

Handle VLAN updates #123

sajith opened this issue Jun 28, 2023 · 2 comments
Assignees
Labels

Comments

@sajith
Copy link
Member

sajith commented Jun 28, 2023

With PR #120, we will add a way to assign VLAN to connection requests, but it is only an initial sketch. We're missing a design and implementation to handle updates.

This is related to this TODO item:

# TODO: careful here when updating VLAN tags table -- what do
# we do when an in use VLAN tag becomes invalid in the update?
# self._update_vlan_tags_table_from_links(
# domain_name=topology_data.get("id"),
# port_list=self.topology_manager.port_list,
# )

@italovalcy
Copy link
Contributor

Some discussion needs to be done here to better define the use case and expected behavior:

What happens is that the OXP modifies the VLAN range available for SDX, and L2VPN services are already using the removed VLAN.

  • Should we just ignore that change?
  • Mark the VLAN as removed and allow existing L2VPN to exist, but not allow new L2VPN service be created with that VLAN? (after freeing up the existing one)?
  • Remove the existing L2VPN and mark them with error status?

@YufengXin
Copy link
Collaborator

My opinion is to distinguish between management function and control function: this is a case of management function, which I think should be defined as out of scope for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

3 participants