[rbridge] Ingress Rbridge and FTAG again
Dinesh G Dutt
ddutt at cisco.com
Wed Oct 18 10:17:27 PDT 2006
I apologize for not responding to Joe's email earlier. I'd like to take
another a more verbose crack (compared to my previous rather terse
email) at stating why we need both ingress rbridge ID and FTAG.
Ingress Rbridge is essential for multiple purposes especially for
troubleshooting and for sending error messages or reports from the
middle of the Rbridge core to the ingress Rbridge. Consider for example,
the backward congestion notification scheme that is being pursued in
IEEE (802.1au). If I want to deploy that work in Rbridges, I need the
ability to signal congestion from the middle of the network back to the
ingress Rbridge or source end station. If I do not have the ingress
Rbridge in the frame, the only way to derive that address is by
populating all the edge MAC addresses in the core of the network; this
defeats one of the key objectives of an Rbridge, IMHO.
Over and over again, I've heard customers tell me that debugging the
network is a critical feature that they want built into the products.
With the help of TTL and ingress Rbridge ID, we can deliver a layer 2
traceroute through the Rbridge network. This seems a critical feature to
While I'll agree that having an ingress Rbridge isn't essential for
security as Silvano stated it, I also think it is not an incorrect case.
With an ingress Rbridge field in the frame, I can support customers who
envisage Silvano's way of doing things.
I'm unaware of any protocol, tunnelling or otherwise, that does not
carry both an ingress and egress endpoint address in the header. Before
you can utter that four letter word at me, remember that MPLS changes
labels hop-by-hop; so having an ingress and egress in MPLS is not very
useful. I can visualize other optimizations and features that can be
deployed if I have both ingress and egress addresses in a frame.
On the question of FTAG, I see three main usage cases.
- The approach currently being pursued in TRILL does not seem different
to me from the approach taken by 802.1D when they mandated a single
spanning tree for all VLANs. While TRILL doesn't suffer from the problem
of a single spanning tree, I can see various reasons why customers may
prefer to keep a small number of separate forwarding topologies, not
unlike a multiple spanning tree approach.
- With the advent of I/O consolidation, people will want to traffic
engineer their campus networks. FTAG allows you to do what MPLS did,
which is have the edge of the network decide based on some deep packet
inspection or such what forwarding topology that any frame follows and
have the core of the network follow that decision without having every
hop along the way having to make that decision.
- In case of multicast, the current approach seems focussed on only
source Rbridge trees. But there are many scenarios in the case of the
data center, where having a smaller number of shared trees and picking
one of these trees by hashing th group addr and such is sufficient and
more scalable. If we decide to support such a scheme, to avoid loops, it
is best to allow the ingress Rbridge to decide on the shared tree and
stick that information in the frame. FTAG carries that kind of
information. Is it possible to do all this using source Rbridge trees
and building multiple trees per source Rbridge ? Yes, but it is less
I'd like to reiterate that I share the concern of protocol overhead with
the others, but methinks the overhead of 16 bits (16-bit ingress ID,
16-bit egress ID, 16-bit TTL/FTAG maybe sufficient) is worth the bits.
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge