Subject: [rbridge] Some comments on RBridge

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 11 Jul 2006 17:29:41 -0400

Radia,

	Some comments in line below...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Tuesday, July 11, 2006 10:16 AM
--> To: Eastlake III Donald-LDE008
--> Cc: rbridge at postel.org; Yang Yang
--> Subject: Re: [rbridge] Some comments on RBridge
--> 
--> It seemed like at the meeting some people were saying if we don't use 
--> the same Ethertype to specify "MPLSencoding", that there isn't any 
--> advantage to using this format, and others were saying that using the 
--> same Ethertype is asking for trouble because the label space would be 
--> overlapping. I suspect this is very implementation dependent, and there 
--> might be some implementations that would benefit from this encodings, 
--> and others it wouldn't help.

This is not quite in alignment with what I thought I heard in the
discussion.

There did not seem to be any argument that using a 32-bit shim 
might not be useful if it is not 100% consistent/compatible with 
MPLS labels.

What I thought some people were saying was that there might not
be any point in preserving the details of the format if we were
going to "break" compatibility by using a dfferent Ethertype.

One _interpretation_ of this - I believe was being argued - was
that we might re-use the BoS bit for some other purpose.  For a
few reasons, I personally don't think this is a good idea.  If
you follow this reasoning, for instance, you could equally well
argue that we could go with a 22-bit "nick-name" rather than to
reserve the EXP-bits space in the MPLS label format.

Clearly, these kind of arguments open up a can of worms that we
have seen the contents of before.  For this (and other) reason(s)
we should avoid re-hashing the format - given that the existing
format is "good enough."

I believe we may find that there are reasons why we might need
the BoS-bit down the road - just as there is likely to be good
reasons to use the EXP-bits.  I don't think we need to do this
in the RBridge protocol specification at this time, but the 
possibility that we may need to someday means we should think
about the consequences of needlessly churning an existing 
format.

Even if changing the Ethertype means that _some_ hardware may
not be directly re-used without modification, does not mean we
could not use the existing hardware with minimal modification.

Minimal modification means at least some savings in hardware
re-definition, re-spin, and re-certification.

Plus, there is the fact that not all hardware combines the 
demultiplexing of Ether-types and interpretation of Labels in
the same component.  For these cases, a lot of hardware re-use
is directly possible if we stick with existing MPLS label format 
details.

--> 
--> So the advantages of the MPLS-like format (with new Ethertype) is:
--> 
--> a) shorter (less overhead) than 8 bytes (which is probably what we'd use

--> for an RBridge ID, a hop count, and perhaps a priority field)

Assuming we use the same paradigm, but with the IS-IS system ID 
rather than a 19 bit nick-name, we would need:

Known Unicast/Other (Multicast/Broadcast/Flooded) De-mux Flag
Ingress/Egress System ID (at least the system unique portion)
TTL/Hop Count (by the way, this does work like TTL, right?)
Potentially a priority bit-field

I agree that this should fit in 8 bytes, but it may be close.

An often missed advantage of the shorter (19-bit) nickname is 
that - with a 19 bit name - it is possible to orient hardware 
around a litteral table look-up.

--> b) perhaps it would make some implementations easier
--> c) as long as we have to come up with a shim format, might as well use 
--> this encoding, since it has everything we want
--> 
--> The disadvantages are:
--> a) more complicated (because of the nickname acquisition protocol)...
-->    I don't think the nickname acquisition protocol is all that 
-->    complicated, but admittedly, with enough "let's do this one extra 
-->    thing because it's not that hard" can add up
--> 

IMO, we're going to absorb this complexity, either in the 
hardware or in the protocol.  My preference would be in the
protocol, but other people's mileage may vary.

-->
--> I can't think of any other disadvantages. People can feel free to add to

--> either list. But at any rate I don't think it matters a lot, and we 
--> should just pick one and not waste much time on this.
--> 
--> Radia
--> 
--> Eastlake III Donald-LDE008 wrote:
--> 
--> > Yes, RBridge forwarding is completely different from MPLS 
--> forwarding. 
--> > But the argument has been that a lot of effort has been 
--> invested in 
--> > hardware to efficiently process the MPLS header at high speed. 
--> > Therefore, it will be helpful to more rapid deployment 
--> and the more 
--> > widespread attainment of the prospective advantages of 
--> TRILL to re-use 
--> > the MPLS header format.
--> >  
--> > Donald
--> >
--> > 
--> ------------------------------------------------------------
--> ------------
--> > *From:* rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] 
--> > *On Behalf Of *Yang Yang
--> > *Sent:* Monday, July 10, 2006 8:15 PM
--> > *To:* rbridge at postel.org
--> > *Subject:* [rbridge] Some comments on RBridge
--> >
--> > Hello,
--> >    RBridge tries to adopt MPLS header. Are there any 
--> benefit to do so? 
--> > IMO, the forwarding behavior of RBridge is totally different from 
--> > MPLS. It's not possible to use the same forwarding componments.
--> >  
--> >    Best Regards!
--> >        Yang
--> >
--> >-----------------------------------------------------------
--> -------------
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://mailman.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->