[Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries.

[Pavlin Radoslavov]

> hi all,
> we are implementing the PIM-Bidir in Xorp.we have decided to implement
> bidir-flag per vif as suggested by Pavlin Sir in his last reply.

To clarify: I didn't suggest that the flag has to be per vif, but
let you decide that :)
I intentionally didn't recommend whether the flag to be per vif or
per PIM instance, because it has been a while since I read the
PIM-Bidir spec and didn't remember what the spec said about
incremental PIM-Bidir deployment.

Anyway, I just had a quick look in the latest PIM-Bidir spec
(draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec
allows incremental PIM-Bidir deployment. The following email from
one of the PIM-Bidir spec authors confirms that:

http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html

Actually, an earlier version of the PIM-Bidir spec
(draft-ietf-pim-bidir-04.txt) had a section about incremental
deployment, but this has been removed in -05:

====================================================
5.2.  Appendix B: Interoperability with legacy code

The rules provided in [10] for interoperating between legacy PIM-SM
routers and new bi-directional capable routers change only slightly to
support this new proposal. The only difference is in the definition of a
boundary between a bi-directional capable area and a legacy area of the
network.  In [10], a bidir capable router forwarding upstream, register
encapsulates the data packet to the RP if its RPF neighbor is not bidir
capable.

In our proposal, since all the routers on a link need to co-operate to
elect the Designated Forwarder, if even one of the routers on the link
is a legacy router, the election cannot take place. As a result register
encapsulation is necessary if one or more routers on the RPF interface
are not bi-directional capable.

As in [10], a Hello option must be used to differentiate between bi-
directional capable and legacy routers, and (S,G) state must be created
on the router doing the register encapsulation to prevent loops.
====================================================

The newer model seems to be that each multicast group is forwarded
in PIM-SM or PIM-Bidir mode (see below).

This suggests that a PIM router has to run in PIM-Bidir mode on all
interfaces (or no interfaces), hence it makes more sence to have a
single bidir-mode flag per PIM instance.
It also seems consistent with the Cisco's "ip pim bidir-enable"
configuration per PIM instance:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html

I couldn't find anything about PIM-Bidir in the Juniper
documentation.

> For bidir mode we have to store only (*,G) entries.So after studying
> the following classes
> 
> 1.PimMre  (Pim_Mre.hh),
> 2.PimMribtable (Pim_Mrib_table),
> 3.PimMrt.
> 
> Now as we are implementing the pim_bidir flag per "vif" then that
> perticular vif can be used for forwarding both type of packets i.e.
> pim sm and bidir.
> 
> Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for the SM
> But as we are using same vif for both we need to know weather these
> entries are same for both?  If they differ then How can we
> differentiate between them.?

Section "4.  RP Discovery" in the PIM-Bidir spec
(draft-ietf-pim-bidir-08.txt) says:

====================================================
4.  RP Discovery

Routers discover that a range of multicast group addresses operates in
bi-directional mode and the address of the Rendezvous-Point address
(RPA) serving the group range either through static configuration or
using an automatic RP discovery mechanism like the PIM Bootstrap
mechanism (BSR) [9] or Auto-RP.
====================================================

Hence, each (*,G) entry needs to have a flag indicating whether it
is in PIM-SM mode or PIM-Bidir mode.

Regards,
Pavlin