[rbridge] Ingress Rbridge and FTAG again

[Dinesh G Dutt]

Good Morning,

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

Dinesh

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