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

[Benjamin Kaduk <[e-mail]>]

On Fri, Jan 03, 2020 at 02:15:24PM -0800, Stig Venaas wrote:
> Hi
> 
> Thanks for good input and clearing the discuss. I also posted version 15 to
> address your comments. Please see my comments inline.

also inline

> On Fri, Jan 3, 2020 at 10:22 AM Benjamin Kaduk <[e-mail]> wrote:
> >
> > On Wed, Dec 18, 2019 at 10:22:39AM -0800, Stig Venaas wrote:
> > > Hi
> > >
> > > Following-up on your discuss. Please see in-line. I've trimmed it down to
> > > what I understand is the remaining issue.
> >
> > Thanks!
> >
> > There's one point not in the quoted text that I'd like to dig into a little
> > more (as well as some more comments inline/at the end).
> >
> > Specifically, now that the -14 has clarified that the mask bits do not need
> > to be contiguous, I wanted to double-check the procedure that is to be
> > applied, with respect to whether the "footprint" of the mask is (in
> > practice) limited to 32-bits wide or whether the mask is effectively
> > limited to 32 bits set total.  As a concrete example, consider the mask of
> > ::f0f0:f0f0:f0f0:f0f0.  The LSZC of the mask is 4, so if I apply the
> > procedure to a group address ending in :3333:3333:3333:3333, do I mask to
> > get :3030:3030:3030:3030, shift to ...303030303030303, then mask with
> > 0xffffffff to get 0x03030303 as input to the modulo operation?
> > Or do I *only* consider the bits set in the mask, so I mask to ...33333333,
> > mask again with 0xffffffff and use 0x33333333 as input to the modulo
> > operation?  My view is that the text is clearly saying the former, but some
> > comments in our other discussions suggested that perhaps the latter was a
> > possibility.  Can you please confirm which behavior is intended?
> 
> It is the former, 0x03030303 is the input in your example. So you pick at most
> 32 consecutive bits that will form the footprint.

Thank you; it gives me peace of mind to have it explicitly confirmed.

> > > On Mon, Dec 16, 2019 at 4:33 PM Benjamin Kaduk <[e-mail]> wrote:
[...]
> >
> > > 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.
> >
> > I've cleared my Discuss position in the datatracker, but I would be more
> > comfortable if you do add a sentence in Section 5.2.2 noting that there is
> > this (probably hypothetical) limitation, and the workaround of defining a
> > new hash algorithm.
> >
> 
> I added this paragraph to 5.2.2. I hope that addresses this. I agree it is
> good to point this out. I couldn't find a crystal clear way to state it, but
> I hope it is sufficient as it is not normative nor affecting implementations.
> 
>    The Modulo Hash Algorithm will use at most 32 consecutive bits of the
>    input addresses for its computation.  Exactly which bits are used of
>    the source, group or RP addresses, depend on the respective masks.
>    This limitation may be an issue for IPv6 deployments, since not all
>    bits of the IPv6 addresses are considered.  If this causes
>    operational issues, a new hash algorithm would need to be defined.

I think it looks good (and being nonnormative is correct).

Thanks!

-Ben