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

[Hitoshi Asaeda <[e-mail]>]

Hi,

I may not understand correctly, but my question is that longer GMI doesn't cause longer leave latency when a leave report is missed?

> On Jan 31, 2022, at 11:03, Stig Venaas <[e-mail]> wrote:
> 
> Hi all, anyone else in the WG having any thoughts on this?
> 
> Thanks,
> Stig
> 
> On Fri, Jan 28, 2022 at 8:24 AM Brian Haberman <[e-mail]> wrote:
>> 
>> Hey Stig,
>> 
>> On 1/5/22 2:17 PM, Stig Venaas wrote:
>>> Hi everyone
>>> 
>>> It would be great to get more input from the WG. Here are my personal thoughts.
>>> 
>> 
>> As the editor of 3376bis, I would have liked to have gotten more input
>> on this...
>> 
>>> 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.
>>> 
>> 
>> I don't see a major downside to the longer timer either. From a process
>> perspective, a change made to this value in 3376bis would not preclude
>> us from moving IGMPv3 to full standard as it would be resolving an erratum.
>> 
>>> 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.
>>> 
>> 
>> Can't say I have seen or heard of operational issues related to this timer.
>> 
>> Brian
>> 
>>> Regards,
>>> Stig
>>> 
>>> On Wed, Dec 15, 2021 at 1:15 PM Brian Haberman <[e-mail]> 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 <[e-mail]>
>>>>> Sent: Thursday, November 11, 2021 12:56 AM
>>>>> To: Ahmed, Nasir <[e-mail]>; Alvaro Retana <[e-mail]>; [e-mail]
>>>>> Cc: [e-mail]
>>>>> 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 <[e-mail]>
>>>>>> Sent: Tuesday, November 9, 2021 12:20 AM
>>>>>> To: Ahmed, Nasir <[e-mail]>; Alvaro Retana
>>>>>> <[e-mail]>; [e-mail]
>>>>>> Cc: [e-mail]
>>>>>> 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 <[e-mail]>
>>>>>>> Sent: Thursday, October 28, 2021 1:33 AM
>>>>>>> To: Alvaro Retana <[e-mail]>; [e-mail]
>>>>>>> Cc: Ahmed, Nasir <[e-mail]>;
>>>>>>> [e-mail]
>>>>>>> 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 (
>>>>>>>> [e-mail]) 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 <[e-mail]>
>>>>>>>> 
>>>>>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pim
> 
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim