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: Wed, 1 Nov 2006 14:58:38 -0500

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