RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (2)

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 1501
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dave Thaler
Date Reported: 2008-09-08
Verifier Name: Adrian Farrel
Date Verified: 2013-05-11

The header says:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

It should say:

Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Updates: 2236                                                 S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002

Notes:

RFC 3376 does not completely replace RFC 2236, so it should say "updates" instead of "obsoletes". Specifically, to have a compliant implementation of RFC 3376 section 4, one MUST understand and implement the "Version 2 Membership Report" and "Version 2 Leave Group" messages. This is why RFC 2236 is listed as a normative reference of RFC 3376.

Errata ID: 7339
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alvaro Retana
Date Reported: 2023-02-07
Verifier Name: John Scudder
Date Verified: 2023-02-08

Section Abstract says:

This document obsoletes RFC 2236.

It should say:

This document updates RFC 2236.

Notes:

Report EID 1501 has been Verified to update the information in the document's header: from Obsoletes to Updates.

This sentence in the abstract should be corrected for the same reason.

Status: Held for Document Update (3)

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 4375
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Yechiel Rosengarten
Date Reported: 2015-05-26
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16

Section 8.13 says:

8.12. Older Version Querier Present Timeout

   The Older Version Querier Interval is the time-out for transitioning
   a host back to IGMPv3 mode once an older version query is heard.
   When an older version query is received, hosts set their Older
   Version Querier Present Timer to Older Version Querier Interval.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval in the last Query received)) plus (one Query Response
   Interval).

It should say:

8.12. Older Version Querier Present Timeout

   The Older Version Querier Interval is the time-out for transitioning
   a host back to IGMPv3 mode once an older version query is heard.
   When an older version query is received, hosts set their Older
   Version Querier Present Timer to Older Version Querier Interval.

   This value MUST be ((the Robustness Variable) times (the Query
   Interval )) plus (one Query Response Interval in the last Query 
   received).

Notes:

The last query received is older version query.
As such - it does not include query interval.
It looks like it should be operator responsibility to configure identical robustness variable and query interval values network-wide for supporting older versions.

=== Alvaro Retana ===

The pim WG was consulted on the proposed text of this errata, but no clear direction was determined. In fact, no significant discussion took place.

Given that this issue doesn't seem to be causing a problem that the WG wants to address wight away, I'm disposing of this errata as "Held for Document Update". If this RFC is updated the WG must then address the issue.

https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o

Errata ID: 6725
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Nasir Ahmed
Date Reported: 2021-10-27
Held for Document Update by: Alvaro Retana
Date Held: 2022-01-31

Section 8.4 says:

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).


It should say:

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).

====
AD Notes:

I am changing the status of this report to Held for Document Update. The WG is discussing what the best way to address it is: https://mailarchive.ietf.org/arch/msg/pim/Im8go1fjyVad7jyhGg1bgnW93qM/

Errata ID: 5562
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Wim De Smet
Date Reported: 2018-11-26
Held for Document Update by: Alvaro Retana
Date Held: 2019-02-08

Section 6.2.1 says:

   When a router filter-mode for a group is EXCLUDE, the source record
   list contains two types of sources.  The first type is the set which
   represents conflicts in the desired reception state; this set must be
   forwarded by some router on the network.  The second type is the set
   of sources which hosts have requested to not be forwarded.  Appendix
   A describes the reasons for keeping this second set when in EXCLUDE
   mode.

It should say:

[see note]

Notes:

Appendix A.3 contains the following:
One of the ways to accomplish this is for routers to keep track of
all sources desired by hosts that are in INCLUDE mode even though the
router itself is in EXCLUDE mode.

Appendix A.3 makes clear that in EXCLUDE mode we need to keep track of the set of hosts that *are* desired (i.e. set A in section 6.4 or the "first type" in this paragraph). The second set (set B in section 6.4) is the set that will be reported to upstream routers, it is not the set which is needed for smooth switching to INCLUDE mode (the behavior described in appendix A). I believe that the intended description may have been "Appendix A describes the reasons for keeping two different sets when in EXCLUDE mode". At the very least, it appears to be set A (the "first set") which is intended in appendix A.

Status: Rejected (3)

RFC 3376, "Internet Group Management Protocol, Version 3", October 2002

Note: This RFC has been updated by RFC 4604

Source of RFC: idmr (rtg)

Errata ID: 770
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Rajesh Garg
Date Reported: 2006-03-21
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24

Section 5.2 says:

If new query is Group and Source Specific query and there is pending 
response for this group and recorded source list for the group is empty 
(i.e. previous query was Group Specific query)

It should say:

[see note]

Notes:

In section 5.2 of RFC 3376, 5 sequential steps are given to handle the
received query from the multicast router.
I feel the following case is not handled properly in these steps (see above)

In this case, source list will be cleared as per step 4 of section 5.2.
But I feel the source list should be recorded to generate the report
accordingly.

from pending
--VERIFIER NOTES--
The RFC is correct in saying that recorded source-list should be cleared if the newly received query is group-specific query.

Errata ID: 7575
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Aymen Lahouel
Date Reported: 2023-07-26
Rejected by: John Scudder
Date Rejected: 2024-02-14

Section 5.1 says:

If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change
have been completed, each such additional change triggers the
immediate transmission of a new State-Change Report.

It should say:

If more changes to the same interface state entry occur before all
the retransmissions of the State-Change Report for the first change
have been completed, each such additional change triggers the
immediate transmission of a new State-Change Report only if the 
new change is of the same type as the current change.

Notes:

Section 5.1 says: "If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State-Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent.".

It is clearly stated that if a source-list changes occur before all the retransmissions of the State-Change Report for the filter-mode change have been completed, The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. Therefore, in this case it must not immediately send a new State-Change Report.
--VERIFIER NOTES--
RFC 3376 author Bill Fenner said (private email, Feb 9 2024, shared with permission):

Hi Aymen,

Thanks for your interest in IGMPv3. I don't think your proposed change is correct, because one of the fundamental goals of IGMP is to communicate about changes immediately, so a change to say that you don't notify about a change immediately is against that goal.

One thing that makes IGMPv3 a little hard to understand is the complete separation between the interface (see section 2 - the IPMulticastListen() primitives) and the protocol. When nothing complicated is happening, a call to IPMulticastListen() will be tightly tied with a similar message, which makes it even harder to understand the behavior when something complicated happens.

Let's start with the API calls that invoke a set of messages: I think a sequence that is covered by the paragraph in question is:

1. at time T: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A } );
2. at time T1, where T1-T is less than the robustness interval: IPMulticastListen( socket, interface, multicast-address, INCLUDE, { A, B } )
(Alternatively, this could be a different socket, IPMulticastListen( socket2, interface, multicast-address, INCLUDE, { B } ) since the socket interface has to create a union of all includes to communicate to the router)

I think this is the case that you propose not to send - the first one is a filter mode change, and the second one is a source list change, and those changes are of different types.

However, the intent of section 5.1 is that you *do* send a message at time T1; it's just still TO_IN because you're not done with the robustness count of sending the filter mode change.

A high level view of the processing, assuming a robustness variable of 3, is:
Time T: 3 tramsissions total of IS_IN state scheduled, first one sent as TO_IN(A)
Time T1: 3 transmissions total of "add B" scheduled, first one sent as TO_IN(A,B)
Time T2: TO_IN(A,B)
Time T3: ALLOW(B)

This results in 3 transmissions of the filter mode change, and also 3 transmissions of the source list change. They're bundled together in the transmissions at time T1 and T2; that's the goal of section 5.1.

Please let us know if you have any more questions.

Thanks,
Bill

Errata ID: 3092
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jon Hak Song
Date Reported: 2012-01-18
Rejected by: Adrian Farrel
Date Rejected: 2012-05-08

Section 6.6.3.1 says:

6.6.3.1. Building and Sending Group Specific Queries

   When a table action "Send Q(G)" is encountered, then the group timer
   must be lowered to LMQT.  The router must then immediately send a
   group specific query as well as schedule [Last Member Query Count -
   1] query retransmissions to be sent every [Last Member Query
   Interval] over [Last Member Query Time].

   When transmitting a group specific query, if the group timer is
   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
   the query message.

It should say:

6.6.3.1. Building and Sending Group Specific Queries

   When a table action "Send Q(G)" is encountered, then the group timer
   must be lowered to LMQT.  The router must then immediately send a
   group specific query as well as schedule [Last Member Query Count -
   1] query retransmissions to be sent every [Last Member Query
   Interval] over [Last Member Query Time].

   When a group specific query is being transmitted, if the group timer is
   larger than LMQT, the "Suppress Router-Side Processing" bit is set in
   the query message.

Notes:


--VERIFIER NOTES--
I am rejecting this editorial erratum because the original English is perfectly comprehensible. (It is true that it is not very elegant, but the proposed replacement isn't too good either:-)

Report New Errata



Advanced Search