[pim] Some comments on draft-ietf-pim-assert-packing-00

Stig Venaas <stig@venaas.com> Mon, 29 March 2021 20:33 UTC

Return-Path: <stig@venaas.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0B7243A20D4 for <pim@ietfa.amsl.com>; Mon, 29 Mar 2021 13:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RcWhzK9zCW6u for <pim@ietfa.amsl.com>; Mon, 29 Mar 2021 13:33:26 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAD23A20D3 for <pim@ietf.org>; Mon, 29 Mar 2021 13:33:26 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id y17so12328899ila.6 for <pim@ietf.org>; Mon, 29 Mar 2021 13:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=P+V39OppZioDnoEc+kn1aNXWlgO8AwZmT4cIUOgbWB4=; b=wWoH7fNvB+4TY0SG8Xs+AoqZ8T0sCwebT+7Kje70DDZx/b48Kn2GRmC0dmj+uJAQJn e2b7ae3m5KMOCWqBCAJKfepa+qfxlDs7zObqmGi82YCgItwnjyaeRSudGAqcFOO/f/6H U0fyU3If+3VpVob0naXiRa8Ui53Yd7A4hndsDSsUTAuEYm7RcJaUSWHkde3mcOTORTc5 IdGmUOXdLrTByhGlx1R9Na/m/IGO8YwbM0423164YrpU1SVtP+RQNIliNF1u7fSczV6g l4oWpsrWdl8XCUNIiSXdB5YI7BexWFMzggZoa9OoLKLn3cgAZLHg4X2Y+QineUorBaaj dOxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P+V39OppZioDnoEc+kn1aNXWlgO8AwZmT4cIUOgbWB4=; b=eDxK2gXPQfCYvM8lMwlBEWpNjekQlcwQNCUnxs12rv9R39As4+YLubGELT1Az6k+NS 4iUzFCRzSPRu9eXdLu76qSd7qeLuU+ugn2lsE7b5I8I6dL7WzF8e5etUfttZ6Pv1Lxmy TUzITa/QZFtXluF4fcEFmcSEMqkgr6qisEss9YLRhK+u8+DeW3QvE6UcCbH/sJIz4c6v KFnuoT2OcSmct8hK3ya2xhXHKMJ+Y7TejbKjdAPkYYgYiwczAy9J7dWbmbhwOpOun0Ke AQCNG0h25sP+jvfNr2TjZegF/DyHVR1Ny2lef7j7ClUS/t3BEn/InhnfqF2m9AclrLG+ XiMA==
X-Gm-Message-State: AOAM5305ZecviEywJwN9P3n0LhYMoT3b50Q0o3lY7e2pH+KdWRNdZUsB lUZMA8vKb8jHofSWvDbRO7arZhiX7fe/l9lKl/MaFWNZ0cp44A==
X-Google-Smtp-Source: ABdhPJyLeYH3KdDNnh97uWMFjxl2xkdbWnuFrcfbJR3McV5KAfvQaAmGVtpYcTr7UsBD81laTkZkY16n+s1mgGpH+58=
X-Received: by 2002:a92:c644:: with SMTP id 4mr16119524ill.154.1617050004483; Mon, 29 Mar 2021 13:33:24 -0700 (PDT)
MIME-Version: 1.0
From: Stig Venaas <stig@venaas.com>
Date: Mon, 29 Mar 2021 13:33:13 -0700
Message-ID: <CAHANBtJhb=tap7zgWVcXAiujvmDLo5bA67LphrvFG=SHObRRXg@mail.gmail.com>
To: draft-ietf-pim-assert-packing@ietf.org, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Zl4vO4p3ZOL61oKxDBYFHiypKGQ>
Subject: [pim] Some comments on draft-ietf-pim-assert-packing-00
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 20:33:29 -0000

Hi authors

The draft looks pretty good to me. The security considerations need
some more details though.

I want to follow-up on a comment I made at the meeting.

When sending a packed assert one can include multiple records. In
order to pack as many asserts as possible, it is OK to send the
periodic assert winner messages slightly earlier than usual, but they
should not be sent later.

When the assert timer expires, it is important that an assert is sent,
and received by other routers within 3s (default value of
Assert_Override_Interval). It might be OK to delay sending some
asserts a few ms so that they can be packed with asserts shortly
after, but it cannot be delayed for long.

However, there is no harm in sending an assert a few seconds before
the assert timer normally would expire. E.g., if one assert is
supposed to be sent in 50s and another in 52s, it is OK to send them
both in 50s. One should then reset the assert timer for both of them
so they would expire at the same time later. This could be achieved in
a few different ways, but we don't have to go into the implementation

What I'm suggesting is some brief text explaining that one should not
delay sending asserts in order to achieve optimal packing (maybe can
say that a few ms is ok), but there is no harm in sending some asserts
a few seconds earlier to achieve better packing.

Maybe another way of saying this is that asserts happening within a 1s
interval can be packed together. With a lot of asserts happening,
which is the use case for packed asserts, one may get efficient
packing just by considering 1s intervals. But this should ideally be
done sending asserts up to 1s earlier than usual, rather than up to 1s