Subject: [rbridge] Ingress Rbridge and FTAG again

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 18 Oct 2006 10:17:27 -0700

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

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 18 Oct 2006 10:38:39 -0700

ddutt at cisco.com wrote:

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

Are you trying to optimize the sending of the BCN to the source
MAC address so that the encapsulating RBridge is known without
having to having stored that information in an intermediate or
core RBridge?

There is ultimately a need for core RBridges to be able to 
map source MAC address to source RBridge in order to forward
a BCN received from an 802.1au bridge that knows nothing 
about RBridges. So this optimization would be about reducing
table size and improving latency of BCN relay, rather than 
about eliminating logic.

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 18 Oct 2006 11:14:15 -0700

> having to having stored that information in an intermediate or
Yes.
> table size and improving latency of BCN relay, rather than 
Agree, but I don't want the advantages to seem trivial.

Dinesh

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 19 Oct 2006 10:29:54 -0700

> traceroute through the Rbridge network. This seems a critical feature to 

I buy Erik's observation that both addresses aren't strictly needed.
There's no traceroute through ethernet switches now; I don't see why
they ought to be supported uniquely in an rbridge.

> deployed if I have both ingress and egress addresses in a frame.

This argues for using an IP header as the shim, at which point we just
ought to deploy routers as rbridge nodes and call it a day. See below.

> and building multiple trees per source Rbridge ? Yes, but it is less 

IMO, tags argue either for VLANs over the rbridge (one per class) -
which we had already agreed was possible (I thought) or argues for using
an IP heaader with a flow tag. At which point we're back to IP.

Let's please not reinvent IP here. As I said in other messages, if
support for future use is the concern, it's more important to define
reserved bits than to fix their allocation now.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061019/6edcdc8e/signature.bin

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 20 Oct 2006 10:32:14 -0700

Good Morning,

> they ought to be supported uniquely in an rbridge.
Could you provide me with technical reasons why you think this is 
unnecessary ? Ethernet bridges today don't have IS-IS. Why invent that ? 
I repeat, troubleshooting networks is a critical aspect of any protocol. 
It can't be shoehorned in or added as an afterthought just like security 
cannot.
> ought to deploy routers as rbridge nodes and call it a day. See below.
I couldn't follow you here. Why does it assume an IP header as a shim ?
> reserved bits than to fix their allocation now.
Please see my email to Eric about FTAG vs VLAN. I disagree with your 
point of view that we're reinventing IP. The moment we chose to do 
IS-IS, provide multipathing at L2, we're changing what current L2 
networks do and some would argue that we're reinventing IP.

Dinesh