Subject: [rbridge] encoding of TRILL IS-IS frames

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Oct 2008 15:43:37 -0700

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.

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.

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.

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"

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.

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

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 10 Oct 2008 17:10:52 -0700

Hi Radia,

I agree with all your points below. Further, I think that ESADI 
discussion is better off in a separate document than the base protocol 
spec. I'm concerned that it maybe not all right if and when someone 
plans a serious implementation of it. I want a very solid base protocol 
specification that is lean, precise and easy to  follow through with as 
little unnecessary stuff in it as possible.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 10 Oct 2008 22:32:25 -0400

See below...

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

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

> For core IS-IS frames, no encapsulation, but a special multicast 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.

> address in the inner Ethernet header a different multicast address

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

> 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

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Sat, 11 Oct 2008 04:37:14 -0700

Donald,

> RBridges need to listen for only one multicast address to receive
I do. We want to make it easy for the hardware to distinguish between 
control and data frames so that the control frames can be trapped easily 
and sent to the control processor. All protocols designed so far work 
that way. The control protocol always uses a separate MAC address than 
data frames.
> currently, they have an Inner.MacDA of All-IS-IS-Rbridges.
Again because it is additional logic for hardware to distinguish between 
control frames that they care about and control frames that they don't 
care about depending on the TRILL header contents. Using a separate MAC 
DA makes it simple. In some ways, ESADI is a different protocol.
> Devices that do not know that Ethertype know that can't parse the
Not even remotely true. The All-Rbridges-core-ISIS and 
All-Rbridges-ESADI-ISIS multicast addresses are unique. Today for L3 
ISIS, there is no addition of an IP header for example to address your 
issue above and no one has asked for it. This is the first instance 
where we're attempting to add a protocol header to IS-IS.
> IS-IS frames from any other protocol's attempt to use unencapsulated
I don't care for this optimization and I doubt if many of those who're 
building switches do. IEEE has set the standard of identifying control 
frames using the MAC DA and that's what we're suggesting. Why are we 
adding stuff that no other protocol so far has done or cared about. This 
is the kind of minor details that make a very nice protocol a pain to 
implement. There is a precedence, let's follow it. I don't want control 
and data frames to have the same MAC DA and I don't want them to do 
complicated parsing to achieve the same result with little or no benefit.
> such frames. I can think of options I might want to use.
What options ? Stick them as additional TLVs. By that logic, L3 IS-IS 
not having an IP header is a big limitation. I've not heard anybody 
making this argument.
> reserved bits to affect such frames or their processing.
I disagree. The control protocol has the versions supported. Any future 
version of TRILL MUST be able to understand the basic IS-IS TLVs.
> fields should an unexpected need arise.
I disagree. This is a major pain for implementation and sets a new 
precedence with zero to insignificant benefits. Let's follow what has 
been accepted so far and has been working well.

Dinesh

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 13 Oct 2008 11:27:28 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Saturday, October 11, 2008 4:37 AM
> To: Donald Eastlake
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] encoding of TRILL IS-IS frames
> 
...
> IEEE has set the standard of 
> identifying control 
> frames using the MAC DA and that's what we're suggesting. 
...

Just a point of clarification...IEEE used to use the
DA to identify the protocol but they are starting to
move away from that model.  Once AB-REV is published,
we will set xSTP and LLDP frames using the same MAC
address; what will be used to distinguish them, then,
is the protocol type.

I think as long as we have a combination of (MAC DA +
protocol type) that is unique for TRILL's IS-IS, we
should be OK.

Anoop

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 13 Oct 2008 14:09:16 -0700

I'm fine with MAC DA + Ethertype, but since it's much harder to get 
multiple ethertypes for the same protocol, I prefer multiple MAC 
addresses. But either approach is fine,

Dinesh

---

From: "Silvano Gai" <[email-masked]>
Date: Mon, 13 Oct 2008 14:49:07 -0700

I agree that "as long as we have a combination of (MAC DA +
protocol type) that is unique for TRILL's IS-IS, we
should be OK."

Since it is hard to get multiple Ethertype, I propose a single Ethertype
and multiple MAC-DAs.

I cannot emphasize more how important it is to have simple
classification criteria that are HW friendly.

-- Silvano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anoop Ghanwani
Sent: Monday, October 13, 2008 11:27 AM
To: Dinesh G Dutt; Donald Eastlake
Cc: Developing a hybrid router/bridge.; Radia Perlman
Subject: Re: [rbridge] encoding of TRILL IS-IS frames

...
...

Anoop

---

From: "Donald Eastlake" <[email-masked]>
Date: Wed, 29 Oct 2008 19:45:46 -0400

There seems to have been no further comment on this.

Just to be sure people understand what is being adopted: There is no
change in TRILL data frames. TRILL core IS-IS frames have a different
outer multicast destination address from data, presumably
All-IS-IS-RBridges, and are not TRILL encapsulated. The remaining case
is ESADI IS-IS frames which are, by default, treated almost exactly
like data. The should have an All-RBridges outer DA and be
encapsulated, like data, but have some new special inner destination
MAC address: All-ESADI-RBridges.

Thanks,
Donald

On Sat, Oct 11, 2008 at 7:37 AM, Dinesh G Dutt <[email-masked]> wrote:
> control and data frames so that the control frames can be trapped easily and
> sent to the control processor. All protocols designed so far work that way.
> The control protocol always uses a separate MAC address than data frames.
>>
> control frames that they care about and control frames that they don't care
> about depending on the TRILL header contents. Using a separate MAC DA makes
> it simple. In some ways, ESADI is a different protocol.
>>
>>
>>>
> All-Rbridges-ESADI-ISIS multicast addresses are unique. Today for L3 ISIS,
> there is no addition of an IP header for example to address your issue above
> and no one has asked for it. This is the first instance where we're
> attempting to add a protocol header to IS-IS.
>>
> frames using the MAC DA and that's what we're suggesting. Why are we adding
> stuff that no other protocol so far has done or cared about. This is the
> kind of minor details that make a very nice protocol a pain to implement.
> There is a precedence, let's follow it. I don't want control and data frames
> to have the same MAC DA and I don't want them to do complicated parsing to
> achieve the same result with little or no benefit.
>>
> What options ? Stick them as additional TLVs. By that logic, L3 IS-IS not
> having an IP header is a big limitation. I've not heard anybody making this
> argument.
>>
> precedence with zero to insignificant benefits. Let's follow what has been
> accepted so far and has been working well.
>
> Dinesh
>
> --
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
>
>