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

[Silvano Gai]

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