Subject: Re: [rbridge] Proposed resolution: Re: encoding of TRILL IS-IS frames

From: Radia Perlman <[email-masked]>
Date: Mon, 04 May 2009 22:31:59 -0700

Several people were not happy about the encapsulation of TRILL IS-IS 
frames in
version 12. After talking to a bunch of people, here is a proposed 
compromise:

The current spec says that the only thing differentiating a TRILL IS-IS 
frame from a
layer 3 IS-IS is the outer MAC DA. There were objections based on:
a) some links might not have DAs
b) IS-IS's SAP encoding precludes jumbograms, which would be possible 
using an Ethertype
c) not all control frames are multicast (e.g., MTU acks).

So, after discussion with a bunch of people,
it seems like the cleanest solution is to have a new Ethertype for
layer 2 IS-IS. For TRILL IS-IS frames that are multicast, we'd still
use a different multicast DA for TRILL IS-IS than layer 3 IS-IS, so
there would be both the Ethertype and the multicast DA to distinguish them.

For links that do not have DAs (like PPP), and for control packets that
are unicast (like MTU acks), the Ethertype would distinguish.

That would mean that TRILL IS-IS frames would look like:

outer Ethernet header:
  . SA (obvious)
  . DA (if multicast, "All-IS-IS-RBridges", if unicast, the intended 
recipient)
  . VLAN (usually the Designated VLAN, other than extra TRILL-Hellos
      that need to be "sprayed")
  . new Ethertype = l2-IS-IS

Then the TRILL IS-IS frame (LSP, CSNP, etc.)

ESADI would be the same, other than having an outer Ethernet header with
protocol type "TRILL", and a TRILL header. After the TRILL header
the ESADI would look like the above.

Radia

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Tue, 5 May 2009 05:58:47 -0700

It looks like the only change being proposed is the
use of a new Ethertype for TRILL IS-IS.

Sounds like a reasonable proposal.

Anoop

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, May 04, 2009 10:32 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Proposed resolution: Re: encoding of 
> TRILL IS-ISframes
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 06 May 2009 14:59:28 -0700

>   . new Ethertype = l2-IS-IS

*If* an IS-IS frame can ever be less than the Ethernet minimum of 60 
bytes, then there might be an issue here.

L3 IS-IS using the 802.3 header with a length field in place of an 
Ethernet type can tell from that length field the actual size of the 
frame before the sender padded it out to 60.

If TRILL IS-IS doesn't use the 802.3 length field then we'd need some 
other way to tell how large the frame was prior to padding to 60 bytes.

(Other protocols, like IP, which uses an Ethernet type have their own 
length field so they don't need the 802.3 length field. I don't know if 
IS-IS has its own length field or whether it relies on the 802.3 length 
field.)

    Erik

---

From: Radia Perlman <[email-masked]>
Date: Wed, 06 May 2009 18:20:32 -0700

Re: Erik pointing out that PDUs will have to be bigger than 60 bytes if 
we use
an Ethertype for TRILL- IS-IS

I'm not sure whether the minimum size constraint still exists when the 
technology isn't
CSMA/CD (anyone know?), but it seems like we could say that if an RBridge
wants to send any IS-IS PDU that would be smaller than 60 bytes, it has 
to include
the padding TLV (TLV type 8) to make it be at least size 60. I believe 
that TLV can
be included in any of the PDUs. (right?)

Radia

---

From: mike shand <[email-masked]>
Date: Thu, 07 May 2009 11:08:06 +0100

Erik Nordmark wrote:

Radia Perlman wrote:

outer Ethernet header:
. SA (obvious)

The IS-IS header always includes a "PDU length" field which indicates
the length of the entire PDU. (It also includes a header length field).

Erik