RFC Errata
Found 114 records.
Status: Verified (3)
RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006
Note: This RFC has been obsoleted by RFC 7761
Source of RFC: pim (rtg)
Errata ID: 44
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen Nadas
Date Reported: 2006-11-07
Verifier Name: David Ward
Normative References say:
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4507, August 2006.
It should say:
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC
4607, August 2006.
Notes:
Reference [6] in RFC 4601 is wrong, it says SSM for IP is
RFC 4507 when it is RFC 4607.
Errata ID: 2927
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ang Way Chuang
Date Reported: 2011-08-09
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18
Section 4.2.2 says:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) {
Set SPTbit(S,G) to TRUE
}
}
It should say:
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
Set SPTbit(S,G) to TRUE
}
}
Notes:
The logical evaluation is not properly enclosed.
Errata ID: 3727
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Brown
Date Reported: 2013-09-16
Verifier Name: Adrian Farrel
Date Verified: 2013-09-17
Section 4.6.1 says:
A6: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time.
If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == true)
set SPTbit(S,G) to TRUE.
It should say:
A6: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time.
If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == Joined)
set SPTbit(S,G) to TRUE.
Notes:
The UpstreamJPState(S,G) should be 'Joined' not 'true'.
Status: Held for Document Update (95)
RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006
Note: This RFC has been obsoleted by RFC 7761
Source of RFC: pim (rtg)
Errata ID: 1104
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
It should say:
immediate_olist(*,G) =
( joins(*,G) (+) pim_include(*,G) ) (-) lost_assert(*,G)
-or-
immediate_olist(*,G) =
joins(*,G) (+) ( pim_include(*,G) (-) lost_assert(*,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1105
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
It should say:
immediate_olist(S,G) =
( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)
-or-
immediate_olist(S,G) =
joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1106
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
It should say:
inherited_olist(S,G,rpt) =
( ( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
( ( joins(*,*,RP(G)) (+) joins(*,G) ) (-) prunes(S,G,rpt) )
(+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )
Or:
inherited_olist(S,G,rpt) =
( ( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G)) )
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
Or:
inherited_olist(S,G,rpt) =
( joins(*,*,RP(G)) (+) ( joins(*,G) (-) prunes(S,G,rpt) ) )
(+) ( ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.6 says:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
It should say:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) ( pim_include(S,G) (-) lost_assert(S,G) )
Or:
inherited_olist(S,G) =
( inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G)
Or:
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
( ( joins(S,G) (+) pim_include(S,G) ) (-) lost_assert(S,G) )
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1110
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.2.1 says:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
It should say:
void
CheckSwitchToSpt(S,G) {
if ( ( ( pim_include(*,G) (-) pim_exclude(S,G) )
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
Or:
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) ( pim_exclude(S,G)
(+) pim_include(S,G) != NULL ) )
AND SwitchToSptDesired(S,G) ) {
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operations happens first.
Errata ID: 1113
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1/6.1.1 says:
The Generation_Identifier (GenID) Option SHOULD be included in all Hello messages. The GenID option contains a randomly generated 32-bit value that is regenerated each time PIM forwarding is started or restarted on the interface, including when the router itself restarts. When a Hello message with a new GenID is received from a neighbor, any old Hello information about that neighbor SHOULD be discarded and superseded by the information from the new Hello message. This may cause a new DR to be chosen on that interface.
Notes:
Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider state thrash due to falsified Hello messages with new Generation_Identifier Options.
Errata ID: 1114
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1 says:
Before an interface goes down or changes primary IP address, a Hello message with a zero HoldTime should be sent immediately (with the old IP address if the IP address changed). This will cause PIM neighbors to remove this neighbor (or its old IP address) immediately. After an interface has changed its IP address, it MUST send a Hello message with its new IP address. If an interface changes one of its secondary IP addresses, a Hello message with an updated Address_List option and a non-zero HoldTime should be sent immediately. This will cause PIM neighbors to update this neighbor's list of secondary addresses immediately.
Notes:
Section 6.1.1, item 2 only considers the possibility of falsified Designated Router election results, it does not consider forged Hello messages with zero HoldTime or with altered Address_List options.
Errata ID: 1118
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
+------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
Notes:
In state Join, when event “Receive Prune (*,*,RP)” occurs and also in state Prune Pending, when event “Expiry Timer Expires” occurs, a situation occurs where an interface will be pruned possibly more rapidly than expected as in J state, when prune is received, PP state is entered and Prune-pending timer is started, but Expiry timer is not reset/halted/etc and this does have an effect in PP state. This issue is not handled in the detailed description on page 48. Is this intentional?
Errata ID: 1119
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
The action "Send PruneEcho(*,*,RP)" is triggered when the
router stops forwarding on an interface as a result of a
prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) message
sent by the upstream router on a LAN with its own address in
the Upstream Neighbor Address field. Its purpose is to add
additional reliability so that if a Prune that should have
been overridden by another router is lost locally on the LAN,
then the PruneEcho may be received and cause the override to
happen. A PruneEcho(*,*,RP) need not be sent on an interface
that contains only a single PIM neighbor during the time this
state machine was in Prune-Pending state.
Notes:
Forged PruneEcho messages could operate as a form of Denial-of-Service (effectively the same as a Prune(*,*,RP) in this context). The issue is resolved by using AH, but it is not listed as one of the forged message types in section 6.1.1.
Errata ID: 1121
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Prune-Pending (PP)
The router has received a Prune(S,G,rpt) on this interface
from a downstream neighbor and is waiting to see whether the
prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly
like the NoInfo state.
Notes:
If a single Prune(S,G,rpt) stops forwarding, then traffic can be interrupted even when it is still needed. There is a random delay between 0 and Effective_Override_Interval(I) (0 – 2.5 seconds by specification defaults) in which traffic stops until it is overridden and traffic starts flowing again. This appears to be an optimization for efficiency vs. reliability. I believe that this should be noted and made into an optional optimization.
Errata ID: 1122
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also recommend that PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
On unnumbered interfaces on point-to-point links, the router's address SHOULD be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also RECOMMEND that PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1123
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
It should say:
these state transitions in this state machine MUST NOT occur, although seeing such a packet may cause state transitions in other state machines.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1124
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune state. The Expiry Timer (ET) is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
It should say:
A compound Join/Prune message containing a Prune(S,G<rpt) is
received on interface I with its Upstream Neighbor Address
set to the router’s primary IP address on I.
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune state. The Expiry Timer (ET) is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
Notes:
This section does not consider “Upstream Neighbor Address” as does “Receive Prune(S,G,rpt)” in “Transitions from Prune State” on page 60 or “Receive Prune(S,G,rpt)” in “Transitions from Prune-Pending State” on page 59. Is that information not important in this state transition?
Errata ID: 1128
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.6.1 says:
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )
It should say:
Too many possibilities to list.
Notes:
Left or right associativity is not established at the beginning of this document, so it is necessary to clarify which operation happens first: (+) or (-).
Errata ID: 1133
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.2 says:
Holdtime is the amount of time a receiver must keep the neighbor
reachable, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message never times out the neighbor. This may be
used with dial-on-demand links, to avoid keeping the link up with
periodic Hello messages.
Notes:
Holdtime is tunable by the sender and is required to be kept by the receiver. This coupled with the “infinity” metric 0xffff produces the conditions necessary for a Denial of Service to be possible. This is not addressed in section 6.1.1 (Forged Link-Local Messages) or 6.4 (Denial-of-Service Attacks). Additionally, utilizing AH will not solve this issue as Hello messages instantiate state upon receipt and this state constitutes the “service” that is abused in this form of attack. A tunable option to accept a maximum Holdtime for security purposes would resolve this condition.
Errata ID: 1135
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Sections 6.4 and A.2
The rationale for this is that there is no way in PIM-SM to prune traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then pruning each source individually.
Notes:
The paragraph beginning “The rationale for this…” describes a condition where a small cause can have a great effect – a (*,*,RP) join could cause state that, if it is not needed, requires a (*,G) join and many prunes for each source. This is mentioned as the last point in section 6.4, but section 6.4 fails to mention that “undoing” this state requires a join followed by multiple prunes.
Errata ID: 1142
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.3 says:
We recommend storing this information if
It should say:
We RECOMMEND storing this information if
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1143
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.3 says:
none
It should say:
PIM (*,G) Join/Prune state begins with a Join(*,G) sent to the RP. The metric to the RP is kept in the MRIB. Because the RP for this group can be any of several PIM routers, the source of the metric information in the MRIB is populated by any of the mechanisms discussed in section 4.7.
Notes:
PIM state begins with a join for a group sent towards the RP. It is not readily evident that the BSR keeps a list of current RPs for use in the hash function to map groups onto these RPs in order to seed our state.
Errata ID: 1145
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.4 says:
However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.6.
It should say:
However, we RECOMMEND storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.6.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1146
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.1.5 says:
However, we recommend storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.6.
It should say:
However, we RECOMMEND storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.6.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1151
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.3.1 says:
PIM implementers should enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router.
It should say:
PIM implementers SHOULD enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1152
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.4.2 says:
Note (+): Implementations are advised not to make this a special
case, but to arrange that this path rejoin the normal packet
forwarding path.
It should say:
Note (+): Implementations are SHOULD NOT to make this a special
case, but to arrange that this path rejoin the normal packet
forwarding path.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1154
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.1 says:
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines. On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links we also recommend that for backwards compatibility
It should say:
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet MAY cause state transitions in other state machines. On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to- point links it is also RECOMMENDED that for backwards compatibility
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1156
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.2 says:
If the upstream neighbor address field is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
It should say:
If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet MAY cause state transitions in other state machines.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1157
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.2 says:
point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
point links we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1159
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Figure 5.
Notes:
Why isn’t (S,G) state considered for the (S,G,rpt) state machine (depicted in Figure 5 on page 58)? Wouldn’t an (S,G) join have an effect up on (S,G,rpt)?
Errata ID: 1160
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.4 says:
Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune-Pending state. The Expiry Timer
(ET) is restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
It should say:
None suggested.
Notes:
Infinite toggle for every pair of routers where one wants (*,G) and the other wants (*,G) and (S,G,rpt). State moves from Prune -> PruneTmp -> NI -> Prune for the (S,G,rpt) state machine. This causes upstream thrash with Join(S,G,rpt) followed by Prune(S,G,rpt) in continual succession. Which causes Prune (S,G,rpt) state to be state limited to never actually enter Prune state (NI -> PP -> NI).
Errata ID: 1161
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.6 says:
bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL OR
(JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(G))) != NULL))
return TRUE
else
return FALSE
}
JoinDesired(*,G) is true when the router has forwarding state that
would cause it to forward traffic for G using shared tree state.
Note that although JoinDesired is true, the router's sending of a
Join(*,G) message may be suppressed by another router sending a
Join(*,G) onto the upstream interface.
Notes:
When would immediate_olist(*,G) be NULL and forwarding state exist?
Errata ID: 1162
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
RPF'(*,G) changes not due to an Assert
An event occurred that caused the next hop towards the RP for
G to change. This may be caused by a change in the MRIB
routing database or the group-to-RP mapping. Note that this
transition does not occur if an Assert is active and the
upstream interface does not change.
The upstream (*,G) state machine remains in Joined state.
Send Join(*,G) to the new upstream neighbor, which is the new
value of RPF'(*,G). Send Prune(*,G) to the old upstream
neighbor, which is the old value of RPF'(*,G). Use the new
value of RP(G) in the Prune(*,G) message or all zeros if RP(G)
becomes unknown (old value of RP(G) may be used instead to
improve behavior in routers implementing older versions of
this spec). Set the Join Timer (JT) to expire after
t_periodic seconds.
Notes:
Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.
Errata ID: 1166
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds.
It should say:
The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. If the
Join Timer is set to expire in less than t_override seconds, leave it
unchanged.
Notes:
It would make the Join Timer clearer to understand if an explicit statement was made indicating that if the Join Timer is less than t_override, it should be left unchanged. This needs to be made for “See Prune(S,G) to RPF’(S,G)”, “See Prune(S,G,rpt) to RPF’(S,G)”, and “See Prune(*,G) to RPF’(S,G)”.
Errata ID: 1167
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.7 says:
The upstream (S,G) state machine remains in Joined state.
Send Join(S,G) to the new upstream neighbor, which is the new
value of RPF'(S,G). Send Prune(S,G) to the old upstream
neighbor, which is the old value of RPF'(S,G). Set the Join
Timer (JT) to expire after t_periodic seconds.
Notes:
Sending the Prune(*,G) may help state issues, but if the change in MRIB was spurious or there was a situation where a difference of opinion in lower route costs exists, some traffic may be dropped until the MRIB becomes consistent again.
Errata ID: 1168
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.8 says:
# Note: we joined the shared tree, but there was an (S,G) assert
# and the source tree RPF neighbor is different.
Notes:
In the comments on the “else” clause, why would we think that we were on the shared tree if the SPTbit is false?
Errata ID: 1169
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.9 says:
In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is used to delay triggered Join(S,G,rpt) messages to prevent implosions of triggered messages.
Notes:
What does “implosions of triggered messages” refer to?
Errata ID: 1170
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.5.9 says:
+------------++--------------------------------------------------------+ | || Event | | ++--------------+--------------+-------------+------------+ |Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ | | || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist | | || ->True | ->False | ->False | (S,G,rpt) | | || | | | ->non-NULL | +------------++--------------+--------------+-------------+------------+ |RPTNotJoined|| -> P state | - | - | -> NP state| |(G) (NJ) || | | | | +------------++--------------+--------------+-------------+------------+ |Pruned || - | -> NP state | -> NJ state | - | |(S,G,rpt) || | Send Join | | | |(P) || | (S,G,rpt) | | | +------------++--------------+--------------+-------------+------------+ |NotPruned || -> P state | - | -> NJ state | - | |(S,G,rpt) || Send Prune | | Cancel OT | | |(NP) || (S,G,rpt); | | | | | || Cancel OT | | | | +------------++--------------+--------------+-------------+------------+
Notes:
In the intersection of “RPTNotJoined(G)” and “PruneDesired(S,G,rpt) -> True”, the state table indicates that the result is to move into “Pruned(S,G,rpt)” state. This occurs again in the text on pages 80 and 81. Why would join state be entered for (*,G) simply in order to prune (S,G,rpt)?
Errata ID: 1181
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.6.5 says:
Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does
indicate that such a join should be dropped.
It should say:
Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does
indicate that such a join SHOULD be dropped.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1183
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5 says:
Holdtime
The amount of time a receiver must keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message should hold the state until canceled by
the appropriate canceling Join/Prune message, or timed out
according to local policy. This may be used with dial-on-demand
links, to avoid keeping the link up with periodic Join/Prune
messages.
Note that the HoldTime must be larger than the
J/P_Override_Interval(I).
It should say:
Holdtime
The amount of time a receiver MUST keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message SHOULD hold the state until canceled by
the appropriate canceling Join/Prune message, or timed out
according to local policy. This MAY be used with dial-on-demand
links, to avoid keeping the link up with periodic Join/Prune
messages.
Note that the HoldTime MUST be larger than the
J/P_Override_Interval(I).
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1184
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.1 says:
Each wildcard group set may contain one or more
(*,*,RP) source list entries in either the Joined or Pruned
lists.
A (*,*,RP) source list entry may only exist in a wildcard group
set. When added to a Joined source list, this type of source
entry expresses the router's interest in receiving traffic for
all groups mapping to the specified RP.
It should say:
Each wildcard group set MAY contain one or more
(*,*,RP) source list entries in either the Joined or Pruned
lists.
A (*,*,RP) source list entry MAY only exist in a wildcard group
set. When added to a Joined source list, this type of source
entry expresses the router's interest in receiving traffic for
all groups mapping to the specified RP.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1185
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.1 says:
Each group-
specific set may contain (*,G), (S,G,rpt), and (S,G) source list
entries in the Joined or Pruned lists.
(*,G)
The (*,G) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic sent to the
group through the Rendezvous-Point shared tree. There may
only be one such entry in both the Joined and Pruned lists of
a group-specific set.
(*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set
to the full length of the IP address, and both the WC and RPT
bits of the Encoded-Source-Address set.
(S,G,rpt)
The (S,G,rpt) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic through the
shared tree sent by the specified source to this group. For
each source address, the entry may exist in only one of the
Joined and Pruned source lists of a group-specific set, but
not both.
(S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address, and the WC bit cleared
and the RPT bit set in the Encoded-Source-Address.
(S,G)
The (S,G) source list entry is used in Join/Prune messages
sent towards the specified source. It expresses interest (or
lack thereof) in receiving traffic through the shortest path
tree sent by the source to the specified group. For each
source address, the entry may exist in only one of the Joined
and Pruned source lists of a group-specific set, but not both.
It should say:
Each group-
specific set MAY contain (*,G), (S,G,rpt), and (S,G) source list
entries in the Joined or Pruned lists.
(*,G)
The (*,G) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic sent to the
group through the Rendezvous-Point shared tree. There MUST
be one such entry in both the Joined and Pruned lists of
a group-specific set.
(*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set
to the full length of the IP address, and both the WC and RPT
bits of the Encoded-Source-Address set.
(S,G,rpt)
The (S,G,rpt) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic through the
shared tree sent by the specified source to this group. For
each source address, the entry MUST exist in only one of the
Joined and Pruned source lists of a group-specific set, but
not both.
(S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address, and the WC bit cleared
and the RPT bit set in the Encoded-Source-Address.
(S,G)
The (S,G) source list entry is used in Join/Prune messages
sent towards the specified source. It expresses interest (or
lack thereof) in receiving traffic through the shortest path
tree sent by the source to the specified group. For each
source address, the entry MUST exist in only one of the Joined
and Pruned source lists of a group-specific set, but not both.
Notes:
RFC 2119 keywords are not capitalized.
Errata ID: 1192
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
This list of (S,G,rpt) Pruned source-list entries MUST not be split in multiple messages.
It should say:
This list of (S,G,rpt) Pruned source-list entries MUST NOT be split in multiple messages.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1193
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune message, but the router has more than N (S,G,rpt) Prunes to add, then the router MUST choose to include the first N (numerically smallest in network byte order) IP addresses.
Notes:
Only N (S,G,rpt) Prune entries are transmitted in the biggest Join/Prune message, what about the remaining (S,G,rpt) entries? Are they ignored? Is a second message generated? This should be made clear.
Errata ID: 1194
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 4.9.5.2 says:
Assert messages may also be sent in response to an Assert message from another router.
It should say:
Assert messages MAY also be sent in response to an Assert message from another router.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1195
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.2 says:
Either static configuration of IP addresses or an IPsec security association may be used.
It should say:
Either static configuration of IP addresses or an IPsec security association MAY be used.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1198
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.3.2.2 says:
In order to simplify the management problem, it may be acceptable to use the same authentication algorithm and authentication parameters, regardless of the sending RP and regardless of the destination DR. Although a unique SA is needed for each DR, the same authentication
It should say:
In order to simplify the management problem, it MAY be acceptable to use the same authentication algorithm and authentication parameters, regardless of the sending RP and regardless of the destination DR. Although a unique SA is needed for each DR, the same authentication
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1200
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6.4 says:
- Forging a (*,*,RP) join presents a possibility for a denial-of-
service attack by causing all traffic in the domain to flow to the
PMBR issuing the join. (*,*,RP) behavior is included here
primarily for backwards compatibility with prior revisions of the
spec. However, the implementation of (*,*,RP) and PMBR is
optional. When using (*,*,RP), the security concerns should be
carefully considered.
It should say:
- Forging a (*,*,RP) join presents a possibility for a denial-of-
service attack by causing all traffic in the domain to flow to the
PMBR issuing the join. (*,*,RP) behavior is included here
primarily for backwards compatibility with prior revisions of the
spec. However, the implementation of (*,*,RP) and PMBR is
optional. When using (*,*,RP), the security concerns SHOULD be
carefully considered.
Notes:
RFC 2119 keyword is not capitalized.
Errata ID: 1201
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Date Held: 2009-03-22
Section 6 says:
See note.
It should say:
IPsec usage is recommended to secure PIM messages, but PIM relies upon an MRIB populated outside of PIM and it should be noted that for PIM security to be effective, securing the sources of change to the MRIB in a similar fashion to IPsec is required to be consistent and secure.
Notes:
An additional note should be made with regard to PIM security, possibly as
section 6.3.3?
Errata ID: 1094
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section Table of Con says:
A.2. Sources Internal to the PIM-SM Domain ...................144
It should say:
A.2. Sources Internal to the PIM-SM Domain ...................144
Notes:
One extra space is listed after the heading and before the item.
Errata ID: 1095
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 1. Per-(S,G) register state machine at a DR ................38
It should say:
Figure 1. Per-(S,G) register state machine at a DR ................39
Notes:
Figure 1 occurs on page 39, is listed as occurring on page 38.
Errata ID: 1096
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 4. Downstream per-interface (S,G) state machine ............53
It should say:
Figure 4. Downstream per-interface (S,G) state machine ............54
Notes:
Figure 1 occurs on page 54, is listed as occurring on page 53.
Errata ID: 1097
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
It should say:
Figure 5. Downstream per-interface (S,G,rpt) state machine ........58
Notes:
Figure 1 occurs on page 58, is listed as occurring on page 57.
Errata ID: 1098
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section List of Figu says:
Figure 6. Upstream (*,*,RP) state machine .........................62
It should say:
Figure 6. Upstream (*,*,RP) state machine ......................63-64
Notes:
Figure 1 occurs on pages 63-64, is listed as occurring on page 62.
Errata ID: 1101
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section List of Figu says:
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................77
It should say:
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................78
Notes:
Figure 1 occurs on page 78, is listed as occurring on page 77.
Errata ID: 1108
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section 4.2 says:
Second, we check to see if the SPTbit should be set because we've now switched from the RP tree to the SPT.
It should say:
See notes
Notes:
The dependent clause does not follow from the independent clause.
Errata ID: 1109
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: David Ward
Section 4.2 says:
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in a implementation-dependent manner.
It should say:
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in an implementation-dependent manner.
Notes:
Misspelling
Errata ID: 1111
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2.2 says:
3. Noone wants the packet on the RP tree.
It should say:
3. No one wants the packet on the RP tree.
Notes:
Misspelling
Errata ID: 1112
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.1 says:
We note that some implementations do not send Hello messages on
point-to-point interfaces. This is non-compliant behavior. A
compliant PIM router MUST send Hello messages, even on point-to-
point interfaces.
It should say:
We note that some implementations do not send Hello messages on point-to-point interfaces. This is non-compliant behavior. A compliant PIM router MUST send Hello messages, even on point-to- point interfaces.
Notes:
It is not clear why this text is indented.
Errata ID: 1115
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.2 says:
We note that some PIM implementations do not send Hello messages on
point-to-point interfaces and thus cannot perform DR election on
such interfaces. This is non-compliant behavior. DR election MUST
be performed on ALL active PIM-SM interfaces.
It should say:
See notes.
Notes:
Are the different references to PIM and PIM-SM intentional? Does PIM-DM enter into this?
Errata ID: 1116
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.3 says:
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the LAN Prune Delay Hello option:
It should say:
In addition to the information recorded for the DR Election, the following per-neighbor information is obtained from the LAN Prune Delay Hello option:
Notes:
Misspelling.
Errata ID: 1117
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.3 says:
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective_Propagation_Delay of interface I is: … When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
It should say:
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Propagation Delay of interface I is: … When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
Notes:
Inconsistency. Either “Effective_Override_Interval” should be used or “Effective Override Interval” should be used.
Errata ID: 1126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
See pages 72-76
It should say:
See notes
Notes:
The figure given on pages 72-73 lists additional state changes, the last three of which are “RPF’(S,G) changes not due to an Assert”, “RPF’(S,G) GenID changes”, “RPF’(S,G) changes due to an Assert”, but the order given in the descriptions after the diagram on pages 74-76 lists the last three as: “RPF’(S,G) changes due to an Assert”, “RPF’(S,G) changes not due to an Assert”, and “RPF’(S,G) GenID changes.”
Errata ID: 1127
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.9 says:
See pages 78-80
It should say:
See notes
Notes:
The figure given on page 78 lists additional state changes. The order given does not match the order given in the detailed descriptions that follow on pages 79-80.
Errata ID: 1129
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.1 says:
An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on an downstream interface that
is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state and perform
Actions A1 (below), which will initiate the assert negotiation
for (S,G).
It should say:
An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on a downstream interface that
is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state and perform
Actions A1 (below), which will initiate the assert negotiation
for (S,G).
Notes:
Misspelling.
Errata ID: 1130
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.1 says:
A4: Send AssertCancel(S,G).
Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default
values).
A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return their default
values).
It should say:
A4: Send AssertCancel(S,G).
Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default
values).
A5: Delete assert info (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default
values).
Notes:
Missing words.
Errata ID: 1131
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.7.2 says:
The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router:
It should say:
See notes.
Notes:
The term “transients” is not defined in section 2.1. Does this refer to the same “transients” as in RFC 1112, section2, paragraph 3?
Errata ID: 1134
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.2 says:
The T bit specifies the ability of the
sending router to disable joins suppression.
It should say:
The T bit specifies the ability of the
sending router to disable join suppression.
Notes:
Misspelling.
Errata ID: 1136
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. The list of definitions that I was able to determine are given below. Some definitions are not given and these are marked below. Address_List 31* Assert(*,G) 128* Assert(S,G) 128* AssertCancel(*,G) 99* AssertCancel(S,G) 99* AssertTimer(*,G,I) not listed X AssertTimer(S,G,I) not listed X AssertTrackingDesired(*,G,I) 93* AssertTrackingDesired(S,G,I) 86* AssertWinner(*,G,I) 100* AssertWinner(S,G,I) 100* AssertWinnerMetric(*,G,I) 101* AssertWinnerMetric(S,G,I) 101* assert_metric 98* Assert_Override_Interval 132* Assert_Time 132* AT(*,G,I) 129* AT(S,G,I) 129* CheckSwitchToSpt(S,G) 28* CouldAssert(*,G,I) 93* CouldAssert(S,G,I) 86* CouldRegister(S,G) 41* Default_Hello_Holdtime not listed X DirectlyConnected(S) 27* DownstreamJPState(*,*,RP,I) 45* (state of FSM in section 4.5.1) DownstreamJPState(*,G,I) 49* (state of FSM in section 4.5.2) DownstreamJPState(S,G,I) 53* (state of FSM in section 4.5.3) DownstreamJPState(S,G,rpt,I) 56* (state of FSM in section 4.5.4) DR(I) 33* dr_is_better(a,b,I) 33* DR_Priority 31* Effective_Override_Interval(I) 36* Effective_Propagation_Delay(I) 35* ET(*,*,RP,I) 128* ET(*,G,I) 128* ET(S,G,I) 129* ET(S,G,rpt,I) 129* GenID 31* Hash_Function not listed X Hello_Holdtime 131* Hello_Period 130* HT(I) 31* IGMP 6* immediate_olist(*,*,RP) 22* immediate_olist(*,G) 22* immediate_olist(S,G) 22* infinite_assert_metric() 99* inherited_olist(S,G) 22* inherited_olist(S,G,rpt) 22* I_Am_Assert_Loser(*,G,I) not listed X I_Am_Assert_Loser(S,G,I) not listed X I_am_DR(I) 33* I_am_RP(G) 44* J/P_Holdtime 131* J/P_Override_Interval(I) 132* JoinDesired(*,*,RP) 64* JoinDesired(*,G) 68* JoinDesired(S,G) 73* joins(*,*,RP(G)) not listed X joins(*,*,RP) 23* joins(*,G) 23* joins(S,G) 23* JT(*,*,RP) 129* JT(*,G) 129* JT(S,G) 129* KAT(S,G) 129* KeepaliveTimer(S,G) not listed X Keepalive_Period 134* lan_delay_enabled(I) 35* LAN_Prune_Delay not listed X local_receiver_exclude(S,G,I) 23* local_receiver_include(*,G,I) not listed X local_receiver_include(S,G,I) not listed X lost_assert(*,G) 24* lost_assert(*,G,I) 100* lost_assert(S,G) 24* lost_assert(S,G,I) 100* lost_assert(S,G,rpt) 24* lost_assert(S,G,rpt,I) 100* MBGP 6* MFIB 6* MLD 6* MRIB 6* MRIB.next_hop(host) 25* my_assert_metric(*,G,I) not listed X my_assert_metric(S,G,I) 98* NBR(Interface,IP_address) not listed X NLT(N,I) not listed X OT(S,G,rpt) 77* Override_Interval(I) 130? (Why is it termed a “variable”?) packet_arrives_on_rp_tunnel(pkt) 43* pim_exclude(S,G) 22* pim_include(*,G) 22* pim_include(S,G) 22* PPT(*,*,RP,I) not listed X PPT(*,G,I) not listed X PPT(S,G,I) not listed X PPT(S,G,rpt,I) not listed X Propagation_Delay(I) 130? (Why is it termed a “variable”?) Propagation_delay_default 130* PruneDesired(S,G,rpt) 79* prunes(S,G,rpt) 23* Register-Stop(*,G) not listed X Register-Stop(S,G) not listed X Register-StopTimer(S,G) not listed X Register_Probe_Time 135* Register_Suppression_Time 135* RP(G) not listed X RPF 6* RPF’(*,G) 24* RPF’(S,G) 25* RPF’(S,G,rpt) 24* RPF_interface not listed X RPF_interface(host) not listed X RPFJoinDesired(G) 79* rpt_assert_metric(G,I) not listed X RST(S,G) 135? SPTbit(S,G) not listed X spt_assert_metric(S,I) 98* SSM 106* Suppression_Enabled(I) 36* SwitchToSptDesired(S,G) 28* TIB 6* Triggered_Hello_Delay 130* t_joinsuppress not listed X t_override 133* t_override_default 130* t_periodic 133* t_suppressed 133* Update_SPTbit(S,G,iif) 29* UpstreamJPState(S,G) not listed X
Notes:
The locations of the definitions of functions are not given. Given that there are so many functions, it would be useful to have a notation that indicates this. I propose adding a “*” next to the page reference that contains the definition of that function as well as adding an explanatory note to the index, such as:
For function definitions, see the pages marked with an asterisk (*).
Errata ID: 1137
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Index not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. AssertTimer(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertTimer(*,G,I) page 24 (missing on the page referred) AssertTimer(*,G,I) page 132 (missing on the page referred) AssertTimer(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AssertTimer(S,G,I) page 24 (missing on the page referred) AssertTimer(S,G,I) page 132 (missing on the page referred) AssertWinner(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertWinner(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AssertWinner(S,G,I) page 100 (duplicate reference) AssertWinnerMetric(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AssertWinnerMetric(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) AT(*,G,I) page 24 (missing on the page referred) AT(*,G,I) page 91 (no explicit function reference is found, but it is referred to on the page) AT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) AT(S,G,I) page 24 (missing on the page referred) AT(S,G,I) page 84 (no explicit function reference is found, but it is referred to on the page) CouldRegister(S,G) page 39 (no explicit function reference is found, but it is referred to on the page) DirectlyConnected(S) page 27 (duplicate reference) dr_is_better(a,b,I) page 33 (duplicate reference) ET(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page) ET(*,*,RP,I) page 46 (no explicit function reference is found, but it is referred to on the page) ET(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) ET(*,G,I) page 50 (no explicit function reference is found, but it is referred to on the page) ET(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) ET(S,G,I) page 53 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 57 (no explicit function reference is found, but it is referred to on the page) ET(S,G,rpt,I) page 59 (no explicit function reference is found, but it is referred to on the page) Hash_Function page 12 (no explicit function reference is found, but it is referred to on the page) Hash_Function page 105 (no explicit function reference is found, but it is referred to on the page) IGMP page 17 (missing on the page referred) IGMP page 23 (missing on the page referred) IGMP page 105 (missing on the page referred) J/P_Holdtime page 47 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 51 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 55 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 59 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 65 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 69 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 74 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 121 (no explicit function reference is found, but it is referred to on the page) J/P_Holdtime page 133 (no explicit function reference is found, but it is referred to on the page) JoinDesired(*,G) page 17 (missing on the page referred) joins(*,*,RP) page 86 (missing on the page referred) joins(*,*,RP) page 93 (missing on the page referred) JT(*,*,RP) page 15 (no explicit function reference is found, but it is referred to on the page) JT(*,G) page 16 (no explicit function reference is found, but it is referred to on the page) JT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KAT(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KAT(S,G) page 26 (missing on the page referred) KAT(S,G) page 27 (missing on the page referred) KAT(S,G) page 28 (missing on the page referred) KAT(S,G) page 41 (missing on the page referred) KAT(S,G) page 43 (missing on the page referred) KAT(S,G) page 73 (missing on the page referred) KAT(S,G) page 108 (missing on the page referred) KeepaliveTimer(S,G) page 18 (no explicit function reference is found, but it is referred to on the page) KeepaliveTimer(S,G) page 26 (missing on the page referred) KeepaliveTimer(S,G) page 27 (duplicate reference) KeepaliveTimer(S,G) page 108 (missing on the page referred) KeepaliveTimer(S,G) page 129 (missing on the page referred) KeepaliveTimer(S,G) page 134 (missing on the page referred) LAN_Prune_Delay page 31 (no explicit function reference is found, but it is referred to on the page) local_receiver_include(S,G,I) page 23 (missing on the page referred) Next line duplicates the previous line (reference on page 144 is correct) MFIB page 13 (missing on the page referred) MLD page 17 (missing on the page referred) MLD page 23 (missing on the page referred) MLD page 105 (missing on the page referred) MRIB page 66 (duplicate reference) MRIB page 75 (missing on the page referred) NBR(Interface,IP address) page 37 (missing on the page referred) OT(S,G,rpt) page 20 (no explicit function reference is found, but it is referred to on the page) Override_Interval(I) page 14 (missing on the page referred) Override_Interval(I) page 34 (missing on the page referred) Override_Interval(I) page 132 (missing on the page referred) pim_exclude(S,G) page 22 (duplicate reference) pim_include(*,G) page 22 (duplicate reference) pim_include(S,G) page 22 (duplicate reference) PPT(*,*,RP,I) page 15 (no explicit function reference is found, but it is referred to on the page) PPT(*,*,RP,I) page 46 (missing on the page referred) PPT(*,G,I) page 16 (no explicit function reference is found, but it is referred to on the page) PPT(*,G,I) page 50 (missing on the page referred) PPT(S,G,I) page 18 (no explicit function reference is found, but it is referred to on the page) PPT(S,G,I) page 53 (missing on the page referred) PPT(S,G,rpt,I) page 20 (no explicit function reference is found, but it is referred to on the page) PPT(S,G,rpt,I) page 57 (missing on the page referred) PPT(S,G,rpt,I) page 59 (missing on the page referred) Propagation_Delay(I) page 31 (missing on the page referred) Propagation_Delay(I) page 132 (missing on the page referred) Register-StopTimer(S,G) page 38 (missing on the page referred) Register-StopTimer(S,G) page 39 (missing on the page referred) Register-StopTimer(S,G) page 129 (missing on the page referred) Register-StopTimer(S,G) page 135 (no explicit function reference is found, but it is referred to on the page) RP(G) page 5 (missing on the page referred) RP(G) page 99 (missing on the page referred) RPF’(*,G) page 101 (missing on the page referred) RPF’(S,G) page 101 (missing on the page referred) rpt_assert_metric(G,I) page 99 (missing on the page referred) RST(S,G) page 38 (missing on the page referred) RST(S,G) page 39 (missing on the page referred) SPTbit(S,G) page 19 (no explicit function reference is found, but it is referred to on the page) SPTbit(S,G) page 53 (no explicit function reference is found, but it is referred to on the page) SPTbit(S,G) page 86 (duplication reference) SPTbit(S,G) page 108 (missing on the page referred) SSM page 10 (missing on the page referred) SwitchToSptDesired(S,G) page 28 (duplicate reference) t_joinsuppress page 64 (missing on the page referred) t_joinsuppress page 68 (missing on the page referred) t_suppressed page 73 (missing on the page referred)
Notes:
The items above are referred to in the Index, but were not found at the locations specified in the Index.
Errata ID: 1138
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here.
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. GenID page 14 RPF page 15 IGMP page 16 MLD page 16 JoinDesired(*,G) page 17 MRIB page 17 IGMP page 19 pim_exclude(S,G) page 21 immediate_olist(S,G) page 21 inherited_olist(S,G) page 21 inherited_olist(S,G,rpt) page 21 immediate_olist(*,*,RP) page 21 immediate_olist(*,G) page 21 lost_assert(S,G,rpt) page 22 inherited_olist(S,G,rpt) page 22 local_receiver_include(*,G,I) page 22 local_receiver_include(S,G,I) page 22 IGMP page 22 MLD page 22 NBR(Interface,IP_address) page 24 I_Am_Assert_Loser(S,G,I) page 25 AssertWinner(S,G,I) page 25 RPF_interface(Interface,IP_address) page 25 RPF’(*,G) page 25 RPF’(S,G,rpt) page 25 RPF’(*,G) page 25 Assert(S,G) page 25 RPF_interface(host) page 25 RP(G) page 25 I_Am_Assert_Loser(*,G,I) page 25 RPF_interface(host) page 26 MRIB page 26 RP(G) page 27 inherited_olist(S,G) page 28 inherited_olist(S,G,rpt) page 28 Update_SPTbit(S,G,iif) page 28 UpstreamJPState(S,G) page 28 Keepalive_Period page 28 RP(G) page 29 I_Am_Assert_Loser(S,G,I) page 29 Assert(S,G) page 29 RPF’(S,G) page 30 RPF’(*,G) page 30 Assert(S,G) page 30 JoinDesired(S,G) page 30 GenID page 32 MRIB page 37 Register_Probe_Time page 40 Register_Suppression_Time page 40 Register-Stop(S,G) page 42 inherited_olist(S,G,rpt) page 43 KeepaliveTimer(S,G) page 44 inherited_olist(S,G) page 44 RPF_interface(host) page 62 JoinDesired(*,*,RP) page 63 t_periodic page 63 MRIB page 63 t_joinsuppress page 63 t_override page 63 RPF_interface(host) page 64 JoinDesired(*,*,RP) page 65 immediate_olist(*,*,RP) page 65 NBR(Interface,IP_address) page 65 RPF_interface(host) page 65 MRIB page 65 t_periodic page 65 t_override page 65 RPF_interface(host) page 66 t_periodic page 66 t_override page 66 JoinDesired(*,G) page 67 t_periodic page 67 t_joinsuppress page 67 t_override page 67 JoinDesired(*,*,RP) page 68 AssertWinner(*,G,I) page 68 JoinDesired(*,G) page 69 immediate_olist(*,G) page 69 RPF’(*,G) page 69 t_periodic page 69 RP(G) page 69 t_override page 70 RPF_interface(host) page 70 RP(G) page 70 t_periodic page 70 MRIB page 71 JoinDesired(S,G) page 72 t_periodic page 72 SPTbit(S,G) page 72 RPF’(S,G) page 72 t_joinsuppress page 72 t_override page 72 RPF’(S,G) page 73 JoinDesired(S,G) page 74 inherited_olist(S,G) page 74 RPF’(S,G) page 74 t_override page 75 RPF’(S,G) page 75 RPF_interface(host) page 75 t_periodic page 76 t_override page 76 PruneDesired(S,R,rpt) page 78 RPTJoinDesired(G) page 78 inherited_olist(S,G,rpt) page 78 RPF’(S,G,rpt) page 78 RPF’(*,G) page 78 RP(G) page 79 t_override page 80 RPF’(S,G,rpt) page 80 RPF’(*,G) page 80 RPF’(S,G,rpt) page 81 PruneDesired(S,G,rpt) page 81 Assert(*,G) page 82 RPF’(*,G) page 82 JoinDesired(*,G) page 82 JoinDesired(*,*,RP) page 82 AssertTrackingDesired(S,G,I) page 84 RPF_interface(host) page 85 joins(*,*,RP) page 86 lost_assert(S,G,I) page 86 GenID page 89 RPF_interface(host) page 90 Assert(S,G) page 90 UpstreamJPState(S,G) page 90 AssertTrackingDesired(*,G,I) page 92 joins(*,*,RP) page 93 GenID page 96 RPF_interface(host) page 97 RP(G) page 97 Assert(*,G) page 97 rpt_assert_metric(G,I) page 98 infinite_assert_metric() page 98 rpt_assert_metric(G,I) page 98 MRIB page 99 RP(G) page 100 AssertWinnerMetric(S,G,I) page 100 Assert(S,G) page 100 Assert(*,G) page 100 Assert(S,G) page 101 Assert(*,G) page 101 AssertWinner(S,G,I) page 101 MRIB page 101 RPF’(*,G) page 102 IGMP page 104 MLD page 104 SSM page 107 SSM page 108 Assert(S,G) page 108 Triggered_Hello_Delay page 131 Default_Hello_Holdtime page 131 Hello_Period page 131 JT(*,G) page 131 AssertTimer(*,G,I) page 132 AssertTimer(S,G,I) page 132 Effective_Override_Interval(I) page 133 Register_Suppression_Time page 134 Register_Probe_Time page 134 SSM page 137 RPF_interface(host) page 144 local_receiver_include(S,G,I) page 145 local_receiver_include(*,G,I) page 145 DownstreamJPState(*,G,I) page 145 DownstreamJPState(S,G,rpt,I) page 145
Notes:
Functions were found in the document that were mentioned in the Index, but there was no reference given in the Index.
Errata ID: 1139
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section Index says:
Not reproduced here
It should say:
Due to the number of change recommendations to the index, I am not reproducing the index entries here. NotJoined(*,*,RP) page 15 NotJoined(*,G) page 16 NotJoined(S,G) page 18 Prune(*,*,RP) page 15 Join(*,G) page 17 Prune(*,G) page 17 Join(S,G) page 19 Prune(S,G) page 19 Prune(S,G,rpt) page 21 Join(*,G) page 21 Prune(S,G,rpt) page 25 Join(*,G) page 25 Join(S,G) page 29 Prune(S,G,rpt) page 29 Prune(*,*,RP) page 46 Join(*,*,RP) page 46 Join(*,*,RP) page 47 Prune(*,*,RP) page 47 Prune(*,*,RP) page 48 Join(*,*,RP) page 48 Prune(*,*,RP) page 49 Join(*,G) page 49 Prune(*,G) page 49 Join(*,G) page 50 Prune(*,G) page 50 Join(*,G) page 51 Prune(*,G) page 51 Join(*,G) page 52 Prune(*,G) page 52 Join(S,G) page 54 Prune(S,G) page 54 PruneEcho(*,*,RP) page 46 PruneEcho(*,*,RP) page 48 PruneEcho(*,*,RP) page 49 PruneEcho(*,G) page 50 PruneEcho(*,G) page 52 PruneEcho(S,G) page 54 Join(S,G) page 55 Prune(S,G) page 55 PruneEcho(S,G) page 56 Prune(S,G) page 56 Prune(S,G,rpt) page 57 Join(*,G) page 58 Join(S,G,rpt) page 58 Prune(S,G,rpt) page 58 Prune(S,G,rpt) page 59 Join(*,G) page 59 Join(S,G,rpt) page 59 Join(*,G) page 60 Join(S,G,rpt) page 60 Prune(S,G,rpt) page 60 Prune(S,G,rpt) page 61 Prune(*,G) page 61 Join(*,*,RP) page 61 Join(*,G) page 61 Join(*,*,RP) page 62 Prune(*,*,RP) page 62 Prune(*,*,RP) page 63 Join(*,*,RP) page 64 Prune(*,*,RP) page 64 Prune(*,*,RP) page 65 Join(*,*,RP) page 65 Join(*,*,RP) page 63 Join(*,*,RP) page 66 Prune(*,*,RP) page 66 Join(*,G) page 66 Prune(*,G) page 66 Join(*,G) page 67 Prune(*,G) page 67 Join(S,G) page 73 Prune(*,G) page 73 Join(*,G) page 68 Prune(*,G) page 68 Prune(*,G) page 69 Join(*,G) page 69 Join(*,G) page 70 Prune(*,G) page 70 Join(S,G) page 71 Prune(S,G) page 71 Prune(S,G,rpt) page 71 Join(S,G) page 74 Prune(S,G) page 74 Prune(*,G) page 75 Prune(S,G,rpt) page 75 Join(S,G) page 76 Prune(S,G) page 76 Prune(S,G,rpt) page 76 Join(*,G) page 76 Join(S,G,rpt) page 76 Join(S,G,rpt) page 77 Prune(S,G,rpt) page 78 Join(S,G,rpt) page 78 Prune(S,G) page 78 Join(S,G,rpt) page 79 Prune(S,G,rpt) page 79 Prune(S,G) page 80 Join(S,G,rpt) page 80 Prune(S,G,rpt) page 80 Prune(S,G,rpt) page 81 Join(*,G) page 81 Join(*,*,RP) page 81 Join(S,G,rpt) page 81 Prune(S,G,rpt) page 82 Join(*,G) page 82 Prune(S,G,rpt) page 82 Join(*,*,RP) page 82 Prune(*,G) page 82 Prune(*,*,RP) page 82 Join(*,*,RP) page 83 Prune(S,G,rpt) page 83 Join(S,G) page 85 Join(S,G) page 90 Join(*,G) page 93 Join(*,*,RP) page 93 Join(*,G) page 97 Join(*,*,RP) page 97 Join(*,G) page 101 Join(S,G) page 101 Join(S,G) page 102 Join(*,*,RP) page 102 Join(*,G) page 102 Prune(S,G,rpt) page 102 Join(S,G,rpt) page 102 Join(*,G) page 125 Prune(*,G) page 125 Join(S,G,rpt) page 125 Prune(S,G,rpt) page 125 Join(S,G) page 125 Prune(S,G) page 125 Join(*,*,RP) page 125 Prune(*,*,RP) page 125 Join(S,G) page 143 Join(*,*,RP) page 144 Joined(*,*,RP) page 15 Joined(*,G) page 16 Joined(S,G) page 18 Join(S,G) page 72 Prune(S,G) page 72 Prune(S,G,rpt) page 72 Join(S,G,rpt) page 82 IGMPv3 page 19 IGMPv3 page 20 IGMPv3 page 21 RPTNotJoined(G) page 20 NotPruned(S,G,rpt) page 20 Pruned(S,G,rpt) page 20 RPTNotJoined(G) page 77 Pruned(S,G,rpt) page 77 NotPruned(S,G,rpt) page 77 RPTNotJoined(G) page 78 Pruned(S,G,rpt) page 78 NotPruned(S,G,rpt) page 78 RPTNotJoined(host) page 80 RPTNotJoined(host) page 81 Pruned(S,G,rpt) page 81 NotPruned(S,G,rpt) page 81 immediate_olist(S,G,rpt) page 21 PMBR(S,G) page 43 RP_Keepalive_Period page 43 next_hop(host) page 63 next_hop(host) page 65 next_hop(host) page 66 Assert(*,*,RP) page 82 pref(S) page 98 metric(S) page 98 my_ip_address(I) page 98 pref(S) page 99 metric(S) page 99 my_ip_address(I) page 99 Value(G,M,C) page 105 C(i) page 105 pref(S) page 128 metric(S) page 128
Notes:
Some functions were found in the document that did not have any entry in the Index. These are itemized above.
Errata ID: 1140
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 2.1 says:
Upstream
Towards the root of the tree. The root of tree may be either
the source or the RP, depending on the context.
It should say:
Upstream
Towards the root of the tree. The root of the tree may be either
the source or the RP, depending on the context.
Notes:
Misspelling.
Errata ID: 1141
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 3.6 says:
This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source-specific trees.
It should say:
This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither or both router has (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source for source-specific trees.
Notes:
Word choice.
Errata ID: 1144
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.1.4 says:
Local membership is the result of the local source-specific membership mechanism (such as IGMP version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won a (S,G) assert on this interface for this group.
It should say:
Local membership is the result of the local source-specific membership mechanism (such as IGMP version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won an (S,G) assert on this interface for this group.
Notes:
Misspelling.
Errata ID: 1147
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2 says:
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to RP, except at the RP when it is the
It should say:
RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to the RP, except at the RP when it is the
Notes:
Missing word.
Errata ID: 1149
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.2.2 says:
Basically, Update_SPTbit will set the SPTbit if we have the appropriate (S,G) join state, and if the packet arrived on the correct upstream interface for S, and if one or more of the following conditions applies:
It should say:
See notes
Notes:
Should “Basically, Update_SPTbit will set” be “Basically, Update_SPTbit(S,G,iif) will set”?
Errata ID: 1150
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.3.1 says:
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
It should say:
The LAN Prune Delay Option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay(I) and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
Notes:
Misspelling.
Errata ID: 1155
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.1 says:
PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
It should say:
PIM Join/Prune messages with an upstream neighbor address field of all zeros also be accepted.
Notes:
Word choice.
Errata ID: 1163
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
If a (S,G) Assert occurs on the upstream interface,
It should say:
If an (S,G) Assert occurs on the upstream interface,
Notes:
Misspelling.
Errata ID: 1164
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
and this changes the this router's idea of the upstream neighbor,
It should say:
and this changes the router's idea of the upstream neighbor, -or- and this changes this router's idea of the upstream neighbor,
Notes:
Word choice.
Errata ID: 1165
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.7 says:
In addition, if MRIB changes
It should say:
In addition, if the MRIB changes
Notes:
Missing word.
Errata ID: 1172
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.5.9 says:
If the router was previously in RPTNotJoined(G)
state, then there is no need to trigger an action in this state
machine because sending a Prune(S,G,rpt) is handled by the rules
for sending the Join(*,G) or Join(*,*,RP).
It should say:
See notes.
Notes:
A reference to a page would be very helpful at the end of the event description in reference to the “rules for sending the Join(*,G) or Join(*,*,RP).”
Errata ID: 1175
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2013-11-03
Section 4.6.2 says:
It must not
forward packets for G onto interface I with the exception of
traffic from sources for which is has (S,G) "I am Assert Winner"
state.
It should say:
It must not
forward packets for G onto interface I with the exception of
traffic from sources for which it has (S,G) "I am Assert Winner"
state.
Notes:
Misspelling ("is" -> "it").
Errata ID: 1178
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.2 says:
See notes.
It should say:
See notes.
Notes:
The figure given on page 92 lists state changes which are “Assert Timer Expires”, “Receive Inferior Assert”, “Receive Preferred Assert”, and “CouldAssert(*,G,I) -> FALSE”, but the order given in the descriptions after the diagram on page 95 does not match this order.
Errata ID: 1179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.2 says:
A4: Send AssertCancel(*,G).
Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return their default
values).
A5: Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return their default
values).
It should say:
A4: Send AssertCancel(*,G).
Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default
values).
A5: Delete assert info (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default
values).
Notes:
Missing words.
Errata ID: 1180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.6.5 says:
In this case, it needs to ignore the assert state if it will win the assert once the SPTbit is set.
It should say:
In this case, it needs to ignore the assert state if it will win the assert once the SPT bit is set.
Notes:
Misspelling.
Errata ID: 1182
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9 says:
Type Types for specific PIM messages. PIM Types are:
It should say:
Type Types for specific PIM messages. PIM Types are:
Notes:
Spacing.
Errata ID: 1186
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o Combining a (*,G) Join and a (S,G,rpt) Join entry in the same
message is redundant as the (*,G) entry covers the information
provided by the (S,G,rpt) entry.
It should say:
o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
message is redundant as the (*,G) entry covers the information
provided by the (S,G,rpt) entry.
Notes:
Misspelling.
Errata ID: 1187
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.
It should say:
o The same applies for a (*,G) Prune and (S,G,rpt) Prunes.
Notes:
Misspelling.
Errata ID: 1188
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The combination of a (*,G) Prune and a (S,G,rpt) Join is also not
generated.
It should say:
o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
generated.
Notes:
Misspelling.
Errata ID: 1189
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o As Join/Prune messages are targeted to a single PIM neighbor,
including both a (S,G) Join and a (S,G,rpt) Prune in the same
message is usually redundant.
It should say:
o As Join/Prune messages are targeted to a single PIM neighbor,
including both an (S,G) Join and an (S,G,rpt) Prune in the same
message is usually redundant.
Notes:
Misspellings.
Errata ID: 1190
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 4.9.5.1 says:
o The combination of a (S,G) Prune and a (S,G,rpt) Join could
possibly be used by a router to switch from receiving a particular
source on the shortest-path tree back to receiving it on the shared
tree (provided that the RPF neighbor for the shortest-path and
shared trees is common). However, Sparse-Mode PIM does not provide
a mechanism for explicitly switching back to the shared tree.
It should say:
o The combination of an (S,G) Prune and an (S,G,rpt) Join could
possibly be used by a router to switch from receiving a particular
source on the shortest-path tree back to receiving it on the shared
tree (provided that the RPF neighbor for the shortest-path and
shared trees is common). However, Sparse-Mode PIM does not provide
a mechanism for explicitly switching back to the shared tree.
Notes:
Misspellings.
Errata ID: 1196
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2011-05-09
Section 6.3.2.1 says:
In this "single shared key" mode of operation, the network administrator must choose an SPI for each DR that will be used to send it PIM protocol packets.
It should say:
See notes.
Notes:
What does “it” refer to?
s/it/the/
Errata ID: 1197
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section 6.3.2.1 says:
The Security Policy Database at every DR is configured to select an SA (including the authentication algorithm, authentication parameters, and this SPI) when sending Register messages to this RP.
It should say:
The Security Policy Database at every DR is configured to select an SA (including the authentication algorithm, authentication parameters, and this SPI) when sending Register messages to an RP.
Notes:
Word choice.
Errata ID: 1199
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Date Held: 2009-08-26
Section 6.4 says:
There are a number of possible denial-of-service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating data false traffic.
It should say:
See notes.
Notes:
What does “or even by generating data false traffic” mean?
[Adrian Farrel] Clearly "or even by generating false data traffic."
Errata ID: 1202
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Held for Document Update by: Adrian Farrel
Section A.2 says:
o If the router receives a (S,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
It should say:
o If the router receives an (S,G) prune alert, it will need to set
DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
Notes:
Misspelling.
Errata ID: 2662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ang Way Chuang
Date Reported: 2010-12-08
Held for Document Update by: Adrian Farrel
Section 4.1.4 says:
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.2.
It should say:
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.3.
Notes:
Section 4.5.2 deals with (*,G) Join/Prune messages, not (S,G) Join/Prune messages.
Errata ID: 4027
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-06-26
Held for Document Update by: Alia Atlas
Date Held: 2014-07-01
Section 4.8.2 says:
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
}
oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist
It should say:
oiflist = NULL
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
}
oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist
Notes:
The followng line is missing:
oiflist = NULL
Without this, it may lead to accessing uninitialized variable
oiflist. This line is present in Section 4.2 from which the simplified
SSM specific pseudo code is derived.
Status: Rejected (16)
RFC 4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006
Note: This RFC has been obsoleted by RFC 7761
Source of RFC: pim (rtg)
Errata ID: 1099
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 7. Upstream (*,G) state machine ............................67
It should say:
Figure 7. Upstream (*,G) state machine .........................67-68
Notes:
Figure 1 occurs on pages 67-68, is listed as occurring on page 67.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1100
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 8. Upstream (S,G) state machine ............................71
It should say:
Figure 8. Upstream (S,G) state machine .........................72-73
Notes:
Figure 1 occurs on page 72-73, is listed as occurring on page 71.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1102
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 10. Per-interface (S,G) Assert State machine ...............84
It should say:
Figure 10. Per-interface (S,G) Assert State machine ............84-85
Notes:
Figure 1 occurs on pages 84-85, is listed as occurring on page 84.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1103
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section List of Figu says:
Figure 11. Per-interface (*,G) Assert State machine ...............92
It should say:
Figure 11. Per-interface (*,G) Assert State machine ............92-93
Notes:
Figure 1 occurs on pages 92-93, is listed as occurring on page 92.
--VERIFIER NOTES--
List of figures is like a table of contents and only needs to point to the first page on which the figure can be found.
Errata ID: 1120
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.2 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,G) | Prune(*,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,G) | | +------------++-------------+--------------+-------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,G) | Prune(*,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,G) | | +------------++-------------+--------------+-------------+-------------+
Notes:
In NoInfo state and in the Prune Pending state, upon receipt of the “Receive Prune(*,G)” event, there is an explicit state transition back to its own state. These seem redundant.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1125
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.7 says:
+----------------------------------------------------------------------+ | In Joined (J) State | +-----------------+-----------------+-----------------+----------------+ | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | | | RPF'(S,G) | +-----------------+-----------------+-----------------+----------------+ | Send | Increase Join | Decrease Join | Decrease Join | | Join(S,G); Set | Timer to | Timer to | Timer to | | Join Timer to | t_joinsuppress | t_override | t_override | | t_periodic | | | | +-----------------+-----------------+-----------------+----------------+
It should say:
+----------------------------------------------------------------------+ | In Joined (J) State | +-----------------+-----------------+-----------------+----------------+ | Event | Timer Expires | See Join(S,G) | See Prune(S,G) | | | | to RPF'(S,G) | to RPF'(S,G) | | | | | +-----------------+-----------------+-----------------+----------------+ | Action | Send | Increase Join | Decrease Join | | | Join(S,G); Set | Timer to | Timer to | | | Join Timer to | t_joinsuppress | t_override | | | t_periodic | | | +-----------------+-----------------+-----------------+----------------+
Notes:
The remaining portions would be inserted into the left portion of the remaining table on Page 73 and the two overflowing items in that table would go into a continuation beneath the table on Page 73.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1132
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.9 says:
All PIM control messages have IP protocol number 103.
It should say:
All PIM control messages have IP protocol number 103, per RFC 1700.
Notes:
The IP protocol assignment information is given without a reference to RFC 1700/STD 2.
--VERIFIER NOTES--
Per RFC 3232, RFC 1700 is replaced by an online database. A reference is no longer appropriate.
Errata ID: 1148
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.2 says:
# or Assert(*,G) message to be sent out interface iif.
It should say:
# or Assert(*,G) message to be sent out iif.
Notes:
“should be sent out interface iif” is redundant as “iif” stands for “incoming interface” and this expands to: “should be sent out interface incoming interface”, which is redundant.
--VERIFIER NOTES--
In this case "iif" is the identifier of an interface. It reads better as it is.
Errata ID: 1153
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.1 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+-------------+--------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,*,RP) | Prune | Pending | Expires | | || | (*,*,RP) | Timer | | | || | | Expires | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+-------------+--------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(*,*,RP) | Prune | Pending | Expires | | || | (*,*,RP) | Timer | | | || | | Expires | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+-------------+--------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune-| | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+-------------+--------------+-------------+ |Prune- ||-> J state | - | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(*,*,RP) | | +------------++-------------+-------------+--------------+-------------+
Notes:
At the intersection of “NoInfo (NI)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(*,*,RP)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1158
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.3 says:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(S,G) | Prune(S,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> NI state | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | -> PP state | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(S,G) | | +------------++-------------+--------------+-------------+-------------+
It should say:
+------------++--------------------------------------------------------+ | || Event | | ++-------------+--------------+-------------+-------------+ |Prev State ||Receive | Receive | Prune- | Expiry Timer| | ||Join(S,G) | Prune(S,G) | Pending | Expires | | || | | Timer | | | || | | Expires | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | - | - | - | |NoInfo (NI) ||start Expiry | | | | | ||Timer | | | | +------------++-------------+--------------+-------------+-------------+ | ||-> J state | -> PP state | - | -> NI state | |Join (J) ||restart | start Prune- | | | | ||Expiry Timer | Pending | | | | || | Timer | | | +------------++-------------+--------------+-------------+-------------+ |Prune- ||-> J state | - | -> NI state | -> NI state | |Pending (PP)||restart | | Send Prune- | | | ||Expiry Timer | | Echo(S,G) | | +------------++-------------+--------------+-------------+-------------+
Notes:
At the intersection of “NoInfo (NI)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “NI”, which is the current state – this is unnecessary. At the intersection of “PrunePending (PP)” and “ReceivePrune(S,G)” it is noted that there is a change of state to “PP”, which is the current state – this is unnecessary.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1171
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.5.9 says:
+----------------------------------------------------------------------+ | In NotPruned(S,G,rpt) State | +----------+--------------+--------------+--------------+--------------+ |Override | See Prune | See Join | See Prune | RPF' | |Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> | |expires | RPF' | RPF' | RPF' | RPF' (*,G) | | | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | | +----------+--------------+--------------+--------------+--------------+ |Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, | |(S,G,rpt);| t_override) | | t_override) | t_override) | |Leave OT | | | | | |unset | | | | | +----------+--------------+--------------+--------------+--------------+
It should say:
See notes
Notes:
The table at the bottom of page 78 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “NotPruned(S,G,rpt) State”.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1173
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.4 says:
+----------------------------------------------------------------------+ | In NoInfo (NI) State | +---------------+-------------------+------------------+---------------+ | Receive | Receive Assert | Data arrives | Receive | | Inferior | with RPTbit | from S to G on | Acceptable | | Assert with | set and | I and | Assert with | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | and | (S,G,I) | (S,G,I) | and AssTrDes | | CouldAssert | | | (S,G,I) | | (S,G,I) | | | | +---------------+-------------------+------------------+---------------+ | -> W state | -> W state | -> W state | -> L state | | [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] | +---------------+-------------------+------------------+---------------+ +----------------------------------------------------------------------+ | In I Am Assert Winner (W) State | +----------------+------------------+-----------------+----------------+ | Assert Timer | Receive | Receive | CouldAssert | | Expires | Inferior | Preferred | (S,G,I) -> | | | Assert | Assert | FALSE | +----------------+------------------+-----------------+----------------+ | -> W state | -> W state | -> L state | -> NI state | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | +----------------+------------------+-----------------+----------------+
It should say:
See notes.
Notes:
The tables at the bottom of page 84 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and “I AM Assert Winner” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1174
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.1 says:
+---------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +-------------+-------------+-------------+-------------+-------------+ |Receive |Receive |Receive |Assert Timer |Current | |Preferred |Acceptable |Inferior |Expires |Winner's | |Assert |Assert with |Assert or | |GenID | | |RPTbit clear |Assert | |Changes or | | |from Current |Cancel from | |NLT Expires | | |Winner |Current | | | | | |Winner | | | +-------------+-------------+-------------+-------------+-------------+ |-> L state |-> L state |-> NI state |-> NI state |-> NI state | |[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] | +-------------+-------------+-------------+-------------+-------------+ +----------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +----------------+-----------------+------------------+----------------+ | AssTrDes | my_metric -> | RPF_interface | Receive | | (S,G,I) -> | better than | (S) stops | Join(S,G) on | | FALSE | winner's | being I | interface I | | | metric | | | +----------------+-----------------+------------------+----------------+ | -> NI state | -> NI state | -> NI state | -> NI State | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | +----------------+-----------------+------------------+----------------+
It should say:
See notes.
Notes:
The table at the top of page 85 does not indicate what the rows are as opposed to the columns. It appears that the first row consists of events and the second row consists of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
It is perfectly possible to parse this with a basic knowledge of the protocol states and events.
Errata ID: 1176
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.2 says:
+----------------------------------------------------------------------+ | In NoInfo (NI) State | +-----------------------+-----------------------+----------------------+ | Receive Inferior | Data arrives for G | Receive Acceptable | | Assert with RPTbit | on I and | Assert with RPTbit | | set and | CouldAssert | set and AssTrDes | | CouldAssert(*,G,I) | (*,G,I) | (*,G,I) | +-----------------------+-----------------------+----------------------+ | -> W state | -> W state | -> L state | | [Actions A1] | [Actions A1] | [Actions A2] | +-----------------------+-----------------------+----------------------+ +---------------------------------------------------------------------+ | In I Am Assert Winner (W) State | +----------------+-----------------+-----------------+----------------+ | Assert Timer | Receive | Receive | CouldAssert | | Expires | Inferior | Preferred | (*,G,I) -> | | | Assert | Assert | FALSE | +----------------+-----------------+-----------------+----------------+ | -> W state | -> W state | -> L state | -> NI state | | [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] | +----------------+-----------------+-----------------+----------------+
It should say:
See notes.
Notes:
The tables at the bottom of page 92 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “NoInfo” state and the “I Am Assert Winner” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.
Errata ID: 1177
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.6.2 says:
+---------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +-------------+-------------+-------------+-------------+-------------+ |Receive |Receive |Receive |Assert Timer |Current | |Preferred |Acceptable |Inferior |Expires |Winner's | |Assert with |Assert from |Assert or | |GenID | |RPTbit set |Current |Assert | |Changes or | | |Winner with |Cancel from | |NLT Expires | | |RPTbit set |Current | | | | | |Winner | | | +-------------+-------------+-------------+-------------+-------------+ |-> L state |-> L state |-> NI state |-> NI state |-> NI state | |[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] | +-------------+-------------+-------------+-------------+-------------+ +----------------------------------------------------------------------+ | In I Am Assert Loser (L) State | +----------------+----------------+-----------------+------------------+ | AssTrDes | my_metric -> | RPF_interface | Receive | | (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) or | | FALSE | Winner's | being I | Join | | | metric | | (*,*,RP(G)) on | | | | | Interface I | +----------------+----------------+-----------------+------------------+ | -> NI state | -> NI state | -> NI state | -> NI State | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | +----------------+----------------+-----------------+------------------+
It should say:
See notes.
Notes:
The tables at the top of page 93 do not indicate what the rows are as opposed to the columns. It appears that the first rows consist of events and the second rows consist of actions to take upon receiving those events while in the “I Am Assert Loser” state.
--VERIFIER NOTES--
This is perfectly easy to parse having an understanding of the states and events for the protocol.
Errata ID: 1191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Maren Peasley
Date Reported: 2007-12-21
Rejected by: Adrian Farrel
Date Rejected: 2009-08-26
Section 4.9.5.2 says:
On a router with a large amount of multicast state,
It should say:
On a router with a large amount of multicast states, -or- On a router with a large amount of multicast state information, -or- On a router with a large multicast state,
Notes:
Word choice.
--VERIFIER NOTES--
This is common usage.
"state information" might have been clearer, but "state" is acceptable.