[rbridge] Ingress Rbridge and FTAG again

[Gray, Eric]

The argument that "You're changing things, and while you're at it,
why not change these other things" is a particularly obnoxious old 
Dinosaur.  

We have a charter to change certain things, and requirements to 
preserve certain other things.

If you cannot show why it is necessary to do what you propose in
order to accomplish our chartered goals, or meet our preservation
requirements, then you need to establish a consensus to change 
our charter.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
--> Sent: Friday, October 20, 2006 1:32 PM
--> To: Joe Touch
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 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
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->