Steps towards an 802.1ad draft

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)