Subject: [rbridge] Should we optimize the common case?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 15 Nov 2006 16:02:05 -0500

Radia/Silvano,

	As I understand it, a summary of the current proposals (with 
apologies for omitting discussion prior to and including Guillermo's 
suggestion) would be as follows:

Radia suggests:

1 - create a MAC header with SA derived from combining ingress and
    sending RBridge nicknames, and DA derived from combining egress
    and receiving RBridge nicknames.  Variations -
    A) TTL is a separate field in the mutated MAC header
    B) TTL is embedded in one or the other derived "MAC address",
       or in some concatenation of both derived "MAC addresses" -
       still in the mutated header.

2 - including both ingress and egress RBridge nicknames in a SHIM,
    that also includes TTL.  Variations - 
    A) fixed (6 octet) length SHIM
    B) variable (6+ octet).

Radia stated a preference for 2.A.

Silvano's modification?

2.A (?) but including the option of using a standard MAC header with
the appropriate DA/SA for a point-to-point link.

=======================================================================

	IMO, Radia's proposals 1.A and 1.B are evidence of how far from
the beaten path we can wander when we try designing things in committee.

	With the exception of the fact that I am still not sold on the
notion that 12, 14 or 16 bits gives us a big-enough nickname space,
I agree that Radia's option 2.A makes sense.

	Alternative proposal 2.B suffers from the fact that it adds more
complexity to hardware implementation in every case in the misleading 
intention of reducing hardware implementation complexity in some cases.

	Given the fact that I think we're starting to gain some degree of 
convergence on the 2.A proposal, I am willing to go along with it.

	However, the additional option proposed by Silvano also suffers
from adding complexity in all cases by trying to simplify hardware in
some cases.  You might simplify your implementation by assuming it will
only ever be deployed in point-to-point networks, but that makes it more
difficult for an implementer who is targeting a super-set of deployment
scenarios your implementation targets.  Also, it will end up making your
implementation more complex by the time you discover that users don't
necessarily deploy things according to a vendor's plans in all cases.

	IMO, we should stick to a single SHIM format.  Also, I am very
much opposed to inventing any new MAC formats here in the IETF - and 
I think we are out of line in talking about doing so.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Tuesday, November 14, 2006 7:35 PM
--> To: Radia Perlman; Guillermo Ib??ez
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Should we optimize the common case?
--> 
--> 
--> Radia,
--> 
--> May I propose:
--> 
--> c) Your b) proposal plus the option that on point-to-point 
--> link we can use a well know destination MAC address, i.e. 
--> RBridge-Next-Hop. 
--> 
--> This allows building a simplified HW that works only on 
--> point-to-point links and that does not keep a next hop 
--> adjacency table.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
--> > Sent: Tuesday, November 14, 2006 6:59 AM
--> > To: Guillermo Ib??ez
--> > Cc: Caitlin Bestler; J. R. Rivers; Silvano Gai; rbridge at postel.org
--> > Subject: Re: [rbridge] Should we optimize the common case?
--> > 
--> > The first RBridge has to recognize a true MAC address, so we can't
--> > reassign endnodes hierarchicaladdresses. I think trying to see 
--> > nickname | nexthop as a hierarchical address is just confusing, 
--> > especially since the "hierarchical address" will change at every 
--> > hop. With the LIDs, it's sort of like a hierarchical address, but 
--> > not really, since lots of endnodes (all the ones on the same link) 
--> > will share the same "hierarchical address". But with Sanjay's 
--> > proposal of folding "egress nickname" and "next hop nickname" into 
--> > the destination address of the hop-by-hop header, this is *not* a
--> > hierarchical address of the destination endnode.
--> >
--> > And besides, this doesn't change the technical proposal, so trying
--> > to think of it that way is, I think, a digression.
--> > 
--> > The real question I think is between two proposals, with variants:
--> > 
--> > a) have 2 byte + Ethernet header: by folding next hop and egress
--> > nickname into "destination MAC" and transmitting RBridge and ingress 
--> > RBridge nickname into "source MAC", with TTL as the only thing left 
--> > over, with possible variant being folding TTL into the source and
--> > destination MACs as well.
--> > 
--> > b) have 6 byte + Ethernet header; putting ingress and egress RBridge
--> > nicknames and TTL into the 6 bytes; with possible variant being a 
--> > variable length shim to add things like LIDs.
--> > 
--> > I'd prefer b) with fixed length at 6 bytes. My second choice is a) 
--> > with the 2 byte addition for TTL, since I think also folding TTL 
--> > into the MACs will be even more confusing.
--> > 
--> > Radia
--> > 
--> > 
--> > 
--> > I do think we should allow advertisement of MAC address 
--> ranges in IS-IS
--> > endnode reports, because
--> > in some cases this will make smaller tables.
--> > 
--> > I'd prefer the "true" hop by hop header, where next hop 
--> and this hop is
--> > used as the MAC addresses,
--> > and a shim header with 6 bytes, partially because it is simpler to
--> > understand, and will be perceived as
--> > pretty straightforward compared with what routers do; 
--> i.e., take a piece
--> > of information, put an end-to
--> > end header (e.g., IP header, but in our case the shim with
--> > ingress/egress RBridge and
--> > TTL) on the information, and then hop by hop put a 
--> link-specific header
--> > on (e.g.,
--> > an Ethernet header).
--> > 
--> > Radia
--> > 
-- [SNIP] --

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 15 Nov 2006 14:43:59 -0800

Gray, Eric wrote:
...
> I agree that Radia's option 2.A makes sense.

Me too.

...
> I think we are out of line in talking about doing so.

I agree with this too.

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/20061115/2539063f/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 16 Nov 2006 07:49:08 +0100

>> I agree that Radia's option 2.A makes sense.
I think option 2.A makes most sense compared with the others.
>> I think we are out of line in talking about doing so.
The "invented" "new" MAC format is the standard MAC format for locally 
assigned L2 addresses. It is the handling which is different. So perhaps 
is more invention in the encapsulation and shim formats discussed.
I said before that TRILL is at an advanced stage of definition, for sure 
too late to discuss this questions.
I agree to stop discussion on this.