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

From: Alia Atlas <[email-masked]>
Date: Tue, 18 Aug 2015 11:38:44 -0400

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 <[email-masked]> wrote:

> Hi Donald,
>
> Thanks for the rapid response :-)  More in-line as always.
>
> On Fri, Jul 31, 2015 at 1:01 PM, Donald Eastlake <[email-masked]> wrote:
>
>> Hi Alia,
>>
>> On Fri, Jul 31, 2015 at 11:22 AM, Alia Atlas <[email-masked]> 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   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [email-masked]
>>
>> > Thanks again,
>> > Alia
>>
>
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 18 Aug 2015 13:43:29 -0400

Hi Alia,

My apologies for the delay. I believe the authors and I have good
resolutions for those of your comments that were not fully resolved
prviously. Please see below (deleting some older text in this thread).

Thanks,
Donald

PS: Although I will be somewhat in contact I'm on vacation at the
WorldCon (www.sasquan.org) from tomorrow through next Monday.
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Fri, Jul 31, 2015 at 1:24 PM, Alia Atlas <[email-masked]> wrote:
>...
>> > ...
>>...
> (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:
>
> RBridge of the RBv identified by the list of LAALPs, it associates
> the pseudo-nickname with the ports of these LAALPs and downloads the
> (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.

So, the problem here is that the text is draft-ietf-trill-cmt is based
on the older mind set that the "virtual RBridge" representing the
active-active edge group would be a pseudonode is the IS-IS sense;
that is, it would have a seven byte IS-IS System ID, have link state,
appear in the topology as a separate node adjacent to all the real
edge RBridge in the group, etc. (This original view is still reflected
in the file name of draft-ietf-trill-pseudonode-nickname.)

However, for a variety of reasons, this is no longer true. In the
scheme in draft-ietf-trill-pseudonode-nickname, the "virtual RBridge"
representing the edge group has a nickname but each of the real
RBridges in the edge group advertises that nickname as one of their
own nickanmes, well as advertising their "real" nickname.  (The base
TRILL protocol standard RFC 6325 provides for RBridges to hold
multiple nicknames. The original motivation for this was that, if an
RBridge was the source and/or sink for a lot of multi-destination
traffic, you might want multiple different least cost trees to be
rooted at that RBridge to spread the load and, since trees are
represented by the nickname of their root, that RBridge would need to
be identified by multiple nicknames.)

There is no need for any RBridge that is not part of the edge group to
know what nickname is the semi-permanent "real" nickname for an
RBridge and what nickname identifies the virtual RBridge. These
nicknames are all advertised in the same way. Adjacencies only exist
between real RBridges that are advertising link state notwithstanding
that such real RBridges may sometimes advertise that one of their
nicknames is a nickname that happens to identify a virtual RBridge.

When AFFINITY is used to associate a virtual RBridge RBv with tree t
at edge group RBridge RB1, RB1 will be advertising RBv as one of its
nicknames so the AFFINITY advertised by RB1 will be referring to
itself.

Two changes appear to be required to bring draft-ietf-trill-cmt up to
date with draft-ietf-trill-psuedonode-nickname:

OLD
   Each RBridge that desires to be the parent RBridge for child Rbridge
   RBy in a multi-destination distribution tree x announces the desired
   association using an Affinity sub-TLV. The child RBridge RBy is
   specified by its nickname (or one of its nicknames if it holds more
   than one).

NEW
   Each RBridge that desires to be the parent RBridge for child
   RBridge RBy in a multi-destination distribution tree x announces
   the desired association using an Affinity sub-TLV. The child is
   specified by its nickname. If an RBridge RB1 advertises an AFFINITY
   sub-TLV designating one its own nicknames N1 as its “child” in some
   distribution tree, the effect is that that nickname N1 is ignored
   when constructing other distribution trees. Thus the RPF check will
   enforce that only RB1 can use nickname N1 to do ingress/egress on
   tree x. (This has no effect on least cost path calculations for
   unicast traffic.)

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

NEW
   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 neither adjacent to RBn nor does nickname RBn identify RB1
   itself, that AFFINITY RECORD is in conflict with the campus
   topology and MUST be ignored.

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

See change below that consists of adding a reference on how tree
numbers are determined and adding "edge group" as a qualifier before
"RBridge" in two places.

OLD
   If n >= k

     Let's assume edge RBridges are sorted in numerically ascending
     order by IS-IS SystemID such that RB1 < RB2 < RBk. Each Rbridge in
     the numerically sorted list is assigned a monotonically increasing
     number j such that; RB1=0, RB2=1, RBi=j and RBi+1=j+1.

     Assign each tree to RBi such that tree number { (tree_number) %
     k}+1 } is assigned to RBridge i for tree_number from 1 to n. where
     n is the number of trees, k is the number of RBridges considered
     for tree allocation, and ''%'' is the integer division remainder
     operation.

   If n < k

     Distribution trees are assigned to RBridges RB1 to RBn, using the
     same algorithm as n >= k case. RBridges RBn+1 to RBk do not
     participate in active-active forwarding process on behalf of RBv.

NEW
   If n >= k

     Let's assume edge RBridges are sorted in numerically ascending
     order by IS-IS SystemID such that RB1 < RB2 < RBk. Each RBridge
     in the numerically sorted list is assigned a monotonically
     increasing number j such that; RB1=0, RB2=1, RBi=j and
     RBi+1=j+1. (See Section 4.5 of [RFC6325] as modified by Section
     3.4 of [RFC7180bis] for how tree numbers are determined.)

     Assign each tree to RBi such that tree number { (tree_number) %
     k}+1 } is assigned to edge group RBridge i for tree_number from 1
                           ^^^^^^^^^^
     to n. where n is the number of trees, k is the number of edge
                                                              ^^^^
     group RBridges considered for tree allocation, and ''%'' is the
     ^^^^^
     integer division remainder operation.

   If n < k

     Distribution trees are assigned to edge group RBridges RB1 to
                                        ^^^^^^^^^^
     RBn, using the same algorithm as n >= k case. RBridges RBn+1 to
     RBk do not participate in active-active forwarding process on
     behalf of RBv.

>> > 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.
>>
> Oh dear - if neither you nor I are certain, it definitely needs to
> be clarified.

The purpose of these timers is to minimize multi-destination packet
loss and/or duplication. Proposed OLD and NEW text is as follows:

OLD
   RBi upon start-up, starts advertising its presence through IS-IS
   LSPs and starts a timer T_i. Member RBridges detecting the presence
   of RBi start a timer T_j. Timer T_j SHOULD be at least < T_i/2.
   (Please see note below)

   Upon expiry of timer T_j, member RBridges recalculate the multi-
   destination tree assignment and advertised the related trees using
   Affinity sub-TLV.

   Upon expiry of timer T_i, RBi recalculate the multi-destination tree
   assignment and advertises the related trees using Affinity TLV.

   Note: Timers T_i and T_j are designed so as to minimize traffic down
   time and avoid multi-destination packet duplication.

NEW
   RBi, upon start-up, advertises its presence through IS-IS LSPs and
   starts a timer T_i. Other member RBridges of the edge group,
   detecting the presence of RBi, start a timer T_j.

   Upon expiry of timer T_j, other member RBridges recalculate the
   multi-destination tree assignment and advertised the related trees
   using Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculate
   the multi-destination tree assignment and advertises the related
   trees using Affinity TLV.

   If the new RBridge in the edge group calculates trees and starts to
   use one or more before the existing RBridges in the edge group
   recalculate, there could be duplication of packets (for example
   more than one edge group RBridge could decapsulate and forward a
   multi-destination frame on links into the active active group) or
   loss of packets (for example due to the Reverse Path Forwarding
   Check in the rest of the campus if two edge group RBridges are
   trying to forward on the same tree those from one will be
   iscarded).  Alternatively, if the new RBridge in the edge group
   calculates trees and starts to use one or more after the existing
   RBridges recalculate, there could be loss of data due to frames
   arriving at the new RBridge being black holed. Timers T_i and T_j
   should be initialized to values designed to minimize these problems
   keeping in mind that, in general, duplicating is a more serious
   problem than dropping. It is RECOMMENDED that T_j be less than T_i
   and a reasonable default is 1/2 of T_i.

I hope the above resolutions of your comments are satisfactory.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 18 Aug 2015 13:51:19 -0400

Donald,

Those changes look good.

Are there any implications for implementations?  Does this need another
WGLC due to
the changes around the AFFINITY sub-TLV?

Alia

On Tue, Aug 18, 2015 at 1:43 PM, Donald Eastlake <[email-masked]> wrote:

> there

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 18 Aug 2015 14:30:10 -0400

Hi Alia,

> Those changes look good.

Thanks.

> Are there any implications for implementations?  Does this need another WGLC
> due to the changes around the AFFINITY sub-TLV?

This specifies what the AFFINITY sub-TLV means when it is
self-referential, that is, it points at a nickname of the advertising
RBridge. This was not previously specified so I think of it more as
filling in a blank area than a change. It is up to the chairs if they
feel a brief WGLC is needed. Our earlier discussions of this have been
on the WG mailing list.

It is unlikely that an implementation based just on the current
trill-cmt text would handle this correctly.

Thanks,
Donald