[rbridge] Ingress Rbridge and FTAG again
Dinesh G Dutt
ddutt at cisco.com
Fri Oct 20 10:32:14 PDT 2006
Joe Touch wrote:
> There's no traceroute through ethernet switches now; I don't see why
> 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
>> 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.
> 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.
I couldn't follow you here. Why does it assume an IP header as a shim ?
> 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.
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.
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