Subject: [rbridge] Review of draft-ietf-trill-rbridge-protocol-13.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 30 Aug 2009 14:41:37 +0200

I was asked by the TRILL WG chairs to perform a review of
draft-ietf-trill-rbridge-protocol-13.txt. Below please find my findings.

I appreciate the work put by the editors and WG in designing this
solution and writing the document. The editors are to be saluted for
writing an I-D which is in most parts clear and well organized. 

I do believe that this work and the document as it stands still have a
number of problems that need to be solved.

1. I have serious reservations that this document can directly go to
Proposed Standard. For reasons detailed below there is a lot of
incertitude in what concerns the interoperability or coexistence with
the layer 2 protocols designed in the IEEE. Many of these are still work
in progress. For this good reason in many places the document is forced
to make assumptions and cannot make but statements like 'Rbridges are
generally compatible with IEEE ...' (section 2.4.2). Has the WG
discussed the option of issuing the first version of this document as
Experimental? 

2. It looks to me like the motivation of the standard is frozen in time
into a period of evolution of the IEEE 802.1 technology trying to solve
some problems that were in part dealt with by the IEEE in the meantime.
Out of the four spanning tree bullets listed in the introduction as
problems that TRILL solves the second and the fourth seem to have been
dealt with by the IEEE 802.1aq and the IEEE 802.1ak respectively. 

3. All the VLAN discussions in the specification mention only the
C-VLANs. What about provider bridges? Can these be migrated to Rbridges?
The explanation in Appendix E is not sufficient, the compatibility with
provider bridges needs to be dealt in the core part of the I-D. 

4. There needs to be more discussion about the IEEE protocols that do
not define forwarding or tagging. If TRILL makes a claim that the nest
migration policy is to replace IEEE bridges by Rbridges it needs to
define behavior relative to protocols like IEEE 802.1AE Media Access
Control (MAC) Security, IEEE 802.1AB Station and Media Access Control
Connectivity Discovery, and IEEE 802.1aj Two Port Media Relay, as
bridges and end stations that are being replaced may support any or a
combination of these. 

5. For all the reasons above I think it is required that this document
is also reviewed in detail by IEEE 802.1. I suggest that a formal review
be required via a liaison letter before or during IETF Last Call. 

6. It would be good to add a section that provides some estimates about
the operational impact of the deployment of TRILL. For example a claim
is made that TRILL will allow internal forwarding tables to be
substantially smaller than in conventional bridges (Abstract). How much
smaller? Is there an estimation of the level of extra traffic created by
TRILL? Any recommendations on tuning to make it more efficient? 

7. The claim made in the introduction section about TRILL avoiding the
problem of the 'significant configuration' required by the IP routers is
not substantiated but what follows. My reading of section 4.8.1 is that
although management configuration of ports and VLAN parameters is not
mandatory, it is highly recommended, and in its absence the protocol
cannot be expected to perform efficiently. 

8. Speaking about configuration parameters I could not locate the place
where the default interval between TRILL hello messages is defined and
how it can be changed. Maybe I missed it, if not please add this. 

9. In section 2, page 13, there is a recommendation to support SNMPv3
over IP. I think this actually should be mapping of SNMPv3 over UDP over
IPv4 (RFC 3417) and mapping of SNMP over UDP over IPv6 (RFC 3419)

10. I find confusing the claim in section 2.4.2 
   'If the bridges replaced by
   RBridges were zero configuration bridges, then their RBridge
   replacements will not require configuration."

I do not know what 'zero configuration' bridges are. I do not see an
Rbridge behaving better than a IEEE 802 bridge without configuration.
See also my comment #7. 

11. In section 4.1.1 

"  As specified in [802.1Q-2005], the priority field contains an
   unsigned value from 0 through 7 where 1 indicates the lowest
   priority, 7 the highest priority, and the default priority zero is
   considered to be higher than priority 1 but lower than priority 2."

This does not seem accurate, see Annex G in IEEE 802.1D-2005

12. Section 4.3.1 - it would be good to justify where the figure 1470
comes from. Also note that an end-station would not support such an MTU
unless it supports IEEE 802.3as, so it would be good to explain how
problems are avoided when an Rbridge replaces an IEEE 802.1 bridge that
connects to end-stations. 

13. I am confused about the need for section 5. The first part that
talks about assignment of multicast addresses seems redundant with
content in the IANA/IEEE considerations section. The second part tries
to list parameters that are configurable per Rbridge and per port? Than
many of the parameters listed in 4.8 and 4.9 are missing. 

14. Section 7.1 - I do not think that there is a need for registries of
the version numbers or Header reserved bits - these would be defined in
later versions of the protocol. For the TRILL Nicknames registry, the
appropriate RFC 5226 policy term is 'RFC Required' rather than 'RFC
Publication'.

15. Normative References - [802.3] has a 2008 edition

16. Annex E will certainly evolve in time until publication, as the IEEE
802.1 documents are also in evolution. At this point in time I would
suggest to add IEEE 802.1AB, IEEE 802.1AE and IEEE 802.1aj. Also IEEE
802.1aq, IEEE 802.1Qaw and IEEE 802.1Qay have been approved in the
meantime. 

I hope this helps. 

Regards,

Dan

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge