Re: [pim] PIM (S,G,rpt) prune group set fragmentation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] PIM (S,G,rpt) prune group set fragmentation



hoerdt at clarinet.u-strasbg.fr initiated a hyperspace jump with:
> Hello,
> 
> In the latest PIM draft specification, section 4.9.5.2,
> it is stated :
> 
> "There is an exception with group sets that contain a (*,G) Join source
> list entry. The group set expresses the router's interest in receiving
> all traffic for the specified group on the shared tree and it MUST
> include an (S,G,rpt) Prune source list entry for every source that the
> router does not wish to receive. This list of (S,G,rpt) Prune source-
> list entries MUST not be split in multiple messages.
> 
> 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."
> 
> I don't understand why prune (S,G,Rpt) messages are not split into
> multiple messages. It means that if there is more that N sources in 
> a group, the PIM SPT switch will generate duplicated trafic on the
> shared tree.
> 
> Do someone have an explanation about this ?


As the S,G,RPT prune fsm is designed it would cause the S,Gs in the
later message to thrash between pruned and no info. When a (*,G) join is
encountered S,G,RPT fsms are put into the prune tmp state. Then each
S,G,RPT prune encountered in the message transitions the fsm back to 
pruned. When the end of the message is reached any S,G,RPT fsm that is
still in the prune tmp state is transitioned to no info.

This is nessary because S,G,RPT joins (which are only ever triggered) were
not designed with robustness. Therefore, the periodic state is used to
refresh this.

Chris

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.