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

Fri Feb 16 15:42:45 PST 2007

>        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).

I assume there will be a PimNode that will have its flag "is_bidir"
flag set to true or false. Most of the existing code inside PimNode
won't be modified. Only where the PIM-SM and PIM-Bidir processing is
different, the "is_bidir()" method can be used to differentiate
between them.

The implementation details can be different from what I describe
above, but I don't see the reason for duplicating most of the stuff
from PimNode to PimBidirNode. Also, have in mind that the is_bidir
flag might be changed on-the-fly (via xorpsh), so your code needs to
take this into account.

>        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 ?

In the future we would like to run multiple protocol instances (or
even XORP instances), but we are not there yet.

>         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
> configuration,etc !!

Just same pimsm4.tp with enable-bidir flag in it. Changing this flag
(e.g., via xorpsh) will invoke the appropriate XRL that will change
the "is_bidir" flag inside PimNode.

Regards,
Pavlin

> Thank you,
> Ashish
> 
> 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:
> >
> > 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
> >
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers