[rbridge] Ingress Rbridge and FTAG again

[Dinesh G Dutt]

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

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 
scalable, IMHO.

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.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan