Re: [trill] AD review of draft-ietf-trill-cmt-06

[Donald Eastlake <[e-mail]>]

Hi Alia,

On Fri, Jul 31, 2015 at 11:22 AM, Alia Atlas <[e-mail]> wrote:
> First, I'd like to thank Tissa, Janardhanan, and Jon, the authors of this
> draft, for their hard work and clear writing that makes this very easy to
> read and understand.

Note: Tissa is not longer with Cisco. I've added an email for him above.

> As is customary, I have done my AD review of draft-ietf-trill-cmt-06 before
> requesting IETF Last Call.  I do have a few comments that I hope can be
> addressed rapidly.
>
> I would really like to get IETF Last Call started on this draft (and the
> other two associated trill drafts that make sense to progress at the same
> time), but I do feel like some clarification or discussion is really needed.
>
> Today is the last day I can request IETF Last Call and still have the draft
> be on the August 20 telechat.  Otherwise, it will have to wait another two
> weeks.  I realize that these drafts have been waiting for a long time (and
> apologize for my part in the delay), but I'd like to get them moving rapidly
> now.

I'm sure the authors will correct me if I am wrong but here is my understanding:

> Major Issues:
>
> 1) In Sec 5.3, it says "If an RBridge RB1 advertises an Affinity sub-TLV
> with an AFFINITY RECORD that's ask for nickname RBn to be its child in
> any tree and RB1 is not adjacent to a real or virtual RBridge RBn,
> that AFFINITY RECORD is in conflict with the campus topology and MUST
> be ignored."  How does an RBridge determine the connectivity of a
> virtual RBridge RBn?  I can see that a Designated RBridge announces
> the pseudo-nickname for the vDRB to the other RBridges in the LAALPs
> (as described in draft-ietf-trill-pseudonode-nickname) but I don't see
> any specific way that the connectivity of a virtual RBridge is
> described and known by the other RBridges.  What am I missing?

Well, a virtual RBridge represents an edge group of RBridges that all
have ports to links that are part of an active-active group of links.
The RBridges in the edge group advertise in IS-IS an ID for that edge
group which is unique in that TRILL network (campus) -- usually pretty
easy as they just use the MC-LAG (or DRNI) ID. So all the members of
the edge group can see each other in the link state and the highest
priority member obtains and advertises in IS-IS the nickname for the
virtual RBridge representing that group. All RBRidge in the edge group
are assumed to be "connected" to that virtual RBridge.

> Minor Issues:
>
> 2) In Sec 5.1, it talks about the tree number.  Is how the tree number
> derived described elsewhere?  Is this something that each RBridge can
> do independently?  Could you add a reference?

Sure. Tree numbering was originally specified in the TRILL base
protocol document RFC 6235 and each RBridge independently determines
the trees and their number; however, this numbering was changed by
Section 3.4 of RFC 7180 which updates 6325. RFC 7180 is being replaced
by draft-ietf-trill-rfc7180bis and retains, still in Section 3.4, that
change. So, to avoid delays, probably a reference to Section 3.4 of
RFC 7180 (already a normative reference for this trill-cmt draft)
would be best.

> 3) In Sec 5.1, could you clarify which RBridges are doing the
> Distribution Tree provisioning?  I'm sure it's my lack of deep
> familiarity, but until I got to Sec 5.2, it wasn't at all clear to me.

I'm not sure that "Distribution Tree Provisioning" is the best name
for that section. In TRILL, every RBridge in the campus independently
computes the same set of distribution trees for the campus and each
tree reaches every RBridge (right now, this will change with
multi-topology, etc.). This section is about the assignment of edge
group RBridges to trees. They all know about all the trees due to how
tree calculation works in TRILL and they all know about all the
members of the edge group. So each member of the edge group does the
calculations described in 5.1 and they will all come up with the same
assignment of edge group RBridges to trees.

> 4) In Sec 5.6, it says "Timer T_j SHOULD be at least < T_i/2" Do you mean
> that timer T_j should be no more than T_i/2 or that timer T_j should be no
> less than T_i/2.  The "<" makes this unclear to me because the "at least"
> contradicts it; is it T_j < T_i/2 or T_i/2 < T_j.

I am less familiar with that provision so I'm not sure what the
correct interpretation is. It should probably be clarified.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanks again,
> Alia