[rbridge] Relationship with 802.1
d3e3e3 at gmail.com
Mon Oct 13 09:24:19 PDT 2008
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
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...
On Fri, Oct 10, 2008 at 7:47 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> 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,
> Caitlin Bestler wrote:
>> 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
>> cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>> task group,
>> rbridge mailing list
>> rbridge at postel.org
> We make our world significant by the courage of our questions and by
> the depth of our answers. - Carl Sagan
> rbridge mailing list
> rbridge at postel.org
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
More information about the rbridge