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

[Alia Atlas <[e-mail]>]

Any progress on responding to this one?  I'd like to get it into IETF Last
Call so that it can make the
Sept 17 IESG telechat - which means being ready by the Thurs a week from
now - at the latest.

Thanks,
Alia

On Fri, Jul 31, 2015 at 1:24 PM, Alia Atlas <[e-mail]> wrote:

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