Sebastien Roy wrote: > ... > Proposal > ======== > > This proposal describes new Crossbow functionality for broadcasting > VLAN ID information to the network fabric. This consists of a > GVRP client system that, when enabled, will automatically register > VLAN IDs with the attached switch. > > We introduce two properties for a physical link: > > vlan-announce : The type of vlan announcements > gvrp-timeout : The timeout duration for GVRP resends > > The values for the vlan-announce property can be: > > off : No announcements are sent > gvrp : GVRP registrations are sent > > This allows for additional protocols to be added as the need for > them arise. > > The gvrp-timeout property can have the following range of values: > > 100-100000 : Timeout in milliseconds. > > The default values for these properties will be 'off' and '250', > closely matching the defaults of many switch GVRP implementations. > > Although this system uses GVRP to announce VLAN IDs, it is > not an implementation of full 802.1d GVRP protocol and state > machine. This project only sends request -- in order to > propagate VLAN information from VNICs/VSwitches/to real switches > and bridges. Specifically, the system does not process incoming > GVRP packets. An appropriate place to implement the full GVRP > state machine would be in the ethernet bridge module > (PSARC 2008/055).
The implication of the last sentence is that if we were to do a full GVRP at a later date then the administrative interface for it would somehow involve talking with the bridging module in Solaris rather than whatever this current project will do. If that were to be the case, how would that impact the link properties above? Should or would they be moved? Would we need a slightly different management interface that made managing GVRP more logical or will using discrete link properties be it? Darren
