Subject: [pim] Discussion on some RFC4601 errata

From: Bill Fenner <[email-masked]>
Date: Wed, 24 Mar 2010 18:44:49 +0000

I picked through the errata and pulled out a handful of ones that
don't appear to be just typographical.

----
Errata ID: 1121

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.

---

A single Prune(S,G,rpt) does not stop forwarding.  A single
Prune(S,G,rpt) moves you to Prune-Pending, which "functions exactly
like the NoInfo state", meaning that forwarding continues.  The
neighbor who wants forwarding to continue sends a Prune-Override (a
*,G join) within 2.5 seconds; the upstream router does not exit
PrunePending into Pruned until after the 2.5 seconds.  I think this
errata should be rejected, as the premise is incorrect.

---
Errata ID: 1159

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

No, an (S,G) join has no effect on (S,G,rpt) state.  This is one of
the significant simplifications of RFC4601.  If there is an (S,G)
join, then the presence of (S,G,rpt) state is irrelevant, because the
forwarding state is (roughly)   (*,G) - (S,G,rpt) + (S,G) -- so the
(S,G,rpt) state is subtracted from the (*,G) state, but if the
interface is in the (S,G) state it will be added back again.  I think
this errata should be rejected (or accepted as a request for
clarification that (S,G) state and (S,G,rpt) state are completely
independent)

---
Errata ID: 1160

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

I am not sure I quite understand the problem.  If you have two
downstream routers, and one is sending (*,G) joins and the other is
sending (*,G) joins and (S,G,rpt) prunes, then the upstream router
will move between NI->PP->PP'->NI and never enter P.  This is the
correct behavior, since the router that is sending (*,G) joins without
(S,G,rpt) prunes is asserting that it wants to receive traffic from
(S,G) on the RP-tree.

Unless the problem being described is something different, I think
this errata should be rejected; the behavior described is the correct
behavior.

---
Errata ID: 1166

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

I hate changes like this.  The document says "If the state is foo,
then you do bar."  Why should we also say "If the state is not foo,
then you do nothing."?  Should we mention that you don't change your
IP address on reception of a malformed PIM packet, or you don't send a
(*,G) Join when your knee itches?  What other things that you don't do
should we mention?

---
Errata ID: 1168

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?
---

I don't understand the question.  The SPTbit being true means we're on
the source tree, and the SPTbit being false means we're on the shared
tree.  So we think we are on the shared tree if the SPTbit is false
because that's what it means.

---
Errata ID: 1169

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?
---

If there are 200 routers that want (*,G), and one who sends a
(S,G,rpt) prune, we don't want the upstream to get 200 prune-override
messages simultaneously.  "implosion" is a commonly used term for this
problem (see, e.g., "Ack implosion" when talking about reliable
multicast), so we used it.

---
Errata ID: 1193

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

They are ignored (not sent).  This is a fine clarification to make.

---

Any discussion on my interpretation of these issues?  Is the errata
reporter (Maren Peasley) on this list?

  Bill