Subject: [rbridge] Ingress Rbridge and FTAG again

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 20 Oct 2006 15:12:21 -0400

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

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 20 Oct 2006 12:45:26 -0700

Hi Eric,

> why not change these other things" is a particularly obnoxious old 
I have shown the reasons and with the exception of you and Joe, I 
haven't heard any objection to including the ingress Rbridge (at least) 
or the FTAG. So, from a democratic spirit, it is upto you two to give us 
technical reasons for objecting instead of saying "its not in the 
charter" or "you can't change that". The charter doesn't explicitly 
forbid doing traceroute, for example.

Dinesh

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

---

From: akatlas at gmail.com (Alia Atlas)
Date: Fri, 20 Oct 2006 14:09:25 -0700

Hi Dinesh,

> forbid doing traceroute, for example.

Just because one is content to for Eric to do the work of discussing a
common position doesn't indicate agreement with your position.

I certainly haven't heard a strong enough argument for including the
ingress rbridge.  For instance, if you really want traceroute equiv,
well, the encapsulated Ethernet frame contains  the source MAC from
right before the entrance to the rbridge area.  Why can't that be used
to get replies back?

As to the Ftag, I've not heard why the 3 bits that are equiv to the
EXP bits in an MPLS header coudn't be used to indicate a CoS related
mechanism.

I am particularly against the idea, that hasn't gotten much
discussion, of trying to include info about how the final rbridge
should direct a packet out.  I think this impacts the scalability &
requires additional knowledge be distributed to all the rbridges.  A
similiar thing can be done with the MPLS Layer-3 VPN, where a
different label is used to indicate the outgoing interface, etc.

Alia

---

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

Hi Alia,

> common position doesn't indicate agreement with your position.
I apologize if my email communicated that point. I wanted to say that 
I'm curious to hear other voices in favor of or against the suggested 
changes.
> right before the entrance to the rbridge area.  Why can't that be used
The reason is that this requires the core Rbridges to also populate the 
tables with the mapping from MAC address to Rbridge. Not requiring the 
core Rbridges to maintain a large MAC table is one of the advantages of 
Rbridges.
> EXP bits in an MPLS header coudn't be used to indicate a CoS related
Again, if you read my rather lengthy email, you'll see why three bits 
are insufficient. The main reasons stem from having to do shared 
multicast trees. Eric points out a way to do it using an additional .1Q 
header and redefining (I think) the meaning of the VLAN field. That has 
the disadvantages that I pointed out in my emails to him.
> different label is used to indicate the outgoing interface, etc.
If you're thinking about the LID, I don't think it is analogous to 
requiring an additional label. It is adding additional bits to the 
switchID that are of consequence to the final Rbridge only. Also, I 
understand that the arguments for including a LID may not be technically 
strong enough to merit the overhead they add.

Dinesh

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 23 Oct 2006 06:36:09 -0700

> forbid doing traceroute, for example.

Charters define what is permitted; that which is not permitted is
prohibited, unless it is needed to support what is permitted.

Otherwise, charters would be wide-open to anything not prohibited; we
don't have time to enumerate that list.

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/20061023/02c8c01a/signature.bin

---

From: akatlas at gmail.com (Alia Atlas)
Date: Mon, 23 Oct 2006 13:46:56 -0700

Hi Dinesh,

> core Rbridges to maintain a large MAC table is one of the advantages of

Not maintaining a large MAC table in hardware could be an advantage of
a core Rbridge.  However, given that the MAC to rbridge association is
provided through the routing protocol, even a core Rbridge will
certainly have the information available in software.   Could you
explain why you don't think this is sufficient?  Traceroute in IP is
frequently on the slowpath going through software; why would it need
to be different for this case?

> the disadvantages that I pointed out in my emails to him.

I had been scanning the emails & may have missed your argument about
three bits being insufficient.  How many shared multicast trees do you
think is sufficient and why?
Does the ingress Rbridge select which shared multicast tree to use for
a frame?   How are the shared multicast trees created and agreed upon?

If a frame is destined for a shared multicast tree, does the ingress
rbridge id in the shim have any relevance to the forwarding?

> strong enough to merit the overhead they add.

My concern  for the LID isn't just the bits that it adds to the
header.  It is the additional table space required by the hardware of
all the Rbridges to produce frames with different encapsulations based
upon the final outgoing interface.  Additionally, how many ports or
interfaces would be sufficient?  Why?

If you're not seriously trying to move that idea forward, there's
probably little point discussing it here, given the debate on the
other two.

Alia