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

[Donald Eastlake <[e-mail]>]

Hi Alia,

On Tue, Aug 18, 2015 at 1:51 PM, Alia Atlas <[e-mail]> wrote:
> Donald,
>
> 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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Alia
>
> On Tue, Aug 18, 2015 at 1:43 PM, Donald Eastlake <[e-mail]> wrote:
>>
>> 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   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>>
>> On Fri, Jul 31, 2015 at 1:24 PM, Alia Atlas <[e-mail]> wrote:
>> > Hi Donald,
>> >...
>> > 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:
>> >> > ...
>> >>...
>> >>
>> >> > 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.
>>
>> 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.
>>
>> >> > Minor Issues:
>> >> > ...
>> >
>> >> > 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.
>>
>> 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.
>> >>
>> >> 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.
>>
>> 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.
>>
>> > Thanks,
>> > Alia
>> >
>> >> Thanks,
>> >> Donald
>> >> =============================
>> >>  Donald E. Eastlake 3rd   [phone] (cell)
>> >>  155 Beaver Street, Milford, MA 01757 USA
>> >>  [e-mail]
>> >>
>> >> > Thanks again,
>> >> > Alia
>
>