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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 13:58:53 -0400

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 27 Oct 2006 11:24:14 -0700

> compatible with 802.1D bridges.

It would not necessarily be true depending on the routes used. The paths
between rbridge nodes would be symmetric, since that uses 802.1D links,
but paths within an rbridge would have only symmetric ingress/egress
pairs. Internally, the paths could differ, but that shouldn't matter.

> proposals for textual changes (replace "XYZ" with "LMNOP")?

That'd be useful, but both terms might be needed; this isn't an IEEE
document, ultimately.

> with existing technologies without listing them all?

The document should list the techologies we depend on (802.1D) and
intend to replace per se. Again, this isn't an IEEE document, so a
comprehensive list of all IEEE-related technologies might be out of
scope. The chairs might suggest where that boundary would be.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061027/00f3de5b/signature.bin