TRILL RBridge Architecture IETF 69

1
TRILL RBridge ArchitectureIETF 69

• Progress and Changes since the last IETF (68
  Prague)

2
This Presentation

• Briefly talks about changes since the last
  meeting
• Raises issues/concerns for discussion and WG
  decision/consensus
• Outlines changes currently expected for the next
  revision

3
Goals in this Iteration

• Update the document to reflect terms and
  definitions agreed on since the last meeting.
• Terminology discussion
• Involved all those who had expressed interest in
  being directly involved
• Silvano, Dinesh, Joe, Radia, Erik, Donald, Eric
• Led by Silvano
• Conducted entirely by E-Mail
• roughly 350 messages exchanged over the course of
  about 20 days, shortly after the last meeting
  (early to mid April)
• time allowed to incorporate changes in drafts
• relatively small number of exchanges last month
  and early this month

4
Latest Revision

• Outlined on the mailing list (a PDF version
  including change bars can be made available, if
  needed)
• Includes changes to the terminology section to
  reflect the discussion we had
• Changes to the text to align with the new
  terminology and definitions
• Over-all, relatively minor update

5
Some Questions

• Do people feel that there are, or may be issues
  that need to be touched on in the Architecture
  document, relative to
• Multipathing (does more need to be said?)
• Setting the initial hop-count value (maybe
  something about issues/considerations?)
• Divergence between unicast/multipoint paths?
• Other concepts discussed on the mailing list?
• Is there a consensus on the model to be used
  relative to VLANs (and - particularly - per-VLAN
  IS-IS Instances)?
• What else needs to be said in the architecture
  document about the optimizations weve decided to
  require support for?

6
VLAN Related Interactions

• Specification of RBridge activity within a single
  VLAN instance
• Avoids many complicated protocol interactions
• Clarifies the assumption that L3 (IP) routing
  occurs between VLANs
• Modeled as logical VLAN overlays using physical
  devices and links
• Requires (logical) IS-IS instances on a per-VLAN
  basis
• Note that this is a logical model, and has only
  very limited impact on implementation
• People have expressed the opinion that not
  requiring per-VLAN IS-IS instances is simpler

7
Future Update

• Input on specific sections?
• Add More details/discussion in specific sections?
• Incorporate now-defunct routing requirements
• Incorporate text/figures from the protocol
  specification thought to be architectural
• Any changes required to align with comments and
  mailing list consensus

8
Finally

• Optimistically hope to complete one more revision
  and depending on WG opinion go to WG last
  call before next meeting
• Pessimistically, this may take multiple revisions
  hence expect a shorter cycle time on future
  revisions