You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is much (error prone) repetition of VLAN lists in trunk definitions.
Really, we only have a few different list contents that are valid and they could (arguably should) be defined as trunk classes, then the trunk definition should reference those classes instead of listing individual VLANs.
Acceptance Criteria
There are multiple possible implementations:
Strictly use only one class in TRUNK/FIBER commands
Strictly use only a class list in TRUNK/FIBER commands (would require de-duping the resulting expansion)
Allow both classes and VLAN names as valid content for such commands (also would require deduping)
My personal current inclination is option 1. If anyone feels differently, please comment here and let's discuss.
The text was updated successfully, but these errors were encountered:
Description
Currently, there is much (error prone) repetition of VLAN lists in trunk definitions.
Really, we only have a few different list contents that are valid and they could (arguably should) be defined as trunk classes, then the trunk definition should reference those classes instead of listing individual VLANs.
Acceptance Criteria
There are multiple possible implementations:
My personal current inclination is option 1. If anyone feels differently, please comment here and let's discuss.
The text was updated successfully, but these errors were encountered: