To: P8021 From: Steve Horowitz Date: 7 Jun 96 15:49:30 Subject: VLAN Issues List The following are issues that I gleaned in conversations regarding VLAN standardization. Noted here so that we can keep an issues list to start resolving. If there are other issues or comments that I am missing, please respond and I will attempt to keep an updated list. A recommendation to keep mail threads clear. Create subject line referencing specific issue in brackets. For example, [2,1] references the duplicate address thread. Use separate emails for separate threads. Don't write in all caps. Don't pass go. Don't collect $200. (Just checking to see if you are awake.) 1. How do we connect VLAN devices that support different implicit mapping capabilities? 1.1 Treat them as separate VLANs entirely - force new type of device to either "bridge" them or route them. 1.2 Treat higher layer VLANs as proper subsets of lower layer VLANs, creating a VLAN hierarchy. Likely to require interpretation of VLAN tag - e.g. Use N bits (13?) to specify layer 2 VLAN and the remainder to specify layer 3 VLAN. Of course, if we decide to use 3 bits for priority out of the VLAN tag space, this becomes even less workable. 1.3 Ignore VLAN tag going to layer 3 device from layer 2 device - allow layer 3 device to associate VLANs based on implicit mappings even though explicitly tagged (sort of "bridging" VLANs). 2. Do we have to support duplicate addresses in separate VLANs? 2.1 Probably yes - DECNET Phase IV, Sun servers, Bridge/Routers, Token Ring VLANs, etc. What does this require in the forwarding architecture? 3. Loop Control - Spanning Tree(s). 3.1 If we decide to run more than one spanning tree, what benefit does this apply? 3.1.1 Load sharing 3.1.2 Works with existing bridge/routers. 3.2 If more than one tree - what is the method? 3.2.1 Separate encapsulated BPDUs - lots of traffic - lots of overhead in CPU 3.2.2. Packed BPDUs - lots of CPU overhead 3.2.3 Dancing Bears - one port bridge BPDUs - less overhead, issues of two layer trees and loop control - needs examination. 4.Tree pruning 4.1 GARP ' ? 5. Leaky VLANs 5.1 Allowed ? Issues of routing updates on wrong ports ... others? 5.2 Not allowed - what do you do with frames that have no VLAN mapping in real time? What does this do to the startup of the bridge (lots of dropped frames)? Will existing protocols be able to handle this? 6.Intelligent Multicasting relationship to VLANs 7. Policies of VLANs - i.e. security, priority, etc. as well as mapping criteria 8.VLAN information distribution 8.1SNMP 8.2Server 8.3GARP or related? 9. Interoperability of network management platforms w/r to VLANs. 9.1 How is vendor A box managed by vendor B platform? 9.2 How does vendor A platform xfer information to vendor B platform? (manually?) 9.3 Management of VLANs - stats? config? etc. 10, Two-layer frame format - is this VLAN related or is this IEEE 802.1r? 11. Frame translation formats - 'nuf said - see minutes from Lynnfield. Hope this helps - Steve witz@prominet.com