[rbridge] Last Call comment on: http://www.ietf.org/internet- drafts/draft-ietf-trill-prob-01.txt

[Gray, Eric]

Silvano, et al,

	 Please see below.

-- [SNIP] --
--> I don't think it is acceptable to have temporary loop for broadcast
--> multicast, even if they are mitigated by TTL. An interlock mechanism
--> similar to ST must be used for multicast/broadcast.
--> 
--> I ask for a strong requirement that says: "TRILL MUST avoid
--> multicast/broadcast storms"

I completely agree with this and I have been assuming an "interlock"
function would be applied - especially for non-unicast or unknown
frames.

In retrospect, it is obvious that this should be explicitly spelled
out.

--> 
--> Sgai 2> ST provides symmetrical forwarding, i.e. the path from A to B is
--> the reverse of the path from B to A. Is this a requirement for TRILL?

I believe this has certainly been assumed in discussions, but it
might not have been deemed necessary to explicitly include this
as a "requirement" in the PA&S document.  It is a behavior that
applies to existing 802.1D bridges and we are required to be
compatible with 802.1D bridges.

--> 
--> Sgai 3> the terminology used in this draft is not the one used in IEEE
--> standards. This makes it difficult to understand what certain sentences
--> really mean. Concepts like autolearning and caches are not IEEE
concepts.

This observation has been made before.  Can you make specific 
proposals for textual changes (replace "XYZ" with "LMNOP")?

--> 
--> Sgai 4> There is no mention of the applicability of other important IEEE
--> standards/WG/Study Groups, e.g.
--> - 802.3ad-2000, Link Aggregation.
--> - 802.1ah - Provider Backbone Bridges
--> - 802.1aq - Shortest Path Bridging
--> - 802.1au - Congestion Notification
--> - 802.1ad - Provider Bridges 
--> - 802.1AE - MAC Security
--> - 802.3ar - Congestion Management Task Force.
--> - 802.3as - Frame Expansion Task Force.
--> I think this document needs to clearly state the position of the WG with
--> respect to these projects.
--> 
--> Sgai 5> I also think there need to be a mention of the applicability of
--> important industrial efforts:
--> - NIC Teaming
--> - uplinkfast
--> - split-MLT
--> - Q in Q
--> All these are widely deployed in all datacenters/enterprises. I think
--> this document needs to clearly state the position of the WG with respect
--> to these de fact standards.

Why?  Is it not sufficient to say that the solution must be compatible
with existing technologies without listing them all?

--> 
--> Sgai 6> Many customers look at TRILL as a backbone network. They would
--> like to connect their current switches to the TRILL backbone using
--> Etherchannel  and connecting the member links on different RBridges for
--> High availability. Is this a requirement? In general which is the
--> relation between Etherchannel and TRILL?

These are good questions, touching on at least one of the issues that
has been brought up previously (the "wiring closet problem").

I am not sure that the WG has reached consensus on this.  At present,
there appears to be a distinct "lean" toward simply listing the set
of existing deployment scenarios that may not be directly supported
using RBridges in a partial-deployment scenario.

--> 
--> Sgai 7> Does TRILL work properly if Ethernet is deployed with Pause
--> enabled?
-- [SNIP] --