TRILL RBridge Architecture

1
TRILL RBridge Architecture

• Changes prior to IETF-67
• Issues and Future Work
• Eric Gray, Ericsson

2
Changes in Recent Iterations

• Many minor wording changes
• Based on comments from Donald (mostly) and one or
  two others
• Specifically detailed in Email on the list in
  mid-September.
• Added text describing the wiring-closet problem
  and issues with it.

3
Issues to Be Addressed

• A few issues (requiring clarification) came up in
  review comments and on the mailing list.
• Do we want to address the wiring closet
  problem?
• Interaction with non-cooperating RBridges why
  forward RBridge control frames if the local
  RBridge cannot consume them?
• Issues with the use of TTL particularly for
  non-unicast or flooded traffic
• CFT, CFT-IRT and how many trees?
• Scalability, ECMP, BCN, etc.
• Do RBridges replace bridges, or routers?
• Optimality verses Orthogonality
• Drop verses process BPDUs
• Hopefully, we will soon come to closure on these
  issues.

4
Wiring Closet Problem (Review)
CRED
A
B-1
RB-1
RB
B
B-2
RB-2
How to ensure that links A and B get used? Do we
want to solve this, or is this something
we solve by suggesting that B-1 and B-2 should
be RBridges as well? Depends entirely on RBridge
complexity (cost).
5
Non-Cooperating RBridges

• Whether or not there is any intention (or
  use-case) for deliberately non-cooperating
  RBridges, it is possible that this will occur.
• The fact that we will be required to define
  security requirements for the protocol, and these
  will include (at least) authentication, it is
  actually likely that this will occur in a few
  deployment scenarios.
• The solution must be robust against this
  occurrence.
• The current wording in the architecture draft is
  intended to reflect this.

6
In any arbitrary topology involving the above
RBridges, if RB-1 is either misconfigured, or out
of sync with the other RBridges, it must appear
to be transparent relative to the peer
discovery protocol. If it is transparent, then
the peers will discover each other RB-1 is the
(trivial) solitary RBridge deployment scenario
a scenario which must work in any case and
the solution is robust.
7
RB-3
RB-2
RB-4
RB-1
RB-7
RB-6
RB-5
Similarly, if there is more than one RBridge
identically misconfigured, or out of sync, the
solution is robust. This is true because
similarly configured RBridges will cooperate with
each other, forming disjoint but overlapping
CREDs and all non-cooperating RBridges will be
transparent to each other.
8
RB-3
RB-2
RB-4
RB-1
RB-7
RB-6
RB-5
Finally, without loss of generality, this can be
shown to apply to any arbitrary combination of
two or more differently configured RBridges. At
one extreme, you have an arbitrary collection of
independent stand-alone RBridges in
the solitary RBridge deployment scenario . At
the other, multiple CREDs that are each
transparent to all others.
9
TTL Issues

• Use of TTL appears to be adequate for the unicast
  delivery case.
• What about for non-unicast and flooded traffic?
• TTL is most likely not adequate, without
  requiring other forms of mitigation.
• Need to modify the architecture draft to say
  something about this.
• What approach does the WG advocate?
• Use spanning tree for the non-unicast/flooded
  case
• Use a purge-or-mark approach with the CFT-IRT in
  the event of a topology change
• Require routing based loop avoidance techniques
• Require other loop mitigation techniques
• Some combination of the above?

10
CFT, CFT-IRT and How Many Trees?

• Do we use a per-ingress IRT (Ingress RBridge
  Tree), using SPF routing (similar to unicast), or
  some subset of this in the form of multiple
  spanning trees?
• Applies only to non-unicast and flooded traffic
  forwarding.
• Apparently driven in part by the need to
  distribute traffic across multiple paths.

11
(No Transcript)
12
Scalability

• Scalability
• This was essentially tabled as a requirement
  because (for one thing) it seemed unlikely we
  would be able to achieve anything like rough
  consensus on specific goals beyond a simple not
  worse, and possibly better goal.
• Is there a sense that we need to take this on as
  a chartered goal?

13
ECMP

• ECMP, multiple shared trees or other forms of
  multi-pathing
• The wording in the charter is currently unclear
  and appears to include this as a goal.
• Is this in fact a goal, or is the wording
  meant simply to indicate that an SPF-based
  solution is preferred based on link-utilization
  considerations?
• What are the use-cases that drive this as a
  requirement especially in light of the other
  goals of the TRILL WG?

14
BCN

• A relatively new technology and proposed
  requirement.
• Only works in compatible cloud scenario
• Has inconsistent potential impacts on the RBridge
  solution
• Its unreasonable to require BCN capable RBridges
  to keep MAC reachability information because of
  the potential scaling issues involved.
• Yet BCN only works in small domains where the
  total control-plane propagation delay is less
  than a milisecond.
• Can we have scaling issues in small networks?

15
Do RBridges Represent the Future of Routers, or
Bridges?

• Several recent proposals appear to want to put
  functionality that is typically provided by
  routers, into RBridges
• Policy based forwarding
• ACLs
• Firewall
• A few recent posts on the mailing list suggest
  that the TRILL solution should be based on the
  needs of customers who are looking to replace the
  routers in their networks with RBridges.
• I am reasonably sure that is not what we intend,
  but the WG needs to make this clear one way or
  the other.

16
Optimality verses Orthogonality

• RBridge protocols and encapsulations would
  ideally be treated as orthogonal to other
  protocols (routing, bridging) and encapsulations
  (802.3, 802.1Q).
• Similar observations have been made relative to
  multicast protocols (PIM, IGMP).
• In many cases (so far), the WG appears to be
  consistently leaning in the direction of
  optimization verses orthogonality in spite of
  issues relating to
• protocol complexity
• getting to specification closure.

17
Drop verses Process BPDU

• The intention was not to explicitly specify how
  RBridge implementations would be required to
  keep an eye out for topology changes
• Snooping BPDUs is allowed (because it is not
  explicitly forbidden),
• Other methods might be used.
• Some people feel that explicit specification is
  required.
• A new proposal is on the table that suggests
• rejecting the co-located bridge model and
• employing RBridges as STP participants that still
  terminate an STP domain

18
Still to Be Done

• Clarify tunnel injection text (section 3.2.3).
• Address recent comments from Silvano, et al
• Modify/clarify definitions
• Clarify architectural issues relating to traffic
  loops
• Other changes still being discussed.
• Potentially make (possibly extensive) changes to
  address new requirements recently proposed on the
  mailing list.
• Potentially address pending comments (from
  Donald)
• Address any comments that may come out of IEEE
  expert review.
• Complete WG Last Call.