Steps towards an 802.1ad draft
Style of specification : A recommendation
Mick Seaman
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!
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
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
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
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
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
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
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
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
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)