errata logo graphic

Found 114 records.

Status: Verified (3)

RFC4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Source of RFC: pim (rtg)

Errata ID: 44

Status: Verified
Type: Technical

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

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

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)

RFC4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Source of RFC: pim (rtg)

Errata ID: 1104

Status: Held for Document Update
Type: Technical

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

RFC4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", August 2006

Source of RFC: pim (rtg)

Errata ID: 1099

Status: Rejected
Type: Editorial

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.


Report New Errata