RBridge%20Protocol%20Extensions%20Proposal

1
RBridge ProtocolExtensions Proposal

• Donald Eastlake 3rd
• Donald.Eastlake_at_motorola.com
• Acknoledgements Erik Nordmark erik.nordmark_at_sun.c
  om, Radia Perlman radia.perlman_at_sun.com

2
Why RBridge Extensions?

• Proof by Assumption
• It is intuitively obvious that protocols need an
  extension facility
• Proof by Tradition
• All IETF Protocols have extensions
• Proof by Aesthetics
• Extensible protocols are beautiful, nonextensible
  ones are ugly
• Proof by Intimidation
• Any fool can see that protocols need an extension
  mechanism
• To support following possible extensions to
  RBridge
• LIDs (Local IDs) if there isnt consensus to put
  them into the fixed shim
• Security, such as Rbridge end to end
  authentication
• The most interesting extensions those we havent
  thought of yet

3
Typical Protocol Extension

• Add some option bits to the protocol header
  and/or use Type-Length-Value encoded trailer
  fields that all implementations would have to be
  able to parse.
• Do some sort of end-to-end negotiation to
  determine what versions of what options are
  supported.

4
RBridge Extensions Proposal

• Add reserved bits to announce supported options
  in the per-RBridge IS-IS flooded TLV element that
  announces nickname, etc...
• No extra negotiation messages required in
  simple cases.
• Include reserved bits in the shim to indicate
  that extension data is appended.
• Extension data only included for extensions
  present.
• No per-option type or length needed (unless
  variable length), as data only be included if
  destination understands it and its inclusion is
  indicated in the shim. Extension data appears in
  flag bit order.

5
Generic Example

• RBridge1 announces that it supports extensions B,
  C, and D. Per-RBridge IS-IS element has

A B C D E F G H
Nickname
Other Fields
0 1 1 1 0 0 0 0
RBridge1
Extension Flags

• RBridge2 supports and wishes to use extensions B
  and D in a frame to RBridge 1. Shim has

RBridge2
Other, BD flags
Ext. B Data
RBridge1
Ext. D Data
Ingress Egress
Extensions Data
6
Inclusion and Distribution

• For known unicast RBridge frames
• Only extensions supported by both ingress and
  egress are allowed.
• Extensions may be ignored by intervening
  RBridges.
• For broadcast/multicast/unknown RBridge frames
• Ingress RBridge can include any extension it
  understands.
• RBridges must remove any extension not understood
  by the next hop RBridge before forwarding.
• Thus broadcast/multicast/unknown distribution of
  extensions, even to egress RBridges that
  implement them, is unreliable unless all RBridges
  in the net suppot that extension.

7
Limitations and Advantages

• Limitations
• Generally restricted to extensions between end
  RBridges.
• Relable delivery only for known unicast unless
  every RBridge in the net understands the
  extension.
• Advantages
• Zero code in RBridges that do not implement any
  extensions.
• Zero end-to-end negotiation messages for simple
  extensions.
• Compact extension data because type and length
  information not generally required.

8
Shim Format Suggestion
Ingree RBridge nickname
A B C D E
Hop Count
K
Egress or tree-root RBridge
Extensions Size
Extension Bits

• Assumes 18 bit RBridge nicknames
• K Known unicast frame if 1, multicast/broadcast/
  unknown if 0.
• A, B, C, D spare reserved bits.
• E Extensions size and bits octets present.
  RBridges that do not support any extensions do
  not need to understand this bit.
• Extension size is there only so that intervening
  devices can always snoop beyond the shim in
  RBridge frames. Such devices need to understand
  the E bit and Extensions Size field.

9
Specific Unicast Example LIDs

• Note This is not meant to assert that there
  should or should not be LIDs or that they should
  or should not be an extension. It is just an
  example.
• Allocate one bit in the per RBridge IS-IS TLV to
  indicate LIDs are supported.
• Allocate one bit in the RBridge shim to indicate
  LIDS are present.
• When bit is on, a 16 bit ingress LID and 16 bit
  egress LID are appended to the shim.
• LID extension would only be used when both source
  and destination RBridges support it.

10
Documentation Suggestion

• RBridge protocol specification would include only
  the extension framework
• Each extension is documented in a separate
  document, requires an IETF Review for approval