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

Brian Haberman <brian@innovationslab.net> Wed, 10 November 2021 19:26 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 9DD873A12D5 for <pim@ietfa.amsl.com>; Wed, 10 Nov 2021 11:26:21 -0800 (PST)
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=unavailable 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 vb07QemdeAAv for <pim@ietfa.amsl.com>; Wed, 10 Nov 2021 11:26:16 -0800 (PST)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 2CE793A12CD for <pim@ietf.org>; Wed, 10 Nov 2021 11:26:16 -0800 (PST)
Received: by mail-qv1-xf29.google.com with SMTP id i13so2568609qvm.1 for <pim@ietf.org>; Wed, 10 Nov 2021 11:26:16 -0800 (PST)
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=eONAbXtCFd2z7rEkt0pAJRVj+l+ebiFcvkmzUtQNxY4=; b=Ka8KvXRCXtDQAzBq7QgJZEGIal/GDsd3xD0odUqQ5bHRYw7FtszGfe1FoZQjcCNTLg u1WL4NUHwu10xC2pFs7mXi54QVLicVc3NbAlD67DhdeET6IuIeF+sKbIfRH4e2pdK++a R5Ig5wAljc495mceoWl1AYTdMcm1DYSPh+CKv6+HYrnXNJE2LaG4tTlArCFz7YNrHOip UJjLKTLadC9cgcNkboqVRZyaF//Khzoj0dgGjkvPessyyPWOhAkxGl6bm04+8NSkZN3i 5ttSlfzoEidIzO2EnFvatu3lD3xT9oNFP2zS4YlRQEMRhOtpIBvdtqdryzquibE6M63w 4PlA==
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=eONAbXtCFd2z7rEkt0pAJRVj+l+ebiFcvkmzUtQNxY4=; b=ts03883f9+qCkMN2p5R5qQb1BuvsWRVAGhqqQztApO5sjUTKplgIcHWQ3UfcvDBW0y T0y5Bdkl5H0OWhMOrHKk/boUeMN9yURLFoU2plehglS7pDVGfiK0inxCWD0TeIyaSJg7 /QdMuDc37MSmvFbHQU4iuKUoUugRLYRdbWuwMR2XSMt2mFzjPSyl4Q0PJrY4oATCCULR BAE5drOFtug5GlSDEynj9apRBKJlVXoQniRhwVrItUvxX0nkdsQ8+wN80EY4vlS2oFGK x03SLQMLEt3Kd8Av7J8Cijkt2xR6vebaXSihfUDDt97huIZ+1nPfuFskilc6qdsR9RoC uExA==
X-Gm-Message-State: AOAM532DPEy+TpKxNHFJCS/8zwjnrPYERYkvfIVeKP6ZrN9EpGPa8KZ1 1dTHeiYa63xEufiBE2S2p7c/Pj5HZDGrsiR+
X-Google-Smtp-Source: ABdhPJxPaW1pMCWAj2xcaH1GwdhBr5NyJWGl7JiKRlIfNbe5JKE9THe5Ir2uDIWHVI8KAB9mque/Pw==
X-Received: by 2002:a05:6214:c6f:: with SMTP id t15mr1034208qvj.49.1636572373787; Wed, 10 Nov 2021 11:26:13 -0800 (PST)
Received: from ?IPV6:2601:5ce:300:84e:58ae:1eda:726c:ed0? ([2601:5ce:300:84e:58ae:1eda:726c:ed0]) by smtp.gmail.com with ESMTPSA id br17sm355415qkb.10.2021.11.10.11.26.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Nov 2021 11:26:13 -0800 (PST)
Message-ID: <d398c83f-45f2-e8cd-90ee-089ef60825ba@innovationslab.net>
Date: Wed, 10 Nov 2021 14:26:09 -0500
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: "Ahmed, Nasir" <nasir.ahmed@commscope.com>, Alvaro Retana <aretana.ietf@gmail.com>, "pim@ietf.org" <pim@ietf.org>
Cc: "draft-ietf-pim-3376bis@ietf.org" <draft-ietf-pim-3376bis@ietf.org>
References: <CAMMESsy51mR5q9pKkV5DiubPX39q1c8sYofEAqkAJqhC2705nA@mail.gmail.com> <2f167b00-955c-b9c3-bf36-c6f68e782f2e@innovationslab.net> <CO6PR14MB424139B5F48E0A9B32CB3E25FF869@CO6PR14MB4241.namprd14.prod.outlook.com> <0af1f916-d2ab-e532-d4c3-b1e3416829b6@innovationslab.net> <PH0PR14MB5258AD10B8A7F49A5188EA63FF929@PH0PR14MB5258.namprd14.prod.outlook.com>
From: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <PH0PR14MB5258AD10B8A7F49A5188EA63FF929@PH0PR14MB5258.namprd14.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------DEofQoHDUgDdujLebxZ3i26x"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/rm8FVdXMZpocqtCSmcndb7QNSwA>
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, 10 Nov 2021 19:26:22 -0000

Hi Nasir,
      I see what you are getting at... There is a corner case where the 
state for a group could disappear for a few seconds before getting 
refreshed/recreated by the next query/response cycle. This isn't a 
catastrophic issue given the soft state nature of multicast, but it does 
appear to be a minor conflict between two timer values.

Regards,
Brian

On 11/8/21 10:28 PM, Ahmed, Nasir wrote:
> Hi Brain,
> 
> This is the case when the current active querier dies off. And all other non-Queriers are waiting for their timer to expire.
> There is no one to send query during this interval.
> 
> -regard's Nasir
> 
> -----Original Message-----
> From: Brian Haberman <brian@innovationslab.net>
> Sent: Tuesday, November 9, 2021 12:20 AM
> To: Ahmed, Nasir <nasir.ahmed@commscope.com>; Alvaro Retana <aretana.ietf@gmail.com>; pim@ietf.org
> Cc: draft-ietf-pim-3376bis@ietf.org
> Subject: Re: IGMP Group Membership Interval (draft-ietf-pim-3376bis) WAS: [Technical Errata Reported] RFC3376 (6725)
> 
> Hi Nasir,
>        What is missing from the scenario below are the queries being sent every [Query Interval] (default of 125 seconds). That will refresh the state for all multicast routers.
> 
> Regards,
> Brian
> 
> On 10/28/21 2:29 AM, Ahmed, Nasir wrote:
>> Hello Alvaro/Brian,
>>
>> Thanks for following this up.
>>
>> Let's assume Router-A sends Query at time 0sec.
>> Host sends report after 2sec (random value from max-response-time).
>> Routers (A,B) starts GMI to be expired at 262sec.
>> Router A (Querier) dies off.
>> Router B resumes sending queries after 255sec.
>> Host responds to the query after 9sec(random value from max-response-time).
>> Which is 255 + 9 = 264sec.
>>
>> Even with the refresh logic, there is a gap of 2sec on the timeline, which results in group aging out.
>> My recommendation is to add extra buffer to GMI to cater to this scenario.
>> Add 10sec to GMI by default - ((the Robustness Variable) * (the Query Interval)) plus (Query Response Interval) + 10sec.
>>
>> Let me know if this make sense or my understanding is wrong.
>>
>> -regard's
>> Nasir
>>
>> -----Original Message-----
>> From: Brian Haberman <brian@innovationslab.net>
>> Sent: Thursday, October 28, 2021 1:33 AM
>> To: Alvaro Retana <aretana.ietf@gmail.com>; pim@ietf.org
>> Cc: Ahmed, Nasir <nasir.ahmed@commscope.com>;
>> draft-ietf-pim-3376bis@ietf.org
>> Subject: Re: IGMP Group Membership Interval (draft-ietf-pim-3376bis)
>> WAS: [Technical Errata Reported] RFC3376 (6725)
>>
>> 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://secure-web.cisco.com/1-W1i5SwgGQM4dcAQZG7tzW3k_EaC_2e4vpCrdZu
>>> m
>>> pEPCo7hgvUCfzwEezjcO-_QnRKLXTonU9iKAioHqK8vKbUxYwXX3auSBCGnOqrJmjg7wF
>>> B
>>> iINIQo6cIkNOHeHUqJYhjIkHrBI2ofMlwdz_ezQKCHnkIMErrYjDEukjkCKeJET8pWgrA
>>> Z
>>> i3rDqZN6U2kFHvWD6lao9U_hOy2Rb3CST8TYgFayOlMQuLSxnB2rJ7v_7ETGMfMyaNKG-
>>> n
>>> -VF47pYWfvG9OEsft87BzdQyazAUXM0ZhYUvVwZy7QP_SrtGlG3Jyu2nmTwV2_jGP7Hf3
>>> C
>>> /https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6725
>>>
>>> --------------------------------------
>>> 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
>>>