Re: [trill] Benjamin Kaduk's No Objection on draft-ietf-trill-multilevel-single-nickname-15: (with COMMENT)

[Donald Eastlake <[e-mail]>]

Hi Benjamin,

I have posted a -17 version which I believe resolves your comments.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]
On Sun, Oct 10, 2021 at 12:36 PM Donald Eastlake <[e-mail]> wrote:
>
> Hi,
>
> Thanks for the detailed review. Sorry for the slow response. See below.
>
> On Wed, Sep 22, 2021 at 7:33 PM Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-trill-multilevel-single-nickname-15: No Objection
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > ...
> >
> > Section 3.1
> >
> >    -  RB3, when forwarding into area {3,30}, replaces the egress
> >       nickname in the TRILL header with RB44's nickname (44). (The
> >
> > I strongly suggest spending a few words to reiterate how RB3 knows to
> > replace 3 with 44 in this scenario.  (I.e., looking up based on D from
> > the packet contents.)
>
> OK. (It looks it up based on the destination MAC and data label (VLAN or FGL).)
>
> > Section 3.2
> >
> >            All border RBridges of an area MUST agree on a pseudorandom
> >    algorithm as the tie-breaker to locally determine the DBRB. The same
> >    pseudorandom algorithm will be reused in Section 4 for the purpose of
> >    load balancing. It's also possible to implement a certain election
> >    protocol to elect the DBRB. However, such kind of implementations are
> >    out the scope of this document. By default, the border RBridge with
> >    the smallest nickname, considered as an unsigned integer, is
> >    elected
> >    DBRB.
> >
> > (Editorial) It seems a little weird to me to write this as "MUST agree
> > on a pseudorandom algorithm ... oh but you could use leader election
> > instead as well, we just don't say how to" -- the "MUST" requirement
> > doesn't seem to match up with the actual requirement for correct
> > operation.  I tried to shuffle things around to make the actual "MUST"
> > requirement match up, as follows, though I'm not fully confident that my
> > proposal is actually correct...
> >
> > NEW:
> >
> > All border RBridges of an area MUST agree on a procedure for
> > determining the DBRB for the area.  This document assumes that the
> > border RBridge with smallest nickname (considered as an unsigned
> > integer) is elected DBRB, and that there is an agreed pseudo-random
> > algorithm as a tie-breaker (and reuses that algorithm in Section 4
> > for the purpose of load balancing), but that does not preclude the
> > use of leader-election or similar procedures.
>
> How about:
>    For proper operation, all border RBridges of an area MUST agree on
>    the DBRB for the area.  This document assumes that the
>    border RBridge with smallest nickname (considered as an unsigned
>    integer) is elected DBRB, and that there is an agreed pseudo-random
>    algorithm as a tie-breaker (and reuses that algorithm in Section 4
>    for the purpose of load balancing), but that does not preclude the
>    use of leader-election or other procedures.
>
> >    -  RB3, when forwarding into area {3,30}, replaces the egress
> >       nickname in the TRILL header with the root RBridge nickname of a
> >       distribution tree of L1 area {3,30} say 30. (Here, the ingress
> >       nickname MAY be replaced with a different area nickname selected
> >       from {2,20}, the set of border RBridges to the ingress area, as
> >       specified in Section 4.) Now suppose that RB27 has learned the
> >       location of D (attached to nickname 3), but RB3 does not know
> >       where D is. In that case, RB3 must turn the packet into a multi-
> >       destination packet and floods it on the distribution tree of L1
> >       area {3,30}.
> >
> > I think either there's a missing paragraph break here, or we need to
> > s/RB27/RB3/ -- RB27 is attached to S, but this part of the procedure is
> > discussing how RB3 is performing level transition to inject the packet
> > into area {3,30}.
>
> The wording can be improved. The two things it is talking about are (1) multidestination frames, in which case they would always have been sent on an L2 tree and are transitioned to an L1 tree, and (2) unicast frames that might have been sent to the border by unicast inside the source L1 and sent by unicast across L2 but have to be transitioned to a tree inside the destination L1 because the L2-to-L1 border RBridge has forgotten (or never knew if it just came up or it fell out of cache or whatever) the MAC&DataLabel of the destination end station. These should be more clearly distinguished but I think it makes sense to leave it as one paragraph since it is all talking about transitioning from L2 to an L1 distribution tree.
>
> >    -  RB30, will receive the packet flooded on the L1 tree by RB3. It is
> >       important that RB30 does not transition this packet back to L2.
> >       RB30 should also examine the ingress nickname of this packet. If
> >       this nickname is found to be an L2 border RBridge nickname, RB30
> >       must not transition the packet back to L2.
> >
> > The way this condition is written ("to be an L2 border RBridge
> > nickname", with no restriction to the area in which it's received) seems
> > to imply an assumption that any given border RBridge is in exactly one
> > level 1 area.  Since §6 of this document says that a given border
> > RBridge can connect multiple L1 areas, I think we should examine more
> > carefully the situation here when a given border RBridge uses multiple
> > nicknames for different L1 areas.  As written, this procedure might
> > result in failing to flood some packets to L2 at all.
>
> I don't actually see the problem here. It is talking about traffic being sent on an L1 distribution list after being transitioned from L2 to L1. Looking back at the original source L1 area, multidestination traffic is flooded on an L1 distribution tree there also but the ingress nickname is the actual source RBridge.
> Anyway, at the destination L1 area, R3 will have changed the destination nickname to the root of a distribution tree for the destination L1 area. The source nickname will be a border RBridge of the source L1 area. R3 sends the TRILL encapsulated frame with these changes on the L1 distribution tree. Say it arrives at R30. It does not actually make any difference if R30 is the root of that L1 distribution tree or not. R30 will continue to propagate the frame on the L1 distribution tree (although it might be a leaf and so not actually do anything for that L1 tree propagation). It needs to decide if it should also transition the frame to an L2 distribution tree. But it seems to me that the check to see if the ingress nickname is any L2/L1 border RBridge is a fine check. If it is, then the frame has already been distributed in L2 and MUST NOT be transitioned to L2. (If the ingress nickname is still the true L1 source (i.e., not a border RBridge), then R30 would transition it to L2 if it is the DBRB or, if it is not the DBRB, not transition it because some other border RBridge this is DBRB will have done that.)
> There is no problem with Rx being a border RBridge for multiple L1 areas. Each such L1 area will have a border RBridge that is its DBRB. Rx could be the DBRB for all, some, or none of the L1 areas for which it is a border RBridge. When a BUM frame arrives from L2, Rx transitions it to zero or more L1 distribution trees, one for each area it is DBRB for. Rx won't get any frames that it transitions to an L1 distribution tree but it might get a frame that had been transitioned to an L1 distribution tree for some L1 area that Rx is a border RBridge for but not the DBRB. If so, it indeed MUST NOT transition it back to L2 but will continue to propagate it on that L1 distribution tree.
>
> > Section 6
> >
> >    RBridge's nickname.  For a multicast packet: either RB1 is not the
> >    DBRB and RB1 will not transition the packet or RB1 is the DBRB. If
> >    RB1 is the DBRB, RB1 follows the following rules:
> >
> > We write "the DBRB" as if there is a single distinguished one.  But when
> > there are multiple L1 areas in play, IIUC each area can have a distinct
> > DBRB.  Should we specify which area RB1 needs to be the DBRB in in order
> > to trigger these procedures (or whether it must do so if it is a DBRB in
> > *any* area)?
>
> Sure, the wording can be clarified. I'll take a crack at doing so. But it just does the described behavior in parallel for each L1 area it is a border RBridge for.
>
> >       dropped by RB1. It recognizes such packets by their ingress
> >       nickname being the nickname of one of the border RBridges of an L1
> >       area to which the receiving border RBridge is attached.
> >
> > Similarly, if RB1 is not the DBRB for an area, the earlier requirement
> > to drop traffic from L2 and not pass it to that area, regardless of the
> > ingress nickname in use, seems to take priority.  So perhaps this should
> > be "of an L1 area for which the receiving border RBridge is the DBRB"?
>
> I agree with your comment and will see if I can clarify the wording.
>
> > Section 8
> >
> > Is there anything useful to say about the transient behavior as
> > information about a partition/repair propagates to the border RBridges
> > of the area?
>
> If an L1 area with multiple border RBridges partitions such that two or more fragments have border RBridges (it's always possible that part of the L1 area will become isolated), then each of the border RBridges involved will withdraw the Border RBridge Group (see Section 5.2) announcement for the old unified L1 and issue new such announcements for the new fragment for which it is a border RBridge.
>
> >    If an L1 Border RBridge Nickname is configured at an RBridge and that
> >    [...]
> >    nickname multilevel do not support the configuration of an L2 Border
> >    RBridge Nickname.  [...]
> >
> > Just to confirm, the distinction between "L1 Border RBridge Nickname"
> > and "L2 Border RBridge Nickname" is correct and as intended?  I think I
> > see one or two other instances of the "L2" form in the document, but
> > this one leaves me most uncertain of the group.
>
> Section 1, Introduction, says that border RBridges use the same nickname in L1 and L2 so I think this reference to different nicknames needs to be fixed.
>
> >    If there are multiple border RBridges between an L1 area and L2 and
> >    one or more of them only support or are only configured for unique
> >    nickname multilevel ([RFC8397]), any of these border RBridges that
> >    are configured to used single nickname multilevel as specified in
> >    this document MUST support [RFC8397] and fall back to behaving as a
> >    unique nickname border RBridge for that L1 area.  [...]
> >
> > Since this condition is predicated on the deployment environment, not
> > the local implementation, it seems to be a de facto requirement on all
> > implementations of this document to also support RFC 8397 and the
> > fallback.  Perhaps it's better to frame it that way.
>
> OK
>
> > I think we should also say something about how an implementation will
> > detect that there are other border RBridges in a given area that are
> > using unique nickname multilevel.
>
> OK. You can tell there are unique nickname border RBridge because they announce in the L1 area the block(s) of nicknames that are available for local use within the L1 area.
>
> > Section 9
> >
> >    The newly defined TRILL APPsub-TLVs in Section 5 are transported in
> >    IS-IS PDUs whose authenticity can be enforced using regular IS-IS
> >    security mechanism [IS-IS] [RFC5310]. This document raises no new
> >    security issues for IS-IS.
> >
> > Thanks for mentioning that IS-IS has a mechanism for authenticating PDUs
> > (and the corresponding implication that it's not the default behavior).
> > That said, I'm not sure that "raises no new security issues" is quite
> > correct, and would propose to adopt a formulation similar to what RFC
> > 8397 uses.  E.g., "malicious devices may fake the [sub-TLVs] to [attract
> > traffic, partition areas, induce excessive state on L2 RBridges, etc.].
> > For this reason, RBridges SHOULD be configured to use the IS-IS
> > Authenticaiton TLV (10) in the IS-IS PDUs, particularly those containing
> > [sub-TLVs], so that IS-IS security [RFC5310] can be used to authenticate
> > those PDUs and discard them if they are forged."
>
> OK.
>
> >    Using a variation of aggregated nicknames, and the resulting possible
> >    duplication of nicknames between areas, increases the possibility of
> >    a TRILL Data packet being delivered to the wrong egress RBridge if
> >
> > Increases compared to what baseline?
>
> The baseline of all RBridges in a TRILL campus being unique, which is the case for non-multi-level TRILL and for multi-level TRILL with unique nicknames.
>
> >    areas are unexpectedly merged. However, in many cases the data would
> >    be discarded at that egress RBridge because it would not match a
> >    known end station data label/MAC address.
> >
> > Is that true for broadcast/multicast or just unicast?
>
> It is true for broadcast/multicast with regard to data labels but not MAC addresses but it doesn't matter. broadcast/multicast is going to be flooded to all RBridges interested in the data label anyway.
>
> > Section 11.2
> >
> > It seems that [IS-IS] ought to be a normative reference.
>
> My question about this is, would changing the reference to normative require a new IETF Last Call?
>
> > NITS
> >
> > Section 4.1, 4.2
> >
> >    nickname. The selection is simply based on a pseudorandom algorithm
> >    as defined in Section 5.3 of [RFC7357]. With the random ingress
> >
> > Pedantically, the referenced document gives an example of a PRF, but
> > does not definitively define "a pseudorandom algorithm".  So "described"
> > or "discussed" might be more appropriate than "defined".
>
> Sure, can change it to "discussed".
>
> > Section 8
> >
> >    Other than the manageability considerations specified above, the
> >    manageability specifications in [RFC6325] still apply.
> >
> > Is this an "other than" or an "in addition to"?
>
> "in addition to" is clearer.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]