Subject: [pim] A Query about the forwarding pseudocode in draft-ietf-pim-sm-v2-n ew-05.txt

From: "Bandi, Sarveshwar" <[email-masked]>
Date: Thu, 26 Sep 2002 09:48:10 -0400

Hi All,
    I am new to the pim draft so please excuse me if my question does not
make sense. The forwarding pseudocode (section 4.2)  in the draft works in a
way that the list of outgoing interfaces are calculated on "receipt of data
from S to G on Interface iif" and the data is forwarded on these outgoing
interfaces. In reality the outgoing interfaces list evolves incrementally as
and when we receive (*,G) or (S/G) join prunes. For ex. if we receive a
Join(*,G) on an oif, then an fwding entry can be made (*,g, iif, oif) into
the forwarder (ofcourse provided oif satisfies other conditions like not
having lost an assert etc.) The data would be forwarded based on this entry
and list of other control plane related actions will be performed (sending
asserts/resetting keepalive timer/checkin switch to spt). Obviously  it
would be a slow process to calculate the list of outgoing interfaces as and
when data packets arrive.

So Could we perceive the forwarding pseudocode as, When we receive
Join/Prune on an oif, we try to evaluvate if this oif qualifies to be added
or removed from an existing outgoing interfaces list???

A related question. Consider the macro 
immediate_olist(*,G) = Joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)

If we have interfaces I1, I2 .... In
Could we express the macro as
Immediate_olist(*,G) =
(include I1 if ( ( DownStreamJPState(*,G,I1) is Join or PrunePending ) OR
                    ( I1 is in pim_include(*,G)) AND
                    ( lost_assert(*,G,I1)  != TRUE) )
(+)
(include I2 if ( ( DownStreamJPState(*,G,I2) is Join or PrunePending ) OR
                    ( I2 is in pim_include(*,G)) AND
                    ( lost_assert(*,G,I2)  != TRUE) )
.
.
.
.
(+)
(include In if ( ( DownStreamJPState(*,G,In) is Join or PrunePending ) OR
                    ( In is in pim_include(*,G)) AND
                    ( lost_assert(*,G,In)  != TRUE) )

What I am trying to do is evaluvate each interface to check if it qualifes
as an oif. This way one wouldnt need to worry about the states of other
Interface state machines and just add/remove an interface from the outgoing
interface list individually based on Join/Prune received on this interface.

Thanks in advance for your suggestions and comments.

Regards,
Sarvesh

Sarveshwar Bandi

Member, Technical Staff
Netplane Network Technologies (India) Pvt. Ltd.
http://www.netplane.com
Ph: +91-40-355 3709/10/11/12 Extn: 1126
Fax: +91-40-355 3713

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 26 Sep 2002 12:26:51 -0700

> when data packets arrive.

True. The purpose of the spec is to specify the correct behavior,
and then it is up to the implementation to make it efficient.

> or removed from an existing outgoing interfaces list???

Yes. However, you should be careful that other events may also
impact the oif list. For example, the following list of
pseudo-coded names may have impact on the iif and/or oif list. The
list is for generalized illustrative purpose only:

RP_CHANGED
MRIB_RP_CHANGED
MRIB_S_CHANGED
RECEIVE_PRUNE_WC
RECEIVE_PRUNE_SG
DOWNSTREAM_JP_STATE_RP
DOWNSTREAM_JP_STATE_WC
DOWNSTREAM_JP_STATE_SG
DOWNSTREAM_JP_STATE_SG_RPT
UPSTREAM_JP_STATE_SG
LOCAL_RECEIVER_INCLUDE_WC
LOCAL_RECEIVER_INCLUDE_SG
LOCAL_RECEIVER_EXCLUDE_SG
ASSERT_STATE_WC
ASSERT_STATE_SG
I_AM_DR
MY_IP_ADDRESS
IS_SWITCH_TO_SPT_DESIRED_SG
SPTBIT_SG

> interface list individually based on Join/Prune received on this interface.

Absolutely! FYI, if you represent various states as bitsets (one bit
per interface), then you can perform the evaluation for all
interfaces in parallel by AND/OR/etc the bitsets.
One thing you need to be careful is to consider all the impact an
event such as receiving of a J/P message or change of DR may have on
each state, and then recompute all other states that may depend on
it. Things may look complicated, but if you follow the macros in the
spec, and consider where each macro is used, everything falls very
nicely into its place.
Well, if you try to track all macro and state dependency by hand, it
may be difficult and error-prone, so you if you get tired you can
try to write a program to perform those dependencies automatically
for you :)

Regards,
Pavlin