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

Hi Dan,

Thanks for your efforts in providing these detailed comments.

On Sun, Aug 30, 2009 at 8:41 AM, Romascanu, Dan (Dan)<dromasca@avaya.com> wrote:
> 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?

It is true that many IEEE 802.1 standards efforts are "work in
progress". But with the ever multiplying number of efforts in 802.1,
this situation seems permanent. To wait for 802.1 standards efforts to
end would be to wait forever.

There is no actual question concerning the interoperability of TRILL
with current 802.1 protocols.

Section 2 of the draft is a broad overview. That is the reason it says
"... RBridges are generally compatible with IEEE [802.1Q-2005]
customer bridges ..." in Section 2.4.2. If all the details were given
in Section 2, it wouldn't be a broad introductory overview. To avoid
misleading readers, that phrase should probably be changed to
"... RBridges are compatible with IEEE [802.1Q-2005] customer bridges
except as discussed in this document ...".

I cannot recall any status other than Proposed Standard ever being
suggested in the TRILL working group for this document. The TRILL
protocol has had more review by routing and bridging network experts
than most IETF protocols at the Proposed Standard level. TRILL has
been implemented in software, tested, and the results of that testing
included back in the protocol design. Multiple vendors are very
interested in TRILL and I predict that RBridge products will ship in
2010.

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

It appears to me that this comment does not suggest any changes in the
draft. But, as a response, the TRILL WG was created by the IETF to
produce a standard subsequent to substantial discussion of the fact
that, after it rejected TRILL technology, IEEE 802.1 then started an
effort with similar goals. (And after the IEEE 802 Executive Committee
stated that it had no objection to the IETF pursuing development of a
TRILL standard.)

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

The TRILL protocol specified in this draft is, as stated in the draft,
a customer bridge standard. The draft is careful to refer to
802.1Q-2005 all over the place. An IEEE 802.1Q-2005 bridge is a purely
customer bridge.

This TRILL protocol specification does not try to solve the provider
bridge problem. (I believe it would be relatively easy to extend TRILL
to do that but it should be done in a separate document.)  Provider
bridges (and provider backbone bridges) cannot be replace by customer
bridges, whether those customer bridges are 802.1 customer bridges or
RBridges based on this spec. On the other hand, as stated in Appendix
E, provider bridges (and/or provider backbone bridges) can be used to
transparently interconnect parts of an RBridge campus.

Since RBridges are compatible with provider bridges and provider
backbone bridges, as I understand the word compatible, I don't
understand what there is to "deal" with. However, an appropriately
reworded version of the paragraph just above this paragraph can
certainly be added to the main body of the draft.

> 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 best
> 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.

This document does not claim that the best migration policy is
incremental replacement, just that a network of 802.1Q-2005 customer
bridges will, with the differences described in the document, operate
correctly if some or all are replaced by RBridges.

802.1 protocols such as 802.1AE, 802.1AB, and 802.1X and 802.3
protocols such as Link Aggregation are logically implemented within
ports. It makes no difference whether those ports are ports on 802.1D
or 802.1Q or RBridge or IP router devices. (And, assuming they
continue to develop in the direction it appears they are going, this
will also be true of 802.1Qaz and 802.1Qbb.) This layering is covered
in overview Section 2.4.1 and in more detail in Section 4.9.2 of the
draft. As far as I can see, the draft makes RBridge "behavior relative
to" this type of protocol, which is that they are orthogonal, clear.

It would be true that if someone is incrementally replacing
802.1Q-2005 bridges that are using one or more of these, for want of a
better term, "port level" protocols, such as 802.1AE, with RBridges,
then obviously they need to use RBridges that also have the same port
level protocols configured the same way. A statement to that effect
could be added to the draft.

802.1aj is a work in progress.  Although referred to as a "type of
bridge", as currently specified 802.1aj devices are, as far as I can
tell, a fancy type of repeater. For example, to quote from 802.1aj
Draft D4.0, "A MAC Relay is transparent to all frame-based media
independent protocols except those explicitly addressed to this
device." (Of course, 802.1aj repeaters have a management interface and
any node, whether a bridge or end station, could have independent
functionality added to it to interact with that management interface,
but I don't think of that as a change in the bridge or end station
functionality.) A statement could be added to the draft saying "RBridges
are compatible with IEEE 802.1aj devices as currently specified, in
the same sense that IEEE 802.1Q-2005 bridges are compatible with such
devices." or the like.

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

A review by IEEE 802.1 has been done. The TRILL draft has been
modified based on that review (see item 2 of "Changes from -12 to -13"
in Appendix Z).

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

The reason that forwarding tables are expected to be smaller is
explained in the draft. From the explanation given, it seems fairly
clear that the amount smaller primarily depends on the ratio between
the number of RBridges and the number of end stations.

What "extra" traffic do you refer to? The normal IS-IS control
traffic? If so, no, the working group has not produced an estimate of
how much IS-IS control traffic would be added. Nor has it produced an
estimate of how much the automatic use of shortest paths would
decrease traffic on the average link.

There has been no work yet (although, of course, this could be added
to a future Charter revision) on tuning of parameters. My opinion is
that it is premature to do so before TRILL is actually deployed in a
variety of environments.

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

Routers require subnet address configuration. Bridges, including
RBridges, do not require any similar address configuration. This is
what is being referred to and this can be clarified in the draft.

Need for VLAN configuration depends on application. I do not see how
it makes sense to make the blanket claim that "management
configuration of ports and VLAN parameters" is "highly recommended". It
is needed for some applications and totally unnecessary for others.

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

This is deferred to the IS-IS standard and/or IETF ISIS WG. The
Holding Time for a port is an IS-IS configuration parameter. The
number of Hellos per Holding Time, facilities for adding timing jitter
to avoid self-synchronization, etc., are all specified in IS-IS. It
would be reasonable to add a statement such as "TRILL Hellos should be
sent with the same timing as IS-IS LAN Hellos." or the like.

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

OK, that recommendation can be made more precise and explicit as
suggested.

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

"Zero configuration" means no configuration has been done, i.e., it is
run as out of the box with default settings, as in the former IETF
ZEROCONF working group. That phrase can be replaced with something
clearer. Is there any particular wording you would suggest?

By definition "unmanaged bridges", a well known product category, are
zero configuration because there is no way to configure them. A
"managed bridge" would be zero configuration if its configuration
features were not used.

All the quoted text is saying is that default configuration
802.1Q-2005 bridges can be incrementally replaced by default
configuration RBridges. As I say, this can be clarified.

> 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

Indeed, the draft does not reflect the 802.1D-2004 standard, which
specifies priority 2 as "spare". However, the draft's target is
802.1Q-2005 bridges. 802.1Q-2005 is specifically cited in the quoted
text above. In Appendix G of 802.1Q-2005 (page 282), priorities are
specified as described in this draft. In particular, in 802.1Q-2005,
priority 2 is specified as "Excellent Effort" and is the priority
between 0 and 3.

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

The problem was TRILL IS-IS frames too long to go through classic 1512
byte limit (called "basic frame" in 802.3as-2006) or possibly 1516
byte (called "Q-tagged frame" in 802.3as-2006) limit devices between
RBridges. I believe what 802.3as-2006 adds to previous 802.3 standards
is an "envelope frame" with a limit of 1996 bytes, which doesn't seem
relevant as it is much larger than 1470. (I'm including the source and
destination MAC addresses in these lengths. The lengths given in
802.3as-2006 are 12 bytes smaller but do not include those addresses.)

The problem is in being sure that IS-IS control messages (except, of
course, MTU size test messages that exceed the MTU) can get through
inter-RBridge links and the draft can be clarified to say so. End
stations are not relevant to the problem although, I would think, they
would mostly support the classic "basic frame" size or larger and thus
be able to handle 1470.

1470 was an engineering compromise between TRILL WG members as a value
which, with reasonable additional headers/tags/encapsulation/...,
would be extremely unlikely to run into MTU problems in real world use
of TRILL on IEEE 802.3 links. Some thought this default should be a
little lower or higher. In any case, this parameter can be configured
and the lowest configured value for an RBridge in the campus controls.

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

I guess Section 5 is an artifact of the way the document evolved. It
would indeed be an improvement to remove the first part and either
remove the second part and the whole section or make the second part
complete.

> 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'.

OK, that section can be modified as suggest
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge