Re: [pim] IGMP Group Membership Interval (draft-ietf-pim-3376bis) WAS: [Technical Errata Reported] RFC3376 (6725)
Stig Venaas <stig@venaas.com> Wed, 05 January 2022 19:17 UTC
Return-Path: <stig@venaas.com>
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 266083A0D10 for <pim@ietfa.amsl.com>; Wed, 5 Jan 2022 11:17:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=venaas-com.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 FQu4JyUFmMjU for <pim@ietfa.amsl.com>; Wed, 5 Jan 2022 11:17:52 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 8CFD93A0D23 for <pim@ietf.org>; Wed, 5 Jan 2022 11:17:52 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id e128so351092iof.1 for <pim@ietf.org>; Wed, 05 Jan 2022 11:17:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1xLSkc7GmCXmQzSB8NpTfnVGxgIIX/GrTaN/PdS3nKs=; b=SBm+fjm3iMjSfWgPkBCn2VDI3Uie2P7kfYXuogf+LIMYahldB1cZtj91sI9/oeTBR9 IQASESWpy8Fh4DV4flA4F1dt6U/dwyPlxUIElMQ8N4aLWoN1mpWj3x99Mc7Ax0WIEsFm pl+3zdv7cCsGGKl0d39w9l3R/VjxOXftTsRl5nOhJyOwDIE+pN7Rd8uu/ROhl/GSKjoG nTBUTb4f5be3vPjao8ENcRHxuXEywyNQNoFjkPXIjfzUp/Do9RC8qIJB1sPmapfxqS8S yovEI+iCwJ5HZmrhMTamWe26ivr5iahEfPbdJQeObhqD5LTngmEtMRsrqe8ShB4hg9IW ETzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1xLSkc7GmCXmQzSB8NpTfnVGxgIIX/GrTaN/PdS3nKs=; b=ey0A/lgisJN0y8TuTXpKUEOK9bcME/Av1Nff/LFG9bFCBDHmv1jVN7MI+XMTt+y3Gm 9nG97yzIksGT4bu81+Gp08cLbj/ZBcLlkulYvFxGgkam67mNoumUt6FO8hoHg6tCp9R0 A76nYKAL5y8NQGuaZIMU7S6WpmxWo9eKTerfjqr7JmkkQ4ymjqYJcpumza8hMIAgVujA 0m+eO57bxmE5IBAOq5qwpTXfnsYRgPzBRVmDMt63blCUe/reD/eL44IPinwJeC6GVYEp qMtN0XZCBaXdxNLmAUr0AF9mBt3c/J43mrjn5qJUQjrw0vQlQxS5lOTLcZPqSXoZu52F rgGQ==
X-Gm-Message-State: AOAM532oXMLcBKtmHbdXqsfkzrzQmuhPUiCa69XIPHzVCzUEDKWSRT6o EZr+i6w1hkBxlb+zmzOONvAGmm4utS80k108M21/cGbTCkY=
X-Google-Smtp-Source: ABdhPJw/kiPjS/CKgk+DPcVYrkcSoVSUtiv6ZaIPKGtc+NTw03re1U1UB4qbv9oJSCPOcQu+djyAapxwjIJawomUJXU=
X-Received: by 2002:a02:c6c6:: with SMTP id r6mr25746318jan.235.1641410270850; Wed, 05 Jan 2022 11:17:50 -0800 (PST)
MIME-Version: 1.0
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> <d398c83f-45f2-e8cd-90ee-089ef60825ba@innovationslab.net> <PH0PR14MB5258AC1F34670AA5085D7CACFF759@PH0PR14MB5258.namprd14.prod.outlook.com> <d5436dae-7441-2801-17c1-820faebe3ca0@innovationslab.net>
In-Reply-To: <d5436dae-7441-2801-17c1-820faebe3ca0@innovationslab.net>
From: Stig Venaas <stig@venaas.com>
Date: Wed, 05 Jan 2022 11:17:36 -0800
Message-ID: <CAHANBtLB-BS-f-xm5gROy--CLt06=JYizD3_Oh7uxsLHgq=XUA@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: "Ahmed, Nasir" <nasir.ahmed@commscope.com>, Alvaro Retana <aretana.ietf@gmail.com>, "pim@ietf.org" <pim@ietf.org>, "draft-ietf-pim-3376bis@ietf.org" <draft-ietf-pim-3376bis@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/WVkflQEaMW5HeG99PydyIRJb_Iw>
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, 05 Jan 2022 19:17:58 -0000
Hi everyone It would be great to get more input from the WG. Here are my personal thoughts. I agree it would be a good idea if implementations use a longer time here. I don't see any downside to increasing it, except some marginal cases where unnecessary forwarding may go on for a few more seconds. If we update this, I would prefer to change the text so that the GMI MUST be at least as large as it is now, but that it is RECOMMENDED to use this larger value. At least I don't think we should make a change requiring the new value, making all existing implementations non-compliant. Is anyone aware of operational issues related to this? It is clear to me that this can happen, but I cannot recall explicitly having observed it. It is possible that some implementations have tweaks to handle this better, does anyone know? E.g., a new querier could initially use a smaller MRT. Regards, Stig On Wed, Dec 15, 2021 at 1:15 PM Brian Haberman <brian@innovationslab.net> wrote: > > Hi Nasir, > The WG and its leadership need to determine if this issue raises > to the level of a technical erratum. If so, the erratum should be marked > as either Verified or Hold for Document Update. With either of those > states, a change can be incorporated into the -bis documents. If the WG > decides it is happy with the values as is, the erratum should be marked > as Rejected. > > The marking is done by the AD overseeing the PIM WG. > > Regards, > Brian > > On 12/14/21 1:02 AM, Ahmed, Nasir wrote: > > Hi Brain and others, > > > > Please let me know what is the next step for this Errata. > > We can recommend adding 10sec to GMI by default - ((the Robustness Variable) * (the Query Interval)) plus (Query Response Interval) + 10sec. > > > > -regard's Nasir > > > > -----Original Message----- > > From: Brian Haberman <brian@innovationslab.net> > > Sent: Thursday, November 11, 2021 12:56 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, > > 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_2e4vpCrdZ > >>>> u > >>>> m > >>>> pEPCo7hgvUCfzwEezjcO-_QnRKLXTonU9iKAioHqK8vKbUxYwXX3auSBCGnOqrJmjg7w > >>>> F > >>>> B > >>>> iINIQo6cIkNOHeHUqJYhjIkHrBI2ofMlwdz_ezQKCHnkIMErrYjDEukjkCKeJET8pWgr > >>>> A > >>>> Z > >>>> i3rDqZN6U2kFHvWD6lao9U_hOy2Rb3CST8TYgFayOlMQuLSxnB2rJ7v_7ETGMfMyaNKG > >>>> - > >>>> n > >>>> -VF47pYWfvG9OEsft87BzdQyazAUXM0ZhYUvVwZy7QP_SrtGlG3Jyu2nmTwV2_jGP7Hf > >>>> 3 > >>>> 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 > >>>> > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim
- [pim] IGMP Group Membership Interval (draft-ietf-… Alvaro Retana
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Stig Venaas
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Stig Venaas
- Re: [pim] IGMP Group Membership Interval (draft-i… Hitoshi Asaeda
- Re: [pim] IGMP Group Membership Interval (draft-i… Alvaro Retana
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Brian Haberman
- Re: [pim] IGMP Group Membership Interval (draft-i… Hitoshi Asaeda