[rbridge] encoding of TRILL IS-IS frames

[Donald Eastlake]

See below...

On Fri, Oct 10, 2008 at 6:43 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
> Someone asked me why IS-IS frames need to be TRILL-encapsulated, and I
> don't remember. I do know we
> were somewhat concerned about differentiating TRILL IS-IS frames from
> layer 3 IS-IS frames. But assuming
> we use a different multicast address for TRILL IS-IS than layer 3 IS-IS,
> with the additional safeguard of
> using a different "area ID" (for TRILL, area ID=0), it seems like there
> would be no danger of confusion.

Yes, if all you are worried about is distinguishing TRILL IS-IS frames
from Layer 3 IS-IS frames when they are received by routers and
RBridges, then a different multi-cast address could be adequate. But
there are other considerations discussed below.

> Perhaps we were concerned about possible unicast of IS-IS frames, like
> for instance, a PSNP that one might
> send just to the DR? I think I verified with the IS-IS people that there
> are no IS-IS frames that are unicast.

There are no Layer 3 IS-IS frames that are unicast. However, according
to the current specification, TRILL frames (except for TRILL IS-IS
Hellos) that would otherwise be multicast MAY be unicast if there is
only one RBridge of interest out a port. This is to reduce the load
such frames would place on, for example, a complex bridged LAN where
they might otherwise be flooded. This applies to both TRILL data and
TRILL IS-IS frames. When an RBridge is processing a TRILL frame, after
a few early checks, the Outer.MacDA is ignored in the rest of the
processing. So it is currently not a big deal to the receiver whether
that outer DA is unicast, multicast, or even broadcast (which MAY be
treated as if it was multicast to All-Rbridges). In any case, the
Inner.MacDA for all TRILL IS-IS frames is All-IS-IS-RBridges.

> So why doesn't the following work?
>
> For core IS-IS frames, no encapsulation, but a special multicast address
> "all-nbr-TRILL-IS-IS" as
> the destination address.

What does "nbr" stand for? If you want to do away with encapsulation
for core TRILL IS-IS frames, I don't see any particular reason why you
couldn't just use the existing All-Rbridges multicast address so that
RBridges need to listen for only one multicast address to receive
TRILL frames.

> For ESADI, TRILL encapsulation like with ordinary data packets, but
> having as the destination
> address in the inner Ethernet header a different multicast address
> "all-ESADI-TRILL"

? Since ESADI frames need encapsulation and work fine in the current
protocol document, why change them at all? Like all TRILL IS-IS frames
currently, they have an Inner.MacDA of All-IS-IS-Rbridges.

> The advantage of this is that for core TRILL IS-IS, we'd save header
> room and probably work for
> RBridges to parse IS-IS packets.

Right, you save a little space but
       You vastly increase the probability of confusing anything TRILL
ignorant, such as network diagnostic equipment. With encapsulation,
all TRILL frame specific content is shielded by the TRILL Ethertype.
Devices that do not know that Ethertype know that can't parse the
following frame content.
       Such a change calls into question the optional optimization of
sending TRILL IS-IS frames (other than TRILL Hellos) unicast when
there is only one destination RBridge of interest out a port. At the
least, it would mean that TRILL would be the only protocol ever able
to use this optimization since, without the multicast destination
address or TRILL Ethertype, you could no longer tell unicast TRILL
IS-IS frames from any other protocol's attempt to use unencapsulated
IS-IS frames.
       You eliminate the possibility of using any TRILL options on
such frames. I can think of options I might want to use.
       You eliminate the possibility of using TRILL versions or header
reserved bits to affect such frames or their processing.

In all previous discussions of this sort of things, the working group
has clearly leaned in the direction of uniformity of processing, even
at the expense of a few more bytes, for reasons like those above and
to leave more freedom for possible future use of currently unused
fields should an unexpected need arise.

For these reasons, I believe that the core TRILL IS-IS frames should
remain encapsulated.

Thanks,
Donald

> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com