1. Steps towards an 802.1ad draft Style of specification : A recommendation Mick Seaman

2. What is a bridge? A miscellaneous collection of learning and forwarding functions, more or less? Equipment conforming to 802.1D or 802.1Q? Definitely the latter!

3. A pure standalone standard Related to 802.1Q as 802.1Q is to 802.1D Restatement of service, network operation, addressing, bridge operation and mgmt. Extensive freedom of specification Not just a possibility but a certainty of reinvention (we can reinvent bridging too!) A ton of work, especially in alignment

4. A profiling standard Option selection from 802.1Q and 802.1D Forces examination and use of existing standard mechanisms No chance of accidental reinvention and misalignment Short standard, and not much work Over constraining for this application

5. Profiling with extensions Extensions limited to expanding functionality of known architectural entities Very powerful style but effective against reinvention Forces in depth understanding of what is specified already Short mandatory part May have extensive explanation, scene setting

6. Example 802.1ad specification Not a proposal for final text! Known to be not what is wanted by some at least However easily extensible with not much additional text to be what at least two people appear to want today A specification of the wart without the facial disfigurement

7. What the example does (1) Specifies provider bridges For construction of secured P-networks Provides multiple service instances to different customers by encapsulation Uses controls already defined in.1Q Uses protocols already defined in.1Q No new top level entities

8. What the example does (2) Provides a very rapid way to specify Q-in-Q Aligns closely with the way existing real bridges have been deployed in provider networks

9. What the example does not do (1) Multiple service instance selection on a single UNI –Two quite different approaches possible, one just varying existing control, other expands the existing VLAN classification process Define provider-provider interfaces Improve performance of L2 protocols over lossy and reordering links

10. What the example does not do (2) Provide any supporting tutorial information Sift through every L2 protocol to see where it terminates etc. etc. (this is a necessary study activity) Prevent different provider tag styles being standardised (actually makes it easy) Prevent extensions to user priority classification

11. Recommendation Adopt the profile with extension/expansion methodology as a guide to what we are attempting to mandate in this standard –Focus discussion and proposals from the start! Consider the proposed standard as an amendment to 802.1Q (and possibly as a future extension to the MAC Service Definition)