[rbridge] Ambiguity with IS-IS messages on PPP

[James Carlson]

Dinesh G Dutt writes:
> I do not like any solution that in Ethernet doesn't distinguish based on 
> the DA or an immediate ethertype. All control protocols so far have 
> relied on this property (at least on Ethernet) and is easiest to 
> implement in hardware. There is also precedence which makes hardware use 
> existing logic.
> 
> So, I dislike (d) for sure.

We're talking about an Ethertype, which behaves like a network layer
protocol -- specifically, a tunneling protocol that has a control and
a data portion.

As a former (reformed?) hardware implementor, it seems to me that if
you are parsing the TRILL header at all (which you must if you're
forwarding or doing encaps/decaps in hardware), then checking for a
single bit at a fixed location to determine whether what you're
looking at is control (kick to software) or data (forward normally) is
quite trivial.

Compared with the other issues that running unencapsulated causes --
the ambiguity with other L2 media and the MTU difficulties -- it seems
hard to say that this is a burden.

> I think (a) maybe simplest. With 64K possible protocol types, using two 
> seems in the noise. IEEE has also typically easily granted two protocol 
> types for distinguishing control from data frames.

Doing (e) (where we allocate from the 4xxx range) is much more likely
to fly through the working group, though it does still smell pretty
funny to me, and it leaves the MTU issue unresolved.

> If we go with inserting a "C" bit in the TRILL header, I vote for it to 
> be only relevant on PPP and that even if we must set the bit on 
> Ethernet, that the DA is the only way to identify IS-IS frames. I don't 
> want there to be the possibility of saying that we can use the IS-IS DA 
> to carry some form of data that is now distinguished based on the 
> presence of the "C" bit.

In this case (which is (d) from Radia's list), the DA is no longer
significant.  We can allocate a single multicast MAC address on
Ethernet, because the "C" bit unambiguously tells us whether we're
looking at control or data for that fixed TRILL Ethertype, and we
needn't bother with address checks.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677