Subject: Using Asserts to remove redundant P2P links in PIM-DM

From: Bill Fenner <[email-masked]>
Date: Tue, 17 Nov 1998 15:09:15 PST

There are two ways to look at the PIM-DM architecture.  Please help
me to flesh out the list of advantages and disadvantages.  I realize
that the advantages and disadvantages are opinions, and that people
will have opinions on my opinions; for now let's put off discussion
of the weight that we give to each advantage/disadvantage and just
work on building the list.

1) Use Prune messages to remove links from the RPF DAG to build the
broadcast tree.  Since Prune messages aren't sufficient on multi-access
LANs, design the ugly Assert mechanism to handle multi-access LANs.
Use Prune messages to remove links from the broadcast tree.

Advantages:
- Prune messages are shorter
- This is what's currently implemented

Disadvantages:
- Prune messages have two purposes, one of which duplicates the purpose
  of Assert messages
- Debugging the network is harder; when a link is pruned, you don't
  know if it was pruned because if was not part of the broadcast tree
  or because it was not part of the multicast tree.  This could cause
  confusion when debugging the network (e.g. "Why is this link pruned?
  I know there are group members beyond the neighboring router!")

2) Use Assert messages to remove links from the RPF DAG to build the
broadcast tree.  Use Prune messages to remove links from the broadcast
tree.

Advantages:
- Easier to understand - each message has its purpose
- Forwarder election works on a redundant P2P link with a group member
  on one or the other end.  (Yes, routers may be group members on P2P
  links and the distribution tree should end in a leaf that is the P2P
  link.)

Disadvantages:
- Assert processing may be more expensive in some implementations

The second advantage of #2 is fairly subtle, but has to do with the
model in which applications running on a router can expect to work the
same as running on a multi-homed host that's attached to the same set
of links as the router.  Some routers seem to use a slightly different
model where the router uses the multicast routing protocol to ensure
that traffic arrives at the router for groups of which the router is a
member.  This is an implementation decision; implementing the first
model should not be precluded by the multicast routing protocol.

I think the reason that I like #2 is because I think that there's a
real difference between a link over which no traffic would flow whether
or not there were group members downstream and one over which traffic
would flow if there were group members downstream.

  Bill

---

From: Liming Wei <[email-masked]>
Date: Tue, 17 Nov 1998 21:06:42 -0800 (PST)

Bill,

Now, that is a verifiable form of opinions.

It is evident that when one is intimately involved with DVMRP, there
is a tendancy to cast PIM-DM concepts/mechanisms into DVMRP, and to
assume they are the same. And an unfamiliar thing is found ugly..

> From: Bill Fenner <[email-masked]>
> Date: Tue, 17 Nov 1998 15:09:15 PST
> 

Not sure what two purposes you are referring to.

The current spec clearly specifies that assert messages are only sent
on multi access LANs and not on point-to-point links.

>   I know there are group members beyond the neighboring router!")

Again, this is more complicated thinking than necessary for PIM-DM.
This is not DVMRP! In your example, even if assert state is provided,
it does not give "parent-child" relationship information.  A
PIM-DM debugger will will rely on RPF information to answer your
question. So this is NOT a disadvantage for using prunes either.

Also a bit of history for everyone, in the early days of PIM-DM
design, Charley used to call an assert a "soft prune".  In other
words, assert is a prune, but softer and which carries more
information related to the prune.

> - Easier to understand - each message has its purpose

Please do give more details on what it means by "use assert messages
to remove links". It has too many interpertations. By default,
I think you mean applying the current assert mechanism on p2p links.
[if not please specify.]

>   links and the distribution tree should end in a leaf that is the P2P

Does it not work if that message is called a prune ? How can this be
an advantage ?

> - Assert processing may be more expensive in some implementations

Just to let people know that in the implementation I'm familiar with,
this is an zero effort change. But the degradation will be universal
to all implementations, without "assert optimizations".

Please add the following to the disadvantages of using the currently
canned "assert":

  - Assert process mandates 3 seconds delay before the winning p2p
    interface can be pruned, resulting in more unnecessary flooded
    traffic;
  - Comparing metrics/metric preferences in such scenario is pointless.

If you do have an "optimized" version of assert for p2p, please
also add an disadvantage for this:
  - Added special Assert processing rules for p2p interafce only;
  - Complicated design, more difficult to understand.

> would flow if there were group members downstream.

I don't think this buys anything for the local member scenario.  You
probably mean a box with local member may still WANT to receive
packets over a p2p link, even though itself is a forwarder too.  By
doing that the box's member would have to not get packets from its RPF
interface it forwards for other links, but to accept packets from the
non-RPF p2p link because the other end of the p2p link is officially
forwarding to the link. I can't think of any reason why this is
desirable, not to say unconditionally advantageous (or subtly).

Finally, I appreciate your attempt to formulate this, which allowed me
a chance to target my arguments more pertinently.

-Liming

---

From: Bill Fenner <[email-masked]>
Date: Wed, 18 Nov 1998 00:38:21 PST

>Not sure what two purposes you are referring to.

1. Removing (some) links from the RPF DAG to form the broadcast tree
2. Removing links from the broadcast tree to form the multicast tree

The other way to look at it is that prunes remove links from the RPF DAG
to form the multicast tree, except that prunes don't work for that purpose
on multi-access LANs so asserts are used.

Whichever one eventually falls out of this discussion should be more
completely documented in the spec, especially the part about the initial
distribution tree being the RPF DAG.

>I think you mean applying the current assert mechanism on p2p links.

Yes, the current mechanism, with an optimization for 2-router
networks (which applies to both prunes and asserts).

>Does it not work if that message is called a prune ? How can this be

Scenario:

           S
           |
      ------------
       /        \
      Z          \
     /            \
    A ------------ B

A is a group member on the A<>B P2P link.  (i.e. A sends IGMP group
membership reports).  A would normally send a prune on the P2P
link, but B still needs to forward packets from S because of the
group member.  However, A shouldn't forward packets from S because
of the group member.  You can use an Assert to elect B as the
forwarder on the link.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 18 Nov 1998 11:46:21 PST

Let me try to phrase it yet another way.  Ignore the evolution of the
protocol and look at what it is today.

Look at multi-access LANs.  We see extra packets flowing due to RPF.
PIM resolves those extra copies via Asserts.  Then all of the
downstream members go away, and we see PIM prune off the tree with
Prunes.

Now look at point-to-point links.  Abstractly, there's no particular
reason that a P2P link needs to look any different than a 2-router
multi-access LAN.  However, when we see extra packets flowing due to
RPF on a P2P link, PIM resolves the extra packets via Prunes.  When all
of the downstream members go away, PIM prunes off the tree with
Prunes.

This is what I mean by saying that Prunes serve 2 different purposes on
P2P links, one of which replicates the purpose of Asserts.

  Bill

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Nov 1998 15:10:16 -0500

Well said Bill.

I see it clearly as an upstream vs. downstream issue.
You send prunes upstream and you send asserts downstream.
The link type is irrelevant.

Tom

---

From: Liming Wei <[email-masked]>
Date: Wed, 18 Nov 1998 12:30:30 -0800 (PST)

> Date: Wed, 18 Nov 1998 15:10:16 -0500
> From: Tom Pusateri <[email-masked]>
> 
> Well said Bill.
> 

Aren't you contradicting Ravi and Bill by saying that link type is
irrelevant. If it is irrevalent why did they all say assert needs to
be changed for p2p links ?

-Liming

---

From: Liming Wei <[email-masked]>
Date: Wed, 18 Nov 1998 12:28:56 -0800 (PST)

> P2P links, one of which replicates the purpose of Asserts.

Ok, I'll buy that this could be idealisticly soothing from that
angle, and ONLY from that angle.

-Liming

---

From: Bill Fenner <[email-masked]>
Date: Wed, 18 Nov 1998 14:06:40 PST

In message <[email-masked]> you write:
>...why did they all say assert needs to

I don't think assert needs to be changed for p2p links.  I think both
assert and prune need to be changed for 2-router links.  (i.e. the
spec says "do this different prune behavior on p2p links", when it
should really say "do this different prune behavior on links with only
2 routers present").

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 18 Nov 1998 14:05:08 PST

>angle, and ONLY from that angle.

But for people who are first approaching PIM and trying to understand
it, as opposed to those who have been working on it for years, such
consistency may be important to aid understanding.

The reason that the current protocol seems natural to you is because
you were involved with it as it grew up.  Try stepping back and
looking at it from the other end, ignoring what you already know
about it.

  Bill