[rbridge] IS-IS for TRILL interoperability issues

[James Carlson]

In testing our TRILL implementation, I've discovered that there's both
ambiguity in the current -11 I-D (separate designers here were able to
interpret the specification in incompatible ways), as well as serious
issues looming further down the road.

I recommend (1) including explicit diagrams of *all* of the packet
formats (currently, only the TRILL header is diagrammed), so that
there can be no confusion about the meaning of the English text, and
(2) reconsidering the recent "IS-IS unencapsulated" decision.

The first issue (specification ambiguity) revolves around the way
IS-IS frames are transmitted, and the interpretation of the word "and"
in this text:

      o  "TRILL" frames are those (1) with a multicast destination
         address allocated to the TRILL protocol (see Section 7.2) and
         (2) non-control frames with the TRILL Ethertype. There are

Assuming Ethernet, my reading of the current specification results in
TRILL IS-IS frames that look like this:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               All-IS-IS-RBridges MAC Destination              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     MAC Destination (cont)    |       Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source MAC Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Ethernet 802 Length Field   |   DSAP = FE   |   SSAP = FE   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   CTRL = 03   |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

That is, I read the "and" in the text to mean that any packet with
that special multicast destination *OR* with the appropriate Ethertype
is to be considered a "TRILL frame," and I understood "unencapsulated"
to mean that the *ONLY* thing distinguishing this from a regular IS-IS
frame was the destination MAC address (and woe unto those
implementations that don't filter multicast perfectly).

The other designer here apparently read that "and" literally, because
his frames look like this on the wire:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               All-IS-IS-RBridges MAC Destination              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     MAC Destination (cont)    |       Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source MAC Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        TRILL Ethertype        |   IDRP = 83   |   Length ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

Both seem plausible, and given the lack of information, it's possible
that others may read this specification in other ways, perhaps
including the LLC header with the Ethertype, depending on what those
readers consider to be the IS-IS frame.  Thus, I strongly encourage
the authors to include an appropriate diagram (such as the above) to
make the frame format unambiguous.

However, this observation leads directly into the second problem,
which I view as much less tractable.  Because of the "unencapsulated"
change, the specification now critically depends on Outer.MacDA.
Unfortunately, the presence of Outer.<mumble> itself depends on the
underlying medium.  When TRILL is run over something *other* than
Ethernet, those fields change.  For example, when run over PPP, there
are no Other.anything fields available at all other than a protocol
type.

A TRILL data packet on PPP would look like this (without header
compression):

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   ADDR = FF   |   CTRL = 03   |       TRILL Protocol ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V | R |M|Op-Length| Hop Count |   Egress RBridge Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ingress RBridge Nickname     |  Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

But what does a TRILL IS-IS packet look like on PPP?  There's no way
to set Outer.MacDA to distinguish this message, so the remaining
options appear to be:

  - Allocate two protocol IDs, one for TRILL data and the other for
    TRILL IS-IS.  (As the chair of PPP extensions, I can tell you that
    allocation of multiple protocol IDs for a single purpose would
    likely be viewed dimly by a significant number of participants.
    It just reeks of poor planning.)

  - Cheat on the TRILL header.  As long as the version field "V" is
    never set to '10', you can always tell an IS-IS frame by testing
    the first byte after the protocol ID: it's 83 for IS-IS, and
    anything else for TRILL.

  - Given both this problem and the subtle MTU issues, reconsider the
    "unencapsulated" decision, and put IS-IS frames after a TRILL
    header that includes a flag indicating whether the payload is
    IS-IS or data.

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