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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 1 Nov 2006 14:14:40 -0800

Eric,

If you want to use node instead of station that is fine, I agree that
this is common.

I am against the term cache, because it is so overloaded, unless you
explain what it really means.

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Wednesday, November 01, 2006 11:59 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Last Call comment on:
http://www.ietf.org/internet-
> drafts/draft-ietf-trill-prob-01.txt
> 
> Silvano,
> 
> 	I think that - with some minor exceptions - these are quite
> reasonable terminology change proposals over-all.  In particular,
> the idea of using frames to represent L2 PDUs is one that has been
> suggested before.
> 
> 	I suspect that we will need to expand the definition, or give
> a definition, for the term "node" to indicate that this term is
> meant to include the conceptual idea of a "station" as defined for
> the IEEE.
> 
> 	On the term "cache," this is generally a well understood term
> in this context and whether or not filtering database is more correct
> is something that may have to be considered on a case-by-case basis.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Saturday, October 28, 2006 10:59 AM
> --> To: Gray, Eric
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] Last Call comment on:
> --> http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-01.txt
> -->
> -->
> --> Per Eric request, this is the terminology changes I
> --> propose, to align
> --> these documents with a layer two terminology:
> -->
> --> Packet -> frame
> --> In IEEE 802.1D the term packet means something at higher
> --> level (IP and
> --> above)
> -->
> --> Autolearning -> learning
> -->
> --> Cache -> filtering database
> --> The term filtering database is consistently used to
> --> indicate that a hit
> --> on the database limit the frame propagation, while a miss causes
> --> flooding (this is a different behavior from a forwarding
> --> database, where
> --> a miss causes a drop).
> -->
> --> I am not sure about the term "Port autolearning" used in
> --> the draft, can
> --> you clarify the meaning?
> -->
> --> IEEE speaks about stations, this may be the most
> --> controversial change,
> --> but we need to settle on a single term.
> --> Node -> station
> --> Endnode -> station
> --> Host -> station
> -->
> --> -- Silvano
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > Sent: Friday, October 27, 2006 10:59 AM
> --> > To: Silvano Gai
> --> > Cc: rbridge at postel.org
> --> > Subject: RE: [rbridge] Last Call comment on:
> --> http://www.ietf.org/internet-
> --> > drafts/draft-ietf-trill-prob-01.txt
> --> >
> --> > 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] --
> -->