Hi Benjamin, I have posted a -17 version which I believe resolves your comments.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Sun, Oct 10, 2021 at 12:36 PM Donald Eastlake <[email protected]> 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 > <[email protected]> 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 +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
