[Rift] AD Review of draft-ietf-rift-rift-16 (4.2.3.3.1)
Alvaro Retana <aretana.ietf@gmail.com> Wed, 15 February 2023 13:00 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AC5C17D667; Wed, 15 Feb 2023 05:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClPWOxJow8dG; Wed, 15 Feb 2023 05:00:05 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4080C17CEA1; Wed, 15 Feb 2023 05:00:04 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id bd35so7595957pfb.6; Wed, 15 Feb 2023 05:00:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:from:from:to:cc:subject:date:message-id:reply-to; bh=nCGjjKX7jHZ46NbB/NRTTzc2tEESgqGfnQkuZNDC1TU=; b=o1Ab8BCDRQRWRyj9KHwtSdUwZcxOAjCQoZ7gmzvsef5h9+jTifYmrzvuwfLrSVMcep QJNhenAh2fL3YzA449Pq9tDnG8exFnV09BwA9qMeST3tic/T8+ymYRnJr3Gr2TiPhJuu lK8w+PeY665Tb64e/R03xKJo/8h1/zxgAEFkidkULvZYbQFTx9hj0wpNXv3GqUlWreAQ CF68UG7Jou0bwR6ykj7zihOljIgcvo7U5wXlCZQrt+pRgkFa/9C1IJxOHS0BQmwazTaV c44Ky6ygHto1hC9pBBhVIV0i/4Srf7ZqsOUa6YTxUkc3+DVdvUWFAoHzy5BxM+QiJDwc Dz0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nCGjjKX7jHZ46NbB/NRTTzc2tEESgqGfnQkuZNDC1TU=; b=IhtLatCywTOUJKAsMsFdstDvuzDzv/5qJdTDSyvqxUakTvBiZgqvkr1QkVKK8LyiGl M1uF4mQeqkI5aTvWkqEiLgAVnI7san59RxM1ASJ2dLvOkE+24k1taziJOzyKw/87AlGh SMyz7iqN3U6wAm59GHDd/5DRgtQXDbesimPAAGnAF8DK+c3370SBD0YtKIcnUrWD/ny0 jFqgrPyq/pIjeyK9fiLfUyZgCJNlNG2KVlwHDSl5StH6BTnaJe1dTcyB7pqrr8vJb+Jq ehpGKxZ71699vkF/r5huERumno1nrtCATbWBUvH6GqqfzUa2VPHwctr2lB63QZXc7gWh 1vSA==
X-Gm-Message-State: AO0yUKU3HyHXSGAeZpi8/6XmxE4T0AjQreUifWuWUYPDBnZm2HY/cozz U5h4I3U47RL+nzFIfiDtEjBClQ9GuivVo4x3sl0=
X-Google-Smtp-Source: AK7set/oGb1Q3btPI9UhWVc192Pe68HGGV28RIg6n8mgHOplw4p3lU+WMGjIOHyiOueIq9C4o/FWKb8IrrO44shUV1M=
X-Received: by 2002:aa7:8f17:0:b0:598:b25d:fdb2 with SMTP id x23-20020aa78f17000000b00598b25dfdb2mr345658pfr.0.1676466003952; Wed, 15 Feb 2023 05:00:03 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Feb 2023 05:00:02 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Wed, 15 Feb 2023 05:00:02 -0800
Message-ID: <CAMMESszF5yKx6t5nQNX8XhM_38iO8cdEWHoMsVOUDfsJiZvh0w@mail.gmail.com>
To: Jordan Head <jhead@juniper.net>
Cc: draft-ietf-rift-rift@ietf.org, rift-chairs@ietf.org, "rift@ietf.org" <rift@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/kCWcNVsx6bxS0eyYwcVKpQPx1IU>
Subject: [Rift] AD Review of draft-ietf-rift-rift-16 (4.2.3.3.1)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2023 13:00:06 -0000
Hi! This message contains §4.2.3.3.1 and a couple of "detours" -- I pointed those out with separators; for example I dug introduce you_are_sending_too_quickly and the comments below indicate that this way: ===== <you_are_sending_too_quickly> ===== ... ===== </you_are_sending_too_quickly> ===== Alvaro. 2448 4.2.3.3.1. Normative Flooding Procedures 2450 On reception of a TIE with an undefined level value in the packet 2451 header the node MAY issue a warning and indiscriminately discard the 2452 packet. Such packets can be useful however to establish e.g. via 2453 `instance_name`, `name` and `originator` elements in `LIEPacket` 2454 whether the cabling of the node fulfills expectations, even before 2455 ZTP procedures determine levels across the topology. [] This paragraph seems out of place. [major] "MAY issue a warning and indiscriminately discard the packet" Given that this is an option, what are the considerations to do so? Is the warning due to the "TIE with an undefined level" or to the fact that the packer was discarded? If the former, can the actions be performed independently of each other; for example, drop the packet but not log a warning? [minor] "indiscriminately discard...packets can be useful" I'm guessing that "indiscriminately" was used to emphasize the action. If the packet can se useful, but not flooded (since we're in this section), maybe the correct action is to ignore (not to discard). ?? [minor] "useful however to establish e.g. via `instance_name`, `name` and `originator` elements in `LIEPacket` whether the cabling of the node fulfills expectations" I'm guessing this is not explained anywhere and that it is probably an operational issue to be covered in the applicability document, right? 2457 This section specifies the precise, normative flooding mechanism and 2458 can be omitted unless the reader is pursuing an implementation of the 2459 protocol or looks for a deep understanding of underlying information 2460 distribution mechanism. [] This seems to be a better first-paragraph for the section. 2462 Flooding Procedures are described in terms of a flooding state of an 2463 adjacency and resulting operations on it driven by packet arrivals. 2464 The FSM itself has basically just a single state and is not well 2465 suited to represent the behavior. An implementation MUST either 2466 implement the given procedures in a verbatim manner or behave on the 2467 wire in the same way as the provided normative procedures of this 2468 paragraph. [nit] s/a flooding state/the flooding state [minor] "The FSM itself has basically just a single state and is not well suited to represent the behavior." There's no TIE FSM, right? Then why even mention it? [major] "MUST either implement the given procedures in a verbatim manner or behave on the wire in the same way as the provided normative procedures of this paragraph." Normative requirements with options are not great. s/MUST/is expected to Also, I don't know what the difference is between the options. 2470 RIFT does not specify any kind of flood rate limiting since such 2471 specifications always assume particular points in available 2472 technology speeds and feeds and those points are shifting at faster 2473 and faster rate (speed of light holding for the moment). [] Judgement about other technology. :-( Suggestion> RIFT does not specify any kind of flood rate limiting. Instead, the packets provide hints... 2475 To help with adjustement of flooding speeds the encoded packets 2476 provide hints to react accordingly to losses or overruns via 2477 `you_are_sending_too_quickly` in `LIEPacket` and `Packet Number` in 2478 security envelope described in Section 4.4.3. Flooding of all 2479 corresponding topology exchange elements SHOULD be performed at 2480 highest feasible rate whereas the rate of transmission MUST be 2481 throttled by reacting to packet elements and adequate features of the 2482 system such as e.g. queue lengths or congestion indications in the 2483 protocol packets. [nit] s/in `LIEPacket`/in the `LIEPacket` [nit] s/in security envelope/in the security envelope ===== <you_are_sending_too_quickly> ===== [] I went looking for `you_are_sending_too_quickly`: 2952 4.2.3.5. 'Flood Only Node TIEs' Bit 2954 RIFT includes an optional ECN (Explicit Congestion Notification) 2955 mechanism to prevent "flooding inrush" on restart or bring-up with 2956 many southbound neighbors. A node MAY set on its LIEs the 2957 corresponding `you_are_sending_too_quickly` flag to indicate to the 2958 neighbor that it should temporarily flood node TIEs only to it and 2959 slow down the flooding of any other TIEs. It SHOULD only set it in 2960 the southbound direction. The receiving node SHOULD accommodate the 2961 request to lessen the flooding load on the affected node if south of 2962 the sender and SHOULD ignore the indication if northbound. [nit] s/flood node TIEs only/only flood Node TIEs [major] "It SHOULD only set it in the southbound direction." The "SHOULD only" construct is always confusing. s/ A node MAY set on its LIEs the corresponding `you_are_sending_too_quickly` flag to indicate to the neighbor that it should temporarily flood node TIEs only to it and slow down the flooding of any other TIEs. It SHOULD only set it in the southbound direction. / A node MAY set the `you_are_sending_too_quickly` flag in its LIEs to indicate to southbound neighbors to temporarily only flood Node TIEs to it and slow down the flooding of any other TIEs. [major] "The receiving node ...SHOULD ignore the indication if northbound." s/northbound/north of the sender When is it ok to not ignore the indication if north of the sender? Why is this action recommended and not required? The schema says that it is "Ignored when received from southbound neighbor.", which sounds to me more like a "MUST". 2964 Obviously this mechanism is most useful in the southbound direction. 2965 The distribution of node TIEs guarantees correct behavior of 2966 algorithms like disaggregation or default route origination. 2967 Furthermore though, the use of this bit presents an inherent trade- 2968 off between processing load and convergence speed since suppressing 2969 flooding of northbound prefixes from neighbors permanently will lead 2970 to traffic loss. [minor] "Obviously this mechanism is most useful in the southbound direction." It may not be obvious to everyone... Is there any utility in the other direction? If `you_are_sending_too_quickly` is ignored anyway, it seems like this sentence is not needed. ===== </you_are_sending_too_quickly> ===== ===== <Packet Number> ===== [] I also went looking for `Packet Number`. Where's the Security Envelope in the schema? >From §4.4.3: 5275 Packet Number: 5276 16 bits. An optional, per adjacency, per packet type 5277 monotonically increasing number rolling over using sequence number 5278 arithmetic defined in Appendix A. A node SHOULD correctly set the 5279 number on subsequent packets or otherwise MUST set the value to 5280 `undefined_packet_number` as provided in the schema. This number 5281 can be used to detect losses and misordering in flooding for 5282 either operational purposes or in implementation to adjust 5283 flooding behavior to current link or buffer quality. This number 5284 MUST NOT be used to discard or validate the correctness of 5285 packets. Packet numbers are incremented on each interface and 5286 within that for each type of packet independently. This allows to 5287 parallelize packet generation and processing for different types 5288 within an implementation if so desired. [nit] s/using sequence number arithmetic/using the sequence number arithmetic [major] "SHOULD correctly set the number on subsequent packets" This is not a good Normative statement -- among other things, by recommending it you're opening the door for it to be ok for the number to not be "correctly set", not to mention the definition of "correct", etc. Given the references to Appendix A, it is Normative (right?), so perhaps the right approach is to simply drop the sentence. Suggestion> s/ An optional, per adjacency, per packet type monotonically increasing number rolling over using sequence number arithmetic defined in Appendix A. A node SHOULD correctly set the number on subsequent packets or otherwise MUST set the value to `undefined_packet_number` as provided in the schema. / An optional, per adjacency, per packet type number set using the sequence number arithmetic defined in Appendix A. If the arithmetic in Appendix A is not used the node MUST set the value to `undefined_packet_number`. ===== </Packet Number> ===== ===== <Appendix A> ===== [] I also looked at Appendix A. 6968 Appendix A. Sequence Number Binary Arithmetic 6970 The only reasonably reference to a cleaner than [RFC1982] sequence 6971 number solution is given in [Wikipedia]. It basically converts the 6972 problem into two complement's arithmetic. Assuming a straight two 6973 complement's subtractions on the bit-width of the sequence number the 6974 corresponding >: and =: relations are defined as: [] I'm not going to pretend to understand the details, but it seems that you're saying that RFC1982 is not great and that what is on Wikipedia is better -- Wikipedia claims the same thing. Besides not comparing what RIFT uses with other technology... The references to Appendix A are Normative (as in, Appendix A is how RIFT does it), right? But the reference to RFC1982 is listed as Normative while the one to Wikipedia is Informative. Which one should the implementation follow? The options I see are: RFC1982, Wikipedia, or Appendix A (the specification is self-contained there). I would be very happy with the answer being Appendix A as Wikipedia is not really a stable reference and you already said that RFC1982 is not a good solution. This would mean eliminating the two references and relying on the text in the Appendix. ===== </Appendix A> ===== 2485 A node SHOULD NOT send out any topology information elements if the 2486 adjacency is not in a "ThreeWay" state. No further tightening of 2487 this rule as to e.g. sequence is possible due to possible link 2488 buffering and re-ordering of LIEs and TIEs/TIDEs/TIREs in a real 2489 implementation for e.g. performance purposes. [major] "SHOULD NOT send...if the adjacency is not in a "ThreeWay" state" Is it ok to ever send TIEs if not in ThreeWay? Why is this behavior recommended and not required? §4.2.2.1 defines ThreeWay as: ThreeWay: this state signifies that ThreeWay valid LIEs from a neighbor are received. On achieving this state the link can be advertised in `neighbors` element in `NodeTIEElement`. I read that to mean that the TIE describing the local node MUST NOT be sent unless in ThreeWay. But that is different from forwarding other TIEs. I saw that the next sentence says that "No further tightening of this rule as to e.g. sequence is possible..." but what you wrote is not clear (maybe missing a couple of commas) and it doesn't seem to be related to origination vs flooding. 2491 A node MUST drop any received TIEs/TIDEs/TIREs unless it is in 2492 ThreeWay state. [] This sentence sort of answers some of my questions above. 2494 TIDEs and TIREs MUST NOT be re-flooded the way TIEs of other nodes 2495 MUST be always generated by the node itself and cross only to the 2496 neighboring node. [] Suggestion> TIEs generated by other nodes MUST be re-flooded. TIDEs and TIREs MUST NOT be re-flooded.
- [Rift] AD Review of draft-ietf-rift-rift-16 (4.2.… Alvaro Retana
- Re: [Rift] AD Review of draft-ietf-rift-rift-16 (… Antoni Przygienda
- Re: [Rift] AD Review of draft-ietf-rift-rift-16 (… Jordan Head