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

[Alia Atlas <[e-mail]>]

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