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

[Alia Atlas <[e-mail]>]

Hi Donald,

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

On Fri, Jul 31, 2015 at 1:01 PM, Donald Eastlake <[e-mail]> wrote:

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

[Alia] thanks!


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

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.

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


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


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.



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

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

Thanks,
Alia


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