[Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries.
ashishkarpe at gmail.com
Fri Feb 16 14:04:32 PST 2007
Thank you very much for showing us proper path & correcting us !!
bty i have doubt about what do you really mean by routing
instance !! Is it that there will be PimBidirNode which will keep all
information ( about routing table , Vifs belonging to routing tables
,routing option configuration,etc).
Is there any condition where multiple instances of same
protocol (say PIM-SM) may exists on same router ? or Routing instance
per PIM-SM means per router in domain ?
Then now do we have to make completely new pimbidir4.tp file &
PimBidirNode & implitment completely separate Bidir module which can
inherit common functionality from PIM-SM :) ........... OR just use
same pimsm4.tp & enable bidir flag in it (i.e Per PimSM instance ) &
thn enable/call new/separate BidirNode from it which will maintain it
own routing table , Vifs belonging to routing tables ,routing option
On 2/16/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > 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:
> 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  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 , a bidir capable router forwarding upstream, register
> encapsulates the data packet to the RP if its RPF neighbor is not bidir
> 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 , 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:
> I couldn't find anything about PIM-Bidir in the Juniper
> > 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)  or Auto-RP.
> Hence, each (*,G) entry needs to have a flag indicating whether it
> is in PIM-SM mode or PIM-Bidir mode.
More information about the Xorp-hackers