Subject: Review of draft-ietf-trill-prob-05

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2008 09:38:02 -0800

Review of draft-ietf-trill-prob-05.txt

I've reviewed this document as part of the transport area directorate's 
ongoing effort to review key IETF documents. These comments were written 
primarily for the transport area directors, but are copied to the document's 
authors for their information and to allow them to address any issues raised. 
The authors should consider this review together with any other last-call 
comments they receive. Please always CC [email-masked] if you reply to or 
forward this review. 

In general, I did not find any major transport issues that need to be addressed
within this document. 

The document does a good job of summarizing the motivations for 
TRILL, such as the desire to improve path efficiency (Section 2.1),
provide multipath support (Section 2.2), improve convergence
(Section 2.3), and improve stability of multicast operation (Section 2.4). 
Since the end result of addressing these issues should be improvement
in aggregate bandwidth as well as lower frame loss, the net result
should be quite positive for transport layer performance. 

At various points, the document pays appropriate attention to transport
implications such as reordering.  For example, within Section 3.1, 
the document states:

   Current Ethernet ensures in-order delivery for frames of the same
   priority and no duplicated frames, under normal operation (excepting
   transients during reconfiguration). These criteria apply in varying
   degrees to the different variants of Ethernet, e.g., basic Ethernet
   up through basic VLAN (802.1Q) ensures that all frames between two
   link addresses have both properties, but protocol/port VLAN (802.1v)
   ensures this only for packets with the same protocol and port. There
   are subtle implications to such a requirement. Bridge autolearning
   already is susceptible to moving nodes between ports, because
   previously learned associations between port and link address change.
   A TRILL solution could be similarly susceptible to such changes.
One question that did arise in my reading of the document was the degree to 
which TRILL would affect IEEE 802 mobility.  Section 2.6 states:
   Similarly, solutions to TRILL need not address link layer node
   migration, which can complicate the caches in learning bridges.
   Similar challenges exist in the ARP protocol, where link layer
   forwarding is not updated appropriately when nodes move to ports on
   other bridges. Again, the compartmentalization available in network
   routing, like that of network layer Autonomous Systems (ASes), can
   help hide the effect of migration. That is a side effect, however,
   and not a primary focus of this work.
 
However, in Section 3.5, the document also notes that
multiple points of attachment are likely to be better supported in TRILL:

   In STP, a single node with multiple attachments to a single spanning
   tree segment will always only get and send traffic over one of the
   those attachment points. TRILL must manage all traffic, including
   multicast and broadcast traffic, so as not to create feedback loops
   on Ethernet segments with multiple TRILL attachment points. This
   includes multiple attachments to a single TRILL node and attachments
   to multiple TRILL nodes.

I think what the Section 2.6 paragraph is trying to say is that TRILL 
will encounter some of the same issues as IEEE 802.1D with respect 
to changes in point of attachment.  

One such issue is how to rapidly seed the learning tables
and ARP caches on movement between attachment points.  For example, within
IEEE 802.11F, the AP spoofs a multicast frame on behalf of the Station 
(IEEE 802.11F) on receipt of an Association-Request, so as to seed the 
learning tables in advance of station attachment.  In DNAv4 (RFC 4436),
unicast ARP-Requests are sent in order to seed the router ARP cache,
providing for return reachability within a single exchange.  The 
motivation behind both of these devices is to minimize handoff
latency and frame loss. 

However, one of the reasons why these work-arounds were necessary
is that IEEE 802.1D only allows a node to have a single attachment
point.  This in turn has lead to prohibitions against the 
maintaince of multiple 802.11 associations within a single ESS, 
impeding "make before break" support. 

Given this, my overall take is that Section 2.6 may be selling
TRILL somewhat short.  While it's probably fair to say that
improved mobility support is not one of the major goals of
TRILL, my assumption is that TRILL will function at least as
well as a mechanism for connecting IEEE 802.11 access points
(particularly if they support 11n), and possibly considerably
better. 

My suggestion is that the paragraphs in Section 2.6 and 3.5
could be better harmonized, perhaps by mentioning TRILL
support for current mobility work-arounds, or noting the
positive mobility implications of support for multiple
simultaneous attachments. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf