Skip to main content

Last Call Review of draft-ietf-trill-active-active-connection-prob-05

Request Review of draft-ietf-trill-active-active-connection-prob
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-07-14
Requested 2014-07-06
Authors Yizhou Li , Hao Weiguo , Radia Perlman , Jon Hudson , Hongjun Zhai
I-D last updated 2014-07-21
Completed reviews Genart Last Call review of -05 by Vijay K. Gurbani (diff)
Secdir Last Call review of -05 by Vincent Roca (diff)
Opsdir Last Call review of -05 by Linda Dunbar (diff)
Assignment Reviewer Linda Dunbar
State Completed
Request Last Call review on draft-ietf-trill-active-active-connection-prob by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has issues
Completed 2014-07-21

As an OpArea Directorate, I reviewed
draft-ietf-trill-active-active-connection-prob-05. Here are my comments:

Section 2 second paragraph stated that “ TRILL AF provides both per Data Label
active-standby traffic spreading and loop avoidance”.

TRILL AF requires one and only one appointed RBridge to ingress/egress native
frames, so it doesn’t provides “traffic spreading”. I can see that End node
using VLAN to spread the traffic. But it is not “active-standby traffic

Suggest to change the wording to the following:

“TRILL AF provides loop avoidance. Without LAALP, End hosts can spread traffic
based on VLAN. But it requires administrative configuration”.

What is “flow rather than VLAN based load balancing”? does it mean the CE has
to  distribute load based on non-VLAN header fields of the packets?

Flow based loading balancing maybe same as load balancing based any L2-L7

Section 2.1:  What does it mean by “at exactly one edge group RBridge”?

a) The LAALP will deliver a frame from an endnode to TRILL at exactly one edge
group RBridge.

Suggest to add

“a single packet will never be delivered by two or more member links of a
single MC-LAG simultaneously”.

Why can’t LAALP assume “

"these are all the MAC addresses attached


Section 3.3: Address Flip-Flop

Why current TRILL switches behave badly when same MAC-SA is associated with
different TRILL nicknames? Why can’t TRILL switches be configured to allow
different TRILL nicknames to be associated with the same MAC-SA?

Need some extra explanation.

Section 3.4:

The flooding described in this section is no different from the “flooding”
caused by aged out MAC entry in FDB, isn’t it? So it is not big deal.

Linda Dunbar