[trill] Benjamin Kaduk's No Objection on draft-ietf-trill-multilevel-single-nickname-15: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 22 September 2021 23:33 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC163A0E46; Wed, 22 Sep 2021 16:33:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trill-multilevel-single-nickname@ietf.org, shares@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163235358800.9389.10388636062686877154@ietfa.amsl.com>
Date: Wed, 22 Sep 2021 16:33:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/QVz5dsp9X1jU9o8nH6zd8aP8b9A>
Subject: [trill] Benjamin Kaduk's No Objection on draft-ietf-trill-multilevel-single-nickname-15: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2021 23:33:09 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-trill-multilevel-single-nickname-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a general remark, it seems that the use of the set of border nicknames to designate an L1 area means that for a degenerate case where there are exactly two L1 areas and the L2 area consists of all the border RBridges, we don't actually distinguish the L1 areas and so the setup is essentially degenerate with a non-multilevel TRILL. This doesn't seem problematic, though, and once the L2 topology becomes more complex (while remaining connected), uniqueness of L1 area identifiers seems guaranteed. It also feels a little like this draft is being progressed for sake of completeness rather than due to specific demand -- the shepherd writeup doesn't convey much sense of market demand (rather, it expresses a desire from the WG to press ahead to try to get traction in the market, even though there is IPR disclosed), and the history of the draft includes two periods of expiration and a few years of only minimal revision at the 6-month expiration boundary, that doesn't indicate much urgency to complete it. That said, the data I have at the moment isn't really strong enough to push me over to balloting Abstain instead of No Objection. 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.) 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. - 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}. - 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. 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)? 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 draffic 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"? 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 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. 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. 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. 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." 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? 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? Section 11.2 It seems that [IS-IS] ought to be a normative reference. 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". 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"?
- [trill] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [trill] Benjamin Kaduk's No Objection on draf… Donald Eastlake
- Re: [trill] Benjamin Kaduk's No Objection on draf… Donald Eastlake