Subject: [rbridge] Base protocol working group last call early warning

From: "Donald Eastlake" <[email-masked]>
Date: Wed, 8 Oct 2008 22:50:05 -0400

Hi,
We plan to start a Working Group Last Call on the "Rbridges: Base Protocol
Specification" draft early next week.

Thanks,
Donald and Erik
=============================
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: Caitlin Bestler <[email-masked]>
Date: Fri, 10 Oct 2008 10:23:55 -0700

Does an RBridge implementation *use* 802.1 or does it
*include* an 802.1 implementation?

The problem statement implies that it *uses* 802.1.
 From the Abstract:

	This document assumes that solutions would not
	address issues of scalability beyond that of existing bridged 		 
(802.1) links, but that a solution would be backward compatible
	with 802.1, including hubs, bridges, and their existing
	plug-and-play capabilities.

That implies that RBridges would use the 802.1 defined EISS
interface, although that is not included in the cited list
of compatibilities.

However, Section 2.2 of the protocol discusses the encapsulation
in terms of 802.3, with PPP being given as one alternate encoding.

The presentation in this section could imply that an RBRidge 
implementation essentially subsumes the 802.1 role, including
being directly aware of 802.3 and alternate lower-layer L2s.

If TRILL *uses* 802.1 then the more correct description would be
that the TRILL Header, Inner Ethernet Header and Ethernet Payload
are submitted as the payload using EISS. The Elements that make
the Outer Ethernet Headers are parameters to EISS.

The diagrams presented in Section 2.2 represent the encapsulation
that the 802.1 layer will do in collaboration with 802.1 or PPP.
But to be totally correct, it does not specify them. IEEE documents
govern this behavior.

Up through 802.1Q-2005 this is strictly an academic question. The
processing between the EISS and ISS interfaces is very well understood
and there is no harm in integrating layers in implementation.

However, this could have an impact on the default interpretation of
TRILL interoperability with new 802.1Q amendments, especially those
in the Data Center Bridging. Interoperability with Provider Backbone
Bridging and Shortest Path Bridging may also be impacted.

I believe the best resolution here was covered previously in
mailing list discussions. We should just state than an RBridge
is a *client* of 802.1 services. That implies reasonable defaults
for RBridge interaction with post 2005 802.1 services. If there
are specific rationale for roto-tilling, as may be the case for
802.1Qau QCN (Congestion Notification) would require subsequent
drafts to justify and define them.

-----
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf

task group,

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 10 Oct 2008 19:34:11 -0400

Hi Caitlin,

A few comments below...

> *include* an 802.1 implementation?

I'm not sure exactly what you mean.

An RBridge incorporates parts which are the same as 802.1Q but does
not include all of 802.1Q. In particular it does not include any
version of spanning tree protocol (although it does limited parsing of
and can do very limited generation of BPDUs). On the other hand, as
far as I can tell, RBridges perform the identical VLAN processing to
that between the ISS and EISS interfaces in 802.1Q.

> interface, although that is not included in the cited list

I don't agree that it implies that. Backward compatibility seem
reasonably satisfied by the general ability to incrementally deploy
RBridges into a 802.1Q bridged LAN and and the ability to connect end
stations to an RBridge or a bridge.

> being directly aware of 802.3 and alternate lower-layer L2s.

I think that is the best way to look at it, even if RBridges
incorporate some blocks of processing from 802.1Q. RBridges use the
802.1Q port VLAN processing because it is convenient.

> the Outer Ethernet Headers are parameters to EISS.

The IETF generally doesn't do APIs. Figure 4.3 in the current protocol
draft indeed shows that native and TRILL frames being output to a port
of an RBridge can be thought of as going through an interface which is
logically equivalent to the 802.1Q EISS.

> drafts to justify and define them.

There is no 802.1Q bridge lurking inside an RBridge or inside an
RBridge port. The port VLAN processing between the RBridge equivalent
of ISS and EISS is the same as 802.1Q port VLAN processing between ISS
and EISS but, as far as I can see, the logic above and below that has
differences.

Thanks,
Donald

--

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 10 Oct 2008 16:47:29 -0700

Caitlin,

You know that I support your statements below. I believe originally 
Silvano and I had written (or maybe only just presented) what you say 
below esp w.r.t EISS. I think it is critical that we include this in the 
base protocol spec.

Thanks for sending this email yet again,

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: Mon, 13 Oct 2008 12:24:19 -0400

Caitlin and Dinesh,

I find the statement that "TRILL uses 802.1" to be somewhat vague and ambiguous.

The current specification makes it more or less clear that what it
calls "port VLAN processing" in an RBridge is the same as the
processing between ISS and EISS in a customer 802.1Q bridge. If you
want that to be made clearer or more prominent, I'd have no problem
with that.

If what you are trying to say is that the all the processing below the
EISS interface (including that below the ISS interface) is the same in
an RBridge and in a customer 802.1Q bridge, it seems to me that isn't
quite right. You could say that all the processing below the EISS
interface is the same as in a customer 802.1Q bridge except for the
handling of some control frames but I have the impression that you
wouldn't be satisfied by that...

Thanks,
Donald

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 13 Oct 2008 10:04:47 -0700

> wouldn't be satisfied by that...

Keep in mind that even for 802.1Q Bridges, the 802.1Q model does not
tell them how to process frames. Rather it is a detailed model that
accurately predicts how different protocol features will interact.
If you were to build a layered implementation which processed frames
in exactly this manner, you would achieve the correct results. There
may be many other methods of achieving the same result, and you are
encouraged to find them on your own.

In that same spirit, TRILL should be cleanly layered on top of 802.1
and the EISS interface. And using the EISS interface you really do
not know what the final frame looks like under 802.3, 802.11 or whatever
other protocol that may be selected. One of the strengths of TRILL is
that it ultimately does not care what transport gets the TRILL frames
from RBx to RBy. That's what layering is supposed to achieve.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 13 Oct 2008 10:43:51 -0700

Donald,

Here's one example where clearly stating where TRILL resides
compared to IEEE 802.1 would be a benefit: Section 4.4.2.2
states:

    The port on which the frame was received is first checked and the
    frame discarded if there is no TRILL core IS-IS adjacency on that
    port.

If it is clear that EISS is the relevant interface then there is
no ambiguity as to whether this is a logical (aggregated) port
or a physical port. It would also allow the TRILL core IS-IS
adjacency to be restricted to the controlled port (802.1X).

With clean layering we don't have to belabor issues like what
if any interactions there are between TRILL and Link Aggregation,
or MACsec.

Given the background of those working on TRILL, this is merely
documenting the assumptions that I believe everyone has made
while reviewing the draft. But assumptions are best explicitly
stated.

-----
Caitlin Bestler
[email-masked] -- http://www.asomi.com/CaitlinBestlerResume.pdf

---

From: "Donald Eastlake" <[email-masked]>
Date: Mon, 13 Oct 2008 21:00:04 -0400

Hi Caitlin,
That's a good example.

If the draft made it clear that the behavior is as if Hello (actually all
TRILL PDU) processing was above EISS, which is how I have been thinking of
it, that would fall out automatically.

Thanks,
Donald

---

From: "Donald Eastlake" <[email-masked]>
Date: Thu, 16 Oct 2008 15:59:23 -0400

Hi Caitlin,
Attached is a text file with a modified and simplified version of Figure 4.3
and some text which might be appropriate to add to Section 2.4 of the Draft.
Would that do what you want?

Thanks,
Donald

---

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

There appear to be a sufficient number of sufficiently significant
changes being discussed that we will probably not do a working group
last call until version -10 of the base protocol specification.

Thanks,
Donald

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 17 Oct 2008 09:17:55 -0700

Donald Eastlake wrote:
> Hi Caitlin,
> 
> Attached is a text file with a modified and simplified version of Figure 
> 4.3 and some text which might be appropriate to add to Section 2.4 of 
> the Draft. Would that do what you want?
> 

Yes, that diagram is very clear.

It may be worth explicitly stating that any statements in the TRILL
protocol documents about processing below EISS and ISS are intended
to be informative and are not to be interpreted in a way that 
contradicts the relevant IEEE 802 specifications.

-----
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.pdf
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge