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

[Joe Touch]

Gray, Eric wrote:
> --> 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.

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.

> --> 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")?

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

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

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