Re: [pim] IGMP Group Membership Interval (draft-ietf-pim-3376bis) WAS: [Technical Errata Reported] RFC3376 (6725)

Brian Haberman <brian@innovationslab.net> Wed, 27 October 2021 20:03 UTC

Return-Path: <brian@innovationslab.net>
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 6E50C3A116A for <pim@ietfa.amsl.com>; Wed, 27 Oct 2021 13:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.227
X-Spam-Level:
X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=innovationslab-net.20210112.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 zv0n6Y04ffvo for <pim@ietfa.amsl.com>; Wed, 27 Oct 2021 13:03:21 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 83E053A1165 for <pim@ietf.org>; Wed, 27 Oct 2021 13:03:21 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id x123so3635014qke.7 for <pim@ietf.org>; Wed, 27 Oct 2021 13:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=innovationslab-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to; bh=UheT3LDfld5Xwr6bUu3wUFmB2Jue7SIamQygQ7WKvYA=; b=TYw0TJQC86yXNUs0UApv+oZQJiZ13ugqBOp6/Z/O6EeeT0rLAbzmFjjcInLcdoEOpY MJY8Ymbx52Z8hhwSQAj99mDroSgk3K7XY9XxLRFIvOI6F4LwT0MWKK4OL9htbgHVrC5P h+UU+rAVn3dTP43m5t6syEnkJLtNAa2TJdXMBgAbZ/AzH7DFSv5L54Ca05gXBfkKd8aU 50uCVmifTpYoF9Bm5uHpylJAyFH30mt4jKDN5CJf/DLMgDY6ShERG5eQRvxBAJShuHK2 GZHD/r/lsIszGhEvr2ysFN2tgyPRfqow6+bNSaYFRIj6H/1khNQQvdUQ3HeMQMMBgJPI dbuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to; bh=UheT3LDfld5Xwr6bUu3wUFmB2Jue7SIamQygQ7WKvYA=; b=SuaLxtLpTacvf+flvQc575rClgwUjm8ns/lAQJf/vi7EZ3qlmx+o5ujRJ0vyrIXvlf VB5E7tyg17clZE/1cQBFsw5ls4qYrmSPbZa13YTWdYpZ/gG9iTfIc0JMyEs0AN3fKNc0 oqAOCOoI55DdKrBW8rGTFHRfn3mVBa1BpQFfEmoACA4UJTt6KMYIZHz0BDCTMK98Ha+y 3aWblOqelqxYgZn9nwO71tOFF+Qb2AZNGD3uYcT7bNQ0zi1NbcOb/XV6CDJe65rltqLd zHLxmggcd2FLivNU4O2i7XxfkC/UVEl/s4YqEls/nzsu07tayKtBkRb4SL9YQehOagqe DP6A==
X-Gm-Message-State: AOAM533Vhs+KHB3pIaut2lvzK9QlAa/FAMY/IOwkmBBhZfBeO1OskhiW jgU61SICoLHF8cQ56nApLGCz6w==
X-Google-Smtp-Source: ABdhPJzO08xItdDKc+GnVzyYl9gP5ty3jow3X5AGtRV1yHly5aIZwcZyd6h1I8u8WW+q3KaCC3xmBw==
X-Received: by 2002:a05:620a:1707:: with SMTP id az7mr26273685qkb.276.1635364999136; Wed, 27 Oct 2021 13:03:19 -0700 (PDT)
Received: from ?IPV6:2601:5ce:300:84e:d1b5:d957:db73:62e0? ([2601:5ce:300:84e:d1b5:d957:db73:62e0]) by smtp.gmail.com with ESMTPSA id 10sm638853qkv.37.2021.10.27.13.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Oct 2021 13:03:18 -0700 (PDT)
Message-ID: <2f167b00-955c-b9c3-bf36-c6f68e782f2e@innovationslab.net>
Date: Wed, 27 Oct 2021 16:03:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Content-Language: en-US
To: Alvaro Retana <aretana.ietf@gmail.com>, pim@ietf.org
Cc: nasir.ahmed@commscope.com, draft-ietf-pim-3376bis@ietf.org
References: <CAMMESsy51mR5q9pKkV5DiubPX39q1c8sYofEAqkAJqhC2705nA@mail.gmail.com>
From: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <CAMMESsy51mR5q9pKkV5DiubPX39q1c8sYofEAqkAJqhC2705nA@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------lY0DXVtR6YKLacSoByBSunut"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/irGQQIfp2KxGIXfs3xmwbL8rBTI>
Subject: Re: [pim] IGMP Group Membership Interval (draft-ietf-pim-3376bis) WAS: [Technical Errata Reported] RFC3376 (6725)
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, 27 Oct 2021 20:03:26 -0000

Hey Alvaro,
      I don't think I understand the rationale described in the erratum. 
All multicast routers that receive a Report for a multicast group will 
set the timer for that group to GMI. It will clear any state for the 
target multicast group if it doesn't get updated info before the timer 
expires. In the scenario described in the report, the router that 
resumes sending queries after the Other Querier Present timer expires 
will send a General Query, which should result in a host that has joined 
the target multicast group sending another Report and that will refresh 
the state for the group (i.e., reset the timer to GMI).

Regards,
Brian

On 10/27/21 12:54 PM, Alvaro Retana wrote:
> [Trying again — with the correct pim address. ]
> 
> Dear pim WG:
> 
> Hi!
> 
> Given the work on rfc3376bis, I want to bring the WGs attention to this new
> report.
> 
> I am looking forward to any comments.
> 
> Thanks!
> 
> Alvaro.
> 
> On October 27, 2021 at 1:06:41 AM, RFC Errata System (
> rfc-editor@rfc-editor.org) wrote:
> 
> The following errata report has been submitted for RFC3376,
> "Internet Group Management Protocol, Version 3".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6725
> 
> --------------------------------------
> Type: Technical
> Reported by: Nasir Ahmed <nasir.ahmed@commscope.com>
> 
> Section: 8.4
> 
> Original Text
> -------------
> 8.4. Group Membership Interval
> 
> The Group Membership Interval is the amount of time that must pass
> before a multicast router decides there are no more members of a
> group or a particular source on a network.
> 
> This value MUST be ((the Robustness Variable) times (the Query
> Interval)) plus (one Query Response Interval).
> 
> 
> 
> Corrected Text
> --------------
> 8.4. Group Membership Interval
> 
> The Group Membership Interval is the amount of time that must pass
> before a multicast router decides there are no more members of a
> group or a particular source on a network.
> 
> This value MUST be ((the Robustness Variable) times (the Query
> Interval)) plus (2 * Query Response Interval).
> 
> Notes
> -----
> A router resuming querier role (when current querier dies off) waits for
> other querier timer value to be expired. This value is ((the Robustness
> Variable) times (the Query Interval)) plus (one half of one Query Response
> Interval). This value by default comes as (2 * 125 + 10/2) = 255. Whereas
> GMI comes as (2 * 125 + 10) = 260. A group learnt with this value will have
> its group timer value set to expire from anywhere from 260 + 10 (min 260,
> max 270 due to random response from host in the interval of max response
> time delay after a query). Now a new router resuming a querier role will
> generate query after 255 sec. At this point of time the group timer left
> will be in the range of (260 - 255) 5sec to (270 - 255 ) 15sec. Since the
> query response can come anywhere between 10sec, Groups whose timer value is
> less will expire and will result in traffic drop. Therefore it is
> recommended to increase the default GMI value by one extra Query Response
> Interval. That is - ((the Robustness Variable
> ) times (the Query
> Interval)) plus (2 * Query Response Interval).
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC3376 (draft-ietf-idmr-igmp-v3-11)
> --------------------------------------
> Title : Internet Group Management Protocol, Version 3
> Publication Date : October 2002
> Author(s) : B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan
> Category : PROPOSED STANDARD
> Source : Inter-Domain Multicast Routing
> Area : Routing
> Stream : IETF
> Verifying Party : IESG
>