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

Brian Haberman <brian@innovationslab.net> Mon, 08 November 2021 18:50 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 421903A0101 for <pim@ietfa.amsl.com>; Mon, 8 Nov 2021 10:50:29 -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 6yXgtrXjuzbe for <pim@ietfa.amsl.com>; Mon, 8 Nov 2021 10:50:23 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 717263A07A1 for <pim@ietf.org>; Mon, 8 Nov 2021 10:50:21 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id c12so10011674qtd.5 for <pim@ietf.org>; Mon, 08 Nov 2021 10:50:21 -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:subject:content-language:to :cc:references:from:in-reply-to; bh=hxRC/TZpmT65vZNXHWkDGwEXvr531b3J6QkoMRGYgwY=; b=kG/B4KGtx7t16UIS5yS/7APppnrp9FiBtXeh+8pg3C4UrD0kW6geFr1yzhMMob5Xny RzI5slxBnL4wpPXUEx1sntTLaI9aIg2PJ62pJfcJx5+Cukgy0uqfk5jgq6nGvnHwRgCW 8U4BTB/NGfjnClwqQnZolKCzjRzbZEoLzhqCU3fW9GoeSCEUpruwwWdmDMyMD/l1dmy2 Z5OBOSGydhLBzkVPRRv832JI4xPIRkQ88WdS0oZJGPC0XrCAMuNZACPqqc86mWEAHqeq OIScuA3lBeJKVgegkAPOyWoiDLKSdTMVItWBVWkZ611gdTIEXoQ3tEWMYVjV/NqkRlyo aq8A==
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:subject :content-language:to:cc:references:from:in-reply-to; bh=hxRC/TZpmT65vZNXHWkDGwEXvr531b3J6QkoMRGYgwY=; b=MgOcodtA96o5J3yesRg7Jeg316kOyt4ODvqSpuBANvd1Y8y+LDFu0tUZXXFDTphS9Y QDn3jgNxIPKPM+SchYTDOeQu1Crc3GjrN3gqhMxmVTuEeF+LacceJefnKMwBniIpQSvh SR++7KeNhLAP1Rz2+1srYfeghYHJyOcYUeN/1rEQeXKzuonbgAC68v2k7Laxr4JoEEPc EMiKUQI68rKVIPpCOD5a2HTzmi2qrChqXM5gTyKSYQjSA1iyKAYrisxEQUgoyRW1IdgL vyvx7fPnQStTiWBA9OZZav5zmvu98Ko3lWHXM1ZWtPbHgFonWKWJkz35WlQGA0lFekKE 3R9Q==
X-Gm-Message-State: AOAM533RaZlyr1WMxxHTLcD0ykrl3qVfQXiyb7B1zWFB7FZGRoE0zYxT E9f0VyM5JQrNoN7luT+gyel/xw==
X-Google-Smtp-Source: ABdhPJzVy4PyohX5h4ILlaS/kKSw732iREZJf3tg7VIH+pY/+wm7jzVlOZ7aCHhV1HHCf0eCj4EC6g==
X-Received: by 2002:a05:622a:11d6:: with SMTP id n22mr1799497qtk.337.1636397419286; Mon, 08 Nov 2021 10:50:19 -0800 (PST)
Received: from ?IPV6:2601:5ce:300:84e:8168:3cf1:b11a:9e92? ([2601:5ce:300:84e:8168:3cf1:b11a:9e92]) by smtp.gmail.com with ESMTPSA id j13sm10697091qkp.111.2021.11.08.10.50.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 10:50:18 -0800 (PST)
Message-ID: <0af1f916-d2ab-e532-d4c3-b1e3416829b6@innovationslab.net>
Date: Mon, 08 Nov 2021 13:50:17 -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>
From: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <CO6PR14MB424139B5F48E0A9B32CB3E25FF869@CO6PR14MB4241.namprd14.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------yRoPyAsN8FITwHSSiiFhwZMz"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/SyrExOiy0C-jNuOxUCjsxb9cx8U>
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: Mon, 08 Nov 2021 18:50:31 -0000

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_2e4vpCrdZum
>> pEPCo7hgvUCfzwEezjcO-_QnRKLXTonU9iKAioHqK8vKbUxYwXX3auSBCGnOqrJmjg7wFB
>> iINIQo6cIkNOHeHUqJYhjIkHrBI2ofMlwdz_ezQKCHnkIMErrYjDEukjkCKeJET8pWgrAZ
>> i3rDqZN6U2kFHvWD6lao9U_hOy2Rb3CST8TYgFayOlMQuLSxnB2rJ7v_7ETGMfMyaNKG-n
>> -VF47pYWfvG9OEsft87BzdQyazAUXM0ZhYUvVwZy7QP_SrtGlG3Jyu2nmTwV2_jGP7Hf3C
>> /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
>>