Subject: Re: PIM-DM mask in prune/join

From: Bill Fenner <[email-masked]>
Date: Thu, 7 Jan 1999 17:44:27 PST

It's not clear where it's safe to use non-/32 netmasks.  Here's a scenario
where it can cause a black hole:

  10.0.0/24            10/8
    |                    |
    A ------------------ B
    |                    |
    |                    |
    |                    |
    |                    |metric 2
    |                    |
    |                    |  |
    C ------------------ D -|
    |                       | grp member on LAN
--------
no group members

So source X, 10.1.2.3, beyond router B, starts sending.  D RPF's to
B, C RPF's to A.
1. C and D send prunes to each other on the C<>D link for 10/8
2. C sends a prune for 10/8 to A
3. A sends a prune for 10/8 to B

Now if a source 10.0.0.1, whose traffic should travel A->C->D,
starts sending, it won't get anywhere because of the 10/8 prune.

If all routers were aware of the whole routing table, it might be
possible to do weird things like prune 10/8 and join 10.0.0/24 and have
special semantics for that type of prune+join.  But C and B might have
aggregated towards D so that D doesn't even know about the existence of
10.0.0/24.

  Bill

---

From: [email-masked] (Ravi Shekhar)
Date: Thu, 7 Jan 1999 22:00:08 -0500 (EST)

>where it can cause a black hole:

    That's an interesting example. 
    From a view limited to this case, looks like the problem is occuring 
    because of lack of distinction between two types of prunes:
      1) one generated because router is not interested in data and
      2) the other generated because upstream router is not the RPF nbr.

    This case should work out correctly for DVMRP. Because of downstream 
    dependency created through routing table exchange, there is no need 
    for a router to send a prune towards non-RPF upstream nbr(the second 
    type). In this case the prune sent by D towards C for 10/8. 

        If there had been a mechanism in PIM-DM for C to identify that 
    the prune igenerated by D is because its not D's RPF for 10/8, it 
    could have pruned 10/8 but not 10.0.0/24.

    Perhaps another point to be added to Radia's list of differences for
    PIM-DM and DVMRP.

    - Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 7 Jan 1999 20:16:02 PST

>    could have pruned 10/8 but not 10.0.0/24.

For which we'd have to invent a new message (well, a prune and a
join in the same packet might work, but we'd have to specify the
exact semantics).  Plus, if there were 50 10.x.x subnet routes,
the prune for 10/8 would have to list all of the excluded routes -
better, in that situation, to prune the /32.

  Bill

---

From: [email-masked] (Ravi Shekhar)
Date: Fri, 8 Jan 1999 15:31:24 -0500 (EST)

>exact semantics).  Plus, if there were 50 10.x.x subnet routes,
    
    I meant the same outcome, but without a need to include all 
    those 50 10.x.x.x subnet. That is prune is activated only 
    for traffic whose best match is 10/8. If it matches anything 
    else (one of those 50), it should not be pruned. Probably this 
    can be specified with just a bit in the prune message. Will 
    that work?

        Actually, if we use asserts (instead of prunes as stated in
    the original mail) for PtoP link between C and D in your example, 
    it can be deduced that pruning is happening for a non-tree link 
    and hence should only be applied to 10/8 and not more specifics 
    of it.
    One more reason why assert might be better for PtoP links as 
    opposed to prune.

>better, in that situation, to prune the /32.
    
    Thats true. But it will become worst once there are more than 50 
    hosts sending data from 10/8 subnet.

    - Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Fri, 8 Jan 1999 14:26:43 PST

>    can be specified with just a bit in the prune message. Will 

No, because you don't know that the routing table is the same between
the two routers.  This is one of the fundamental things that causes
things to be easy in DVMRP and hard in PIM-DM.

>    and hence should only be applied to 10/8 and not more specifics 

Asserts don't have netmasks...

  Bill