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 tsv-dir(_at_)ietf(_dot_)org 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf