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

• 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.

• 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.

B-1
A
B
RB-1
CRED
RB’
RB-2 B-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).

• Whether or not there is any intention (or usecase) 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.

RB-3
RB-2
RB-4
RB-1
RB-6
RB-5
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.

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.

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.

• 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?

• 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.

RB-1 RB-2 RB-3 RB-4 RB-5
RB-8 RB-6 RB-7
RB-12
RB-9
RB-14
RB-10 RB-11
RB-13
RB-15

• 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?

• 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?

• A relatively new technology and proposed requirement.
• Only works in “compatible cloud” scenario
• Has inconsistent potential impacts on the
RBridge solution
– It’s 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?

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.

• 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.

• 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”

• 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.