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

From: Alia Atlas <[email-masked]>
Date: Fri, 31 Jul 2015 11:22:14 -0400

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.

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.

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?

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?

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.

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.

Thanks again,
Alia

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 31 Jul 2015 13:01:35 -0400

Hi Alia,

> draft, for their hard work and clear writing that makes this very easy to

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

> apologize for my part in the delay), but I'd like to get them moving rapidly
> now.

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

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

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

> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Fri, 31 Jul 2015 13:24:30 -0400

Hi Donald,

Thanks for the rapid response :-)  More in-line as always.

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

[Alia] thanks!

> rapidly

Right - so I agree that an RBridge can announce the tuple of
(pseudo-rbridge id,
LAALP ID) to indicate that the RBridge is attached to that virtual RBridge
for the
particular LAALP ID.  Probably, it isn't even necessary to include the
LAALP ID.

However, I don't see any text in draft-ietf-trill-pseudonode-nickname-04
that causes
this announcement to happen.  For instance, in Sec 9.2 where the handling
of a PN-RBv APPsub-TLV is discussed, at the end all that is done by the
receiver is:

"On receipt of such a sub-TLV, if RBn is not an LAALP related edge
   RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member
RBridge of the RBv identified by the list of LAALPs, it associates the
pseudo-nickname with the ports of these LAALPs and downloads the
association to data plane fast path logic."

So it sounds like what you are saying is that

a) RBridges announce the LAALP IDs that they are part of
(PN-LAALP-Membership APPsub-TLV) and the Designated RBridge announces the
nickname for the associated virtual RBridge.

and then something unspecified is done that is described in Sec 9.2 and
contradicts the claim that the sub-TLV is ignored.

I'm not saying the technology as implemented doesn't work - just that there
are clearly some missing details here that need to be written down.

> RFC 7180 (already a normative reference for this trill-cmt draft)
Sounds fine.

> assignment of edge group RBridges to trees.

Right - but this section doesn't specify that the intended behavior is just
for
the edge group RBridges.  IMHO, that would be useful for clarity.

> correct interpretation is. It should probably be clarified.

Oh dear - if neither you nor I are certain, it definitely needs to be
clarified.

Thanks,
Alia