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

From: [email-masked] (Ravi Shekhar)
Date: Thu, 7 Jan 1999 19:11:39 -0500 (EST)

>
>    Do PIM_DM implementations handle(send/recv) join_prune packets with 
>     - multiple sources/groups in the same packet.
>     - src mask length less than 32.
>

    I did not recv any mails supporting this.
    So can it be safely assumed that PIMDM join_prunes dont have any of 
    these two things?

    I would appreciate any input from the implementors/authors or if 
    someone knows of something contrary to this.

    Any views on whether this could be made a requirement for PIM-DM.

    Thanks.
     - Ravi Shekhar.

---

From: [email-masked]
Date: Thu, 7 Jan 1999 16:35:27 -0800 (PST)

>     someone knows of something contrary to this.

well i don't know for sure, and i haven't taken the time to read Kurt
W's. pimdm code (that is accessable, if you care to).  but if it's
similar to my pim-sm code the answers would be.

> >     - multiple sources/groups in the same packet.

yes

> >     - src mask length less than 32.

no.  actually the (gated-5.0) code and mcast route tables can
currently handle any size mask, i think i just reject any entry that
is not /32. 

>     Any views on whether this could be made a requirement for PIM-DM.

i *believe* it is already required to handle multiple sources/groups.
however, masks that are not /32, i believe can be quite problematic,
e.g. how do you aggregate multicast traffic.

i don't know that this helps...
-rusty

---

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

You asked about implementations in your first message, so I didn't

>    So can it be safely assumed that PIMDM join_prunes dont have any of 

The PIM-DM spec defers to the PIM-SM spec for packet formats; the PIM-SM
spec allows for both of them (but recommends against using anything but
/32 source mask with PIMv2 over IPv4).

  Bill

---

From: [email-masked] (Ravi Shekhar)
Date: Thu, 7 Jan 1999 20:06:56 -0500 (EST)

>> >     - multiple sources/groups in the same packet.

    I briefly looked at the PIMDM code available from USC PIM page. Looks 
    like it is calling pim_send with only one source always.

>e.g. how do you aggregate multicast traffic.

    I agree it will be difficult. But something like how DVMRP handles 
    subnet prunes is possible. Especially if there is mask in the message, 
    it can be clearly specified what mask downstream intends prune to be 
    active for. 

    - Ravi Shekhar.

---

From: [email-masked] (Ravi Shekhar)
Date: Thu, 7 Jan 1999 20:20:55 -0500 (EST)

>/32 source mask with PIMv2 over IPv4).

    I havent given enough thought to this, but this recommendation kind of 
    suits well for PIM-SM as mostly prunes will be originated when there is 
    a switch to source tree involved. 
        On the other hand, in case of PIM-DM, prunes will be mostly originated 
    by the leaf routers if there arent any local group memberships. For IGMPv2
    this is not source specific. So it would be more appealing to delete the 
    whole subnet.

        But I certainly like /32s as far as implementing it is concerned.. ;)
    Would have to handle non-/32s if someone was sending it.

    - Ravi Shekhar.

---

From: [email-masked]
Date: Thu, 7 Jan 1999 17:25:15 -0800 (PST)

>     like it is calling pim_send with only one source always.

ok, i didn't know if you were speaking of send or recieving.  i don't
think that you should make a requirement that all group/sources are
compiled into an outgoing message (the pim-sm spec suggests (but not
requires))  that you do for periodic J/P.

however, it is an implied requirement to be able to handle
multiple group/sources for incoming packets.  i just looked at Kurt's 
pimdm_graft_recv() and he does indeed read multiple groups with
multiple sources...

>     it can be clearly specified what mask downstream intends prune to be 

are dvmrp subnet prunes the same subnet as those passed by it's
unicast routing protocol?  with pim relying on *some* unicast routing
protocol with possible aggregates, etc, it seems like a faulty
scenario could be easy to (unwittingly) come up with.  also if you
allow groups to be aggregated this becomes even more problematic...

- rusty

---

From: [email-masked]
Date: Thu, 7 Jan 1999 17:37:06 -0800 (PST)

>> >     - multiple sources/groups in the same packet.

My PIMDM implementations will support multiple (S,G)s in a single
received Join/Prune message but will never send such a packet itself.

> currently handle any size mask, i think i just reject any entry that

Rusty is correct.  My implementations only handle /32 source and group
addresses.

---------------------------------------------------------------------------
Kurt Windisch
Internet Engineering Group, LLC                              [email-masked]
Univ. Oregon - Advanced Network Technolgy Center     [email-masked]
ph 541-346-1698   ---  fax 541-346-4397  ---  http://ns.uoregon.edu/~kurtw/
PGP fingerprint: 33 2A 7E 38 24 36 03 11  DB BF 22 DA C4 28 CC 23

---

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

>ok, i didn't know if you were speaking of send or recieving.  i don't

    I was writing recv. So I wanted to see what other implementations are 
    sending. Especially for prunes which are data triggered in PIMDM, it 
    would not be straightforward to put multiple of those in one packet. 
    But I guess you are right. I should just handle it on the recv side. 
    Thanks for the input.

>unicast routing protocol?  
    
    Used to be like that earlier. But now there is an extra source network
    mask field present in the message.

    - Ravi Shekhar.