Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-drlb-13: (with DISCUSS and COMMENT)

Stig Venaas <stig@venaas.com> Wed, 18 December 2019 18:22 UTC

Return-Path: <stig@venaas.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1D8120AC4 for <pim@ietfa.amsl.com>; Wed, 18 Dec 2019 10:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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=unavailable 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQVGprwb6lr5 for <pim@ietfa.amsl.com>; Wed, 18 Dec 2019 10:22:52 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 81171120241 for <pim@ietf.org>; Wed, 18 Dec 2019 10:22:52 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id r21so2465506edq.0 for <pim@ietf.org>; Wed, 18 Dec 2019 10:22:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pjrLW8y0IPM5eXLP5d+pVH0khojiJBU4IqVXDI3X9Q0=; b=fq+61Mjt4pKuFhX610IOpggGlXBk5c1bEXq0pw4KQUXZPCC5Ez/4wB35UqzxiQEKgW 5qjQVZg/sa/CmqmUo5PhYp/VH6lfxkgI71hElYBuiPylzbsBv3DklL0ycRi8F6t3Cajj LJvSxaMp2GkagwzIyCpbuVhtSgbzYTLlXqdIVcu8LEYS16I1nlkskFvUp7AL45rK29XT bk9i2T4blFXlhlWkdEUvbgJgzIYvLJq1tV792BsjJcewn+ScDqXvWV7ECd1xyL9Pv0wX xtaKD7P2v0I0dEInu22fvmff9c6Pk/1f+x/a94TMPJNt5UFBeLB4LSNhFKW4nTuLAx6c wl4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pjrLW8y0IPM5eXLP5d+pVH0khojiJBU4IqVXDI3X9Q0=; b=Th5yaQ3abco0Iet7yzvCyJWvxXNCvng5N49ORgwaW1OwHYKRDOS845Wd7tOimv2wOO hn0nr5qvAfxtJawqK/lSX8AX1hmOMRQ44lGB/efoD+/wc/+80sG91WnUAG/vPcqlycUu 05rH4Rya0reM6tPxbtjOXQ21Eu5GxCB9Sb2xhfxA6enbUkI89I+Ja7lH0e+UHpkuI3+f Yoe2DND7bxZGlwKHm1TOwbNNL7PdyaAcVNcvFW0wy6gjlg4x5IGSz7Avirw7LLIHdYyA BbnNT13kDEhPb/tpVcQkUtPd2kW7QyycegqeU5qWXAczl/YkWyDhxARfaBvad3+naT5Z avAw==
X-Gm-Message-State: APjAAAVJeuHLHcJ0Z9PUAxrhtz4ozu2xr0oBFeemqShfIbHjYqwRUrbU PXpHivjd0PgF5LnlzoGZx5VJrEukM0hXr91QN5cV8Q==
X-Google-Smtp-Source: APXvYqwFohTDL6Ey+3Rj3oJqqfui9jSQMWZsaI+FeYchyaZQLd/ZKCdXA/RNmOsTTwUTQBpWT2XVqF4TAZojZ0OXZmg=
X-Received: by 2002:a17:906:9615:: with SMTP id s21mr4332662ejx.20.1576693370918; Wed, 18 Dec 2019 10:22:50 -0800 (PST)
MIME-Version: 1.0
References: <157540986540.4772.3616840765001072305.idtracker@ietfa.amsl.com> <CAHANBtLM=U4_hFvkmkuJPQc52SXshKibPbxpcU2HWNcYEs3WWg@mail.gmail.com> <20191217003307.GV81833@kduck.mit.edu>
In-Reply-To: <20191217003307.GV81833@kduck.mit.edu>
From: Stig Venaas <stig@venaas.com>
Date: Wed, 18 Dec 2019 10:22:39 -0800
Message-ID: <CAHANBtJF-JY84iPm8ELk2qEdTJSnrDLYxyXLWfHeH56AkJq6AA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pim-drlb@ietf.org, Mike McBride <mmcbride7@gmail.com>, pim-chairs@ietf.org, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Rs8rt2O0nZIbZ4Uxl3uL0uo9v7I>
Subject: Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-drlb-13: (with DISCUSS and COMMENT)
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: Wed, 18 Dec 2019 18:22:55 -0000

Hi

Following-up on your discuss. Please see in-line. I've trimmed it down to
what I understand is the remaining issue.

On Mon, Dec 16, 2019 at 4:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
[...]
> I do still worry some about the IPv6 limitation, though, but let me check
> my understanding a bit.  It seems that we only take the low-order 32 bits
> of the shifted+masked value out of implementation convenience, since 32-bit
> integers are fast and (modular) division slow.  I'm not missing some more
> fundamental reason why the 32 bits are chosen for the modulo hash
> algorithm, am I?  (I mean, yes, IPv4 addresses will only populate 32 bits
> of any field, but I am not sure why that length would have to be extended
> to IPv6 processing, when zero-padding would produce a well-defined result.)

One significant reason for 32 bits, is that it is easy to compute modulo on any
platform where this is likely to be implemented. The other perhaps not so
good reason for 32 bit in particular is that it is easy to use the
same algorithm
as was used on IPv4 addresses once it is 32 bits. We also thought 32-bits
were sufficient. See more details on that further down.

We could have folded the IPv6 address into 32 bits in such a way that the full
address was being used, but we also wanted something where it is easy for
an operator to predict the hashing.

> If it is just a relatively arbitrary choice of number of bits to take,
> given that it in theory could have a detrimental effect on the mechanism
> when used with IPv6, it would seem to potentially qualify as a "known
> technical omission" in the language of RFC 2026, which is something that we
> are not supposed to have in Proposed Standards.  Even if the IESG did
> decide to waive the requirement, I think it would still be incubent upon us
> to properly document the at-risk scenarios.

Let me comment further on while I don't see the 32 bits as a significant
limitation. I want to add though, that the modulo algorithm has shortcomings
in general, which is why we wanted to allow further hash algorithms to be
defined in the future if needed. Among other things, such algorithms would
not need to have the 32 bit limitation.

When people choose IPv6 multicast-group addresses, they tend to choose
them so the least significant bits vary. RFC 3307 has the concept of a 32-bit
group-ID that is used by IANA assignments, and should be used for dynamic
assignments. One reason is that these 32 bits will also be used for link-layer
multicast as mentioned in 3307.

Also when people allocate their own group addresses, from what I've seen,
they typically use consecutive addresses, or least addresses where the less
significant bits are not all the same. One way many choose IPv6 addresses
that do not conflict with others, is unicast prefix-based addresses, RFC 3306,
here a 32-bit group-ID is also used.

For SSM, source address is considered in addition to the group address. In
the special case where many sources are sending to the same group, and
few group addresses are used overall, it is important how the source
address is hashed. Also here I would argue that people generally do manual
assignments (or DHCP) where the least significant bits vary. Also if using
SLAAC and EUI-64.

There are some special cases where people might have say the same
unicast and multicast assignment schemes in multiple sites, and perhaps
the multicast sources from different sites are identical except for some
high-order bit in the addresses (e.g. with 3306 addressing, and for unicast
addresses, unicast bits 32-47 might vary between sites, and multicast bits
64-79). For that, using hash masks that use those 32 bits would suffice.

If you in the same deployment have a significant number of flows that only
vary in the lower bits, and also a significant number of flows that only vary
in the higher bits (basically a combination of what I wrote first, and what
I wrote in the above paragraph), then there is a problem. This seems fairly
contrived to me though.

I hope this helps. Do you still think this limitation is strong enough to be a
technical omission? If you like I can add some text in section 5.2.2
pointing out this limitation.

Regards,
Stig