Re: [pim] AD Review of draft-ietf-pim-drlb-10

Alvaro Retana <> Mon, 09 September 2019 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A91212001A; Mon, 9 Sep 2019 14:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.493
X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G57uA_Bx_Pfh; Mon, 9 Sep 2019 14:27:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6ADA1200C7; Mon, 9 Sep 2019 14:27:50 -0700 (PDT)
Received: by with SMTP id f19so14583650eds.12; Mon, 09 Sep 2019 14:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PmBtRNnu98DeWzaKH5Z1meRjk3roksPR8y12OinM0zs=; b=O0J5niFFVa9Cg/9p6PWlJJALJd6OqtOZa/IZmFAdWEQ0Ll3cM8GDzxLXjXuyGlMFdI 7MBdBik4rTLq8Mh4VqMVRHo7HSsMivXFAp1+Fsx5b90fVyv+CGMNAF7LmcCKJLZUDKMf DoT0U3HEeMKipQc65JAxnpE8l2fIdm84OmkjEFGFjbjoL6BkEb1TUwIp/H7dw8Gt28Vm iCpj2PBF2ZXzUB/I9qQjVPNicO8gtwpHD3X9kLvcPzStkJw5tVhDYgJfmOGGhzz4+dNG /6rVazzVzNzMUf79HfbBLAj814LHz9BnpVLDiryqLqSXVKZ6EX8wfVlsK6bSdlk4w3Vs YmmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PmBtRNnu98DeWzaKH5Z1meRjk3roksPR8y12OinM0zs=; b=U7N26CNQJ4n5s8IwLFNLT2VSlAbe/UU+rn9Qi4LSx+SunORXZJ9nYmVf/DxNZFdbsk +3SXIsZIYefJ1JxTCL1LzumlMQQ9p1FYm7wqItwYTdopC3xZMwMGlTDghMTJiKG2HntW YGrk+VlZdG8AMSDxX9kuuB6KHjFnLbSVeBsnVNteNlRFg1X7vwpcmLZT18OZ/q1LdB+N cHnVI6YbFEo1UEuIZmwhSHH1QrVGCiHBzbLvA/UjPCW4i1Lt/gl2NGTALExwvxbRxtd/ sTbSSLz8ggmZaGLUad8wew4DvWY+FNy2H2rJkdWHVRpNHPa0UH9pTgk5uhU9bBrhbVXH pVNw==
X-Gm-Message-State: APjAAAU6Kql5aS1UcZWh22F15qUN8NR0VjXBWw73tgkLGH3buFIrXbI3 /g1pt4pJeDCCt4gMd6pS8CsM2vxhmLCTVNUD1Lm1qZFl
X-Google-Smtp-Source: APXvYqwp+/e6a9Bj3zVflnEsFpgDxIxDdHOHvflT8GSTWXLuXtK6OegQmwaIwVSyz2SbF/ZRwZLHsuPUaVf2L7f7eG4=
X-Received: by 2002:a17:906:c669:: with SMTP id ew9mr21282618ejb.285.1568064469429; Mon, 09 Sep 2019 14:27:49 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 9 Sep 2019 14:27:48 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Mon, 09 Sep 2019 14:27:48 -0700
Message-ID: <>
To: Stig Venaas <>
Cc:,, Mike McBride <>,
Content-Type: multipart/alternative; boundary="000000000000af71d60592257594"
Archived-At: <>
Subject: Re: [pim] AD Review of draft-ietf-pim-drlb-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Sep 2019 21:27:53 -0000

On August 27, 2019 at 5:54:48 PM, Stig Venaas ( wrote:




> [major] Is there a possibility that the assigned GDR for a specific
multicast state can't fulfill its duties? This document assumes that all
the GDRs are able to service all states...but that may not be true. Because
every GDR candidate calculates who the GDR is for a specific state, it may
never know what an alternate GDR is not able to forward traffic. [Does this
make sense?]

It is assumed that a router is only configured as GDR if it is
expected to have the necessary connectivity etc to fulfill its role.
This is no different than expecting today that any router elected as
the DR has the necessary connectivity. Implementations could
potentially have some ways of automatically decrease the priority in
failure scenarios to avoid being the DR. This is not specific to DRLB


I’m not sure if we want to point this fact out…but because it is not
different than a DR…. I’ll leave it up to you.

> [minor] Can you provide any guidance on how to configure the hash masks?
The example below shows a mask of, which seems both "unnatural"
(for the average person used to set masks) and very specific (in order for
N to have a specific value). Maybe it's just me, but I would have set the
mask to something similar to Guidance should be
added to §8 (Manageability Considerations).

The reason for allowing such masks rather than just prefix lengths is
to allow load-balancing regardless of how service providers utilize
their space. I will try to think of examples. It would allow for
ensuring that certain groups always are hashed to the same router
(that the hash value computed is exactly the same for the groups).
That is, H(G1) == H(G2) if G1 and G2 are the same after the mask is
added. Hence the same router will be selected as the GDR for both G1
and G2.

Allowing that type of mask is ok.  Examples are good.  I would like to see
text about (maybe as part of an example) how some masks will provide better

> [major] What does "provide" mean in this context? I guess that it means
that if no hash mask is configured, then the default should be used. Is
that correct?
> [major] When would an implementation not provide those masks? IOW, why
aren't you using MUST?

Just using default masks would be sufficient for most deployments.

Ok…so s/SHOULD/MUST, right?

s/SHOULD provide masks with default values/MUST provide masks with default


It will take a while for us to revise the document.