Subject: [rbridge] IEEE 802.1 Comments on the protocol specification draft

From: Donald Eastlake <[email-masked]>
Date: Wed, 8 Apr 2009 22:22:43 -0400

Hi,

As suggested at the TRILL WG meeting in San Francisco, we are treating
the IEEE 802.1 comments as if they had been posted to this mailing
list:

On Sun, Apr 5, 2009 at 11:23 AM, Donald Eastlake <[email-masked]> wrote:
>  To TRILL WG co-chairs and IEEE-IETF liaisons:
> From: IEEE 802.1
>
> Thank you for your query of November 6, 2008, reproduced below so that
> it is clear what question is being answered:
>
> "As you know, the IETF TRILL Working Group has been developing a
> protocol for devices called RBridges (Routing Bridges).
>
> We believe that the draft specification of the TRILL protocol
> (the
> protocol that is implemented by RBridges) has reached a stage of
> maturity where, as required by the TRILL WG Charter, it would be
> appropriate to request IEEE 802.1 to comment on the draft,
> particularly from the point of view of its effect on the Ethernet
> Service model."
>
> A number of the members of IEEE 802.1 have read the draft-ietf-TRILL-
> rbridge-protocol-10.txt, draft-ietf-TRILL-rbridge-protocol-11.txt
> and the recent draft-ietf-TRILL-rbridge-protocol-12.txt.
>
> While we don't plan to comment on the details of the TRILL design there
> are statements in these revisions of the document with respect to IEEE
> 802.1 we would appreciate being revised.  It was our understanding at
> the outset of TRILL the design was planned to be link-layer agnostic
> however the current design only refers to IEEE 802.1. Further there are

(Probably meant to say 802.3 in the line above.)

> errors or inaccuracies in descriptions about IEEE 802.1 equipment used
> in conjunctions with Trill.

There may be such "errors or inaccuracies" but this message from IEEE
802.1 fails to point out any of them.

> IEEE 802.1 does not have an Ethernet Service model per se but we have
> an architecture that governs the design of 802.1 bridged networks and
> maintains compatibility among new and legacy IEEE 802.1 bridged
> networks.
>
> TRILL, as currently defined, depends upon a subset of 802.1Q. It is
> designed to integrate into a flat C-VLAN network and provide a
> different forwarding and control model from that specified in 802.1Q.

That is correct if you mean the 802.1Q with all currently completed
amendments. The RBridge base protocol specification defines "802.1Q",
as referenced in that specification, to be only 802.1Q-2005. An
attempt is made in the specification, in each instance, to explicitly
refer to any subsequent amendment part of which is referenced
(possibly the only such things are drop eligibility from 802.1ad and
MVRP from 802.1Qak). The RBridge base protocol specification also
states that it provides only customer bridging. Such statements start
in the Abstract where it says: "RBridges are compatible with previous
IEEE 802.1 customer bridges".

However, the draft can certainly be modified to make all this clearer.

> By inserting RBridges into a C-VLAN network a network structure is
> created that is incompatible with current 802.1Q S-VLAN and B-VLAN
> network architecture.  This incompatibility in network architecture may

It is the case that an RBridge conformant to the specification would
not know about and could not cooperate with "S-VLAN and B-VLAN network
architecture". But Provider Bridging (802.1ad) and Provider Backbone
Bridging (802.1ah) are designed, in general, to be transparent to
customer LAN traffic including, for example, TRILL encapsulated
traffic.

> create a complex network structure which, if not actually broken, will
> be difficult to administer and evolve.
>
> For example:
> 802.1Q includes:
> •
> Services based on Provider Bridges (Clause 16 IEEE 802.1Q) and
> Provider Backbone Bridges (Clause 25 IEEE 802.1Q) are not
> accounted for in TRILL.

As explained above, the current RBridge protocol specification
concerns itself only with customer bridging, Further I believe
RBridges could be extended to handle Provider Bridging.

> •
> OAM functions IEEE 802.1 Connectivity Fault Management (Clause 22
> IEEE 802.1Q) that are not accounted for in TRILL. TRILL weakens
> the applicability of CFM.

Indeed, the feeling in the TRILL WG seems to be that OAM additions of
some sort will be required for TRILL.

> •
> 802.1Q Bridge protocols provide a low probability of frame
> misordering, including during topology changes. New protocols
> such as Fibre channel over Ethernet depend on this behavior.
>
> 802.1Q will include:
> •
> Shortest Path Bridging. IEEE 802.1aq provides an example of how
> to conform to the architecture and include shortest path tree
> forwarding.

TRILL provides shortest path bridging without the scaling constraints
of 802.1aq.

> Our analysis was not complete and there are other aspects of IEEE 802.1
> that are changing behavior even on C-VLAN bridges (such as AV Bridging,
> Congestion management) that may not be compatible with TRILL RBridges
> in the future.
>
> Furthermore, it is impossible for 802.1 to effectively ensure any
> ongoing compatibility between 802.1 bridged network architecture and
> TRILL.  In consequence it is our opinion that the "effect on the
> Ethernet Service model" as we understand it could be severe and
> deleterious.
>
> Where the TRILL document refers to replacing IEEE 802.1Q Bridges, it
> would be more accurate to state that it supports only a limited subset
> of IEEE Std 802.1Q (including its approved amendments), and what that
> subset is. The document should also make it clear that there is no
> assurance of compatibility with future versions of IEEE Std 802.1Q,
> even within the limited subset identified.

As stated above, the RBridge protocol specification refers to
replacing IEEE 802.1Q-2005 Bridges, not IEEE 802.1Q + 802.1ad +
802.1ag + 802.1ak + 802.1ah + ... Bridges. This can be clarified in
the draft.

> ...

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