Subject: [pim] Some questions on PIM-DM RFC 3973

From: Bharat Joshi <[email-masked]>
Date: Thu, 3 Nov 2011 17:55:14 +0530

Hi,

      I was going through the PIM-DM RFC and have got some questions. I tried to search net for some of them but did not find a satisfactory answer and so decided to send a mail on this mailing list.

     Here is the list:

• In section 4.4.1, in following text:

     Forwarding (F)
       This is the starting state of the Upsteam(S,G) state machine.
       The state machine is in this state if it just started or if
       oiflist(S,G) != NULL.

oiflist(S,G) is not defined. I think 'olist(S,G)' should have been used here.

• In section 4.4.1, in tabular form, following row:

+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND     | ->AP Send  | ->AP Send  |->AP Send   |
| olist(S,G) != NULL            | Graft(S,G) | Graft(S,G) | Graft(S,G) |
|                                           |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)|
+-------------------------------+------------+------------+------------+

In case of forwarding state, should not we send a Prune to the older next-hop as well?

In case of Pruned state, should not we cancel PLT(S,G)? BTW, in case olist(S,G) is non-NULL, can it really have Pruned state?

• In section 4.4.1, in tabular form, following row:

+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND     | ->P        | ->P Cancel |->P Cancel  |
| olist(S,G) == NULL           |            |  PLT(S,G)  |  GRT(S,G)  |
+-------------------------------+------------+------------+------------+

How will it be in Forwarding and AckPending state if olist(S,G) is NULL? Also in case of Pruned state, why to cancel the PLT? Should not we send a prune message to new next-hop and let this continue to run?

• In following case:

+-------------------------------+------------+------------+------------+
| OT(S,G) Expires               | ->F Send   | N/A        |->AP Send   |
|                                            |  Join(S,G) |            |  Join(S,G) |
+-------------------------------+------------+------------+------------+

In ackPending state, we send a join(S,G) but remains in AckPending state. In another case:

+-------------------------------+------------+------------+------------+
| State Refresh(S,G) received  | ->F        | ->P Send   |->F Cancel  |
| from RPF`(S) AND                  |            | Prune(S,G) |  GRT(S,G)  |
| Prune Indicator == 0 AND      |            |Set PLT(S,G)|            |
| PLT(S,G) not running              |            |            |            |
+-------------------------------+------------+------------+------------+

In ackPending case, we move to forwarding state and cancel the GRT.

IMO, the two are similar case but handled in a different way. Any particular reason?

• In section 4.4.2, in following case:

+-------------------------------+------------+------------+------------+
| RPF_Interface(S) becomes I    |->NI        |->NI Cancel |->NI Cancel |
|                                                    |               | PPT(S,G,I) |  PT(S,G,I) |
+-------------------------------+------------+------------+------------+

In this event, downstream interface has now become upstream interface, so should not this clean up all this information and start collecting the other one used in upstream interface case.

• I am not sure why we have State-refresh message which is a top-down approach? Why we do not use a bottom-up approach and ask routers to refresh their prune state with upstream routers? Can someone please explain this? I am sure there must have been some reason to do it this way, it is just that I could not find it. We could have avoided the source-active-timer.

• In section 4.6.2 'AssertCancel Messages', I did not get the meaning of the last statement:

   An AssertCancel(S,G) message is simply an Assert message for (S,G)
   with infinite metric.  The Assert winner sends this message when it
   changes its upstream interface to this interface. 

Assert is typically done on downstream interfaces so what is the meaning of 'upstream interface to this interface' in the last sentence?

• In section 4.6.1 and 4.6.3, 'spt_assert_metric(S,G,I)' is used but it is not defined. I think it should have been using 'spt_assert_metric(S,I)'.

• Taking cue from the above, I think 'AssertWinnerMetric(S,G,I)' should also be 'AssertWinnerMetric(S,I)'.

• In '4.6.3. Assert State Macros', is not it enough to check 'AssertWinner(S,G,I) != me'? Why do we need to compare the spt_assert_metric against the AssertWinnerMetric? I was looking at RFC 4601 and we need it there because of transition to SPT.

Regards,
Bharat
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "Nicholas, Jonathan - ES" <[email-masked]>
Date: Wed, 9 Nov 2011 09:04:18 -0500

Responses in line.

Jonathan Nicholas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bharat Joshi
> Sent: Thursday, November 03, 2011 8:25 AM
> To: [email-masked]
> Subject: [pim] Some questions on PIM-DM RFC 3973
>
> Hi,
>
>       I was going through the PIM-DM RFC and have got some questions. I
> tried to search net for some of them but did not find a satisfactory
> answer and so decided to send a mail on this mailing list.
>
>      Here is the list:
>

oiflist is defined in section 4.2 - perhaps section 4.2 should say oiflist(S,G).

> In case of Pruned state, should not we cancel PLT(S,G)? BTW, in case
> olist(S,G) is non-NULL, can it really have Pruned state?

Let's see if I can get all of these.

In the case of Forwarding state, the most likely situation is that the RPF'(S) has changed, but the upstream interface has not, most likely as the result of an Assert.  In this case, a Prune would be redundant, and potentially misleading to others on that interface.  If the actual upstream interface has changed, then the appropriate response would be an Assert, but since the previous upstream router is likely reassessing its own upstream interface, you should just wait for an actual data packet.

In the case of the Pruned state, yes, you could cancel the Prune Limit Timer (and it is probably good coding practice), but since the PLT is to rate limit prunes you won't be sending, it is likely a moot point.  The most likely situation for this case is if the upstream interface has changed, making the previous upstream interface a downstream interface and causing olist(S,G) to become non-NULL when it was previously NULL.

> How will it be in Forwarding and AckPending state if olist(S,G) is
> NULL? Also in case of Pruned state, why to cancel the PLT? Should not
> we send a prune message to new next-hop and let this continue to run?

The state could transition from Forwarding or AckPending if the upstream interface failed, forcing the router to (potentially) use the only active downstream interface as its upstream interface.  If the PLT was running, we want to permit an immediate Prune if a message is received, so we cancel the PLT.  You could send a Prune to the new upstream router, but we felt it was better to wait for a message to arrive.

> • In following case:

Yes, these are actually very different situations.  The OT gets set in response to a Prune message sent by another router.  While this could come from the upstream router, (actually a PruneEcho - see 4.4.2.2 PPT Expires), it is most likely not.  As such, we cannot infer the Upstream Router state from the Prune message.  Conversely, the State Refresh is from the Upstream Router, and it has specifically indicated it will be forwarding, so we know the state of the Upstream Router, making further Graft messages pointless.

> In this event, downstream interface has now become upstream interface,
> so should not this clean up all this information and start collecting
> the other one used in upstream interface case.

Yes, I believe that is what the table says.  Please keep in mind that the upstream and downstream state machines are written to be independent.  However when the RPF_Interface changes, then both state machines will change simultaneously.

> • I am not sure why we have State-refresh message which is a top-down
> approach? Why we do not use a bottom-up approach and ask routers to
> refresh their prune state with upstream routers? Can someone please
> explain this? I am sure there must have been some reason to do it this
> way, it is just that I could not find it. We could have avoided the
> source-active-timer.

State Refresh was not part of the original PIM-DM draft, but was added after some practical experience.  I was not involved at that time, so I cannot say why this approach was taken.

> Assert is typically done on downstream interfaces so what is the
> meaning of 'upstream interface to this interface' in the last sentence?

If the router was previously the Assert Winner on a downstream interface, but found that its upstream interface changed to that interface, it can no longer be a Forwarder on the interface, so it effectively resigns as the Assert Winner.

> • In section 4.6.1 and 4.6.3, 'spt_assert_metric(S,G,I)' is used but it
> is not defined. I think it should have been using
> 'spt_assert_metric(S,I)'.
>

All should read '(S,G,I)' - I believe an errata has been filed for this.

> • In '4.6.3. Assert State Macros', is not it enough to check
> 'AssertWinner(S,G,I) != me'? Why do we need to compare the
> spt_assert_metric against the AssertWinnerMetric? I was looking at RFC
> 4601 and we need it there because of transition to SPT.

This is here to cover the NoInfo case when you should be sending traffic.  It would probably be better to say 'AND AssertWinner(S,G,I) != NULL'.

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 10 Nov 2011 11:34:32 +0530

Hi Jonathan,

     Thanks a lot for your response. Please see my replies in line.

Regards,
Bharat

> oiflist is defined in section 4.2 - perhaps section 4.2 should say oiflist(S,G).
Ok. I will submit an errata to get this fixed.

> In the case of Forwarding state, the most likely situation is that the RPF'(S) has changed, but the upstream interface has not, most likely as the result of an Assert.  In this case, a Prune would…
Got the first part where upstream interface has not changed. There is no need to send a Prune as assert state would have told him that he has lost it.

For the second part where upstream interface has changed, how will the previous upstream neighbour would cleanup the state? Will it be based on the timer?

In the case of the Pruned state, yes, you could cancel the Prune Limit Timer (and it is probably good coding practice), but since the PLT is to rate limit prunes you won't be sending, it is likely a moot point. 
Ok. I agree it is better to cancel the PLT.

 The most likely situation for this case is if the upstream interface has changed, making the previous upstream interface a downstream interface and causing olist(S,G) to become non-NULL when it was previously NULL.
But how an upstream interface will become downstream interface until that interface has receivers. Even if it has receivers, this interface may not be an upstream interface to reach the source.

What I am trying to understand is how come both the state change happens together?

> The state could transition from Forwarding or AckPending if the upstream interface failed, forcing the router to (potentially) use the only active downstream interface as its upstream interface.  I…
I still did not understand that if olist(S,G) is NULL, how can it be in forwarding state? Is this something similar to what you have mentioned above? In this case, the downstream interface is moved to becomes upstream interface and if we had only one downstream interface, olist(S,G) will now become NULL.

Why do you think it was better to wait for the message to arrive? Is this because there may be other routers who would have joined that (S,G) and they would send a join-override if we generate a Prune?

> Yes, these are actually very different situations.  The OT gets set in response to a Prune message sent by another router.  While this could come from the upstream router, (actually a PruneEcho - s…
Ok. I missed the PruneEcho part here.

> State Refresh was not part of the original PIM-DM draft, but was added after some practical experience.  I was not involved at that time, so I cannot say why this approach was taken.
Ok. I will wait if someone can throw some light on this.

> If the router was previously the Assert Winner on a downstream interface, but found that its upstream interface changed to that interface, it can no longer be a Forwarder on the interface, so it ef…
Ok.

> All should read '(S,G,I)' - I believe an errata has been filed for this.
It seems errata has changed this to (S,I).

Another question on assert. Assert typically uses the routing preference/metric to decide an Assert winner. This routing is for the source so why not just keep it as (S,I) instead of (S,G,I).

> This is here to cover the NoInfo case when you should be sending traffic.  It would probably be better to say 'AND AssertWinner(S,G,I) != NULL'.
But this will be taken care by the first statement 'AssertWinner(S,G,I) != me'. Right?

Once we decide what it should be, I can file an errata for this as well.

Again, thanks a lot for replying to these questions, it has really helped in understanding PIM-DM better.

Last question is, are we looking at a next revision where we can bring out PIM-DM from experimental status to proposed standard?

---

From: "Nicholas, Jonathan - ES" <[email-masked]>
Date: Thu, 10 Nov 2011 08:02:15 -0500

More answers below in line...

Jonathan Nicholas

> Sent: Thursday, November 10, 2011 1:05 AM
> To: Nicholas, Jonathan - ES; [email-masked]
> Subject: Re: [pim] Some questions on PIM-DM RFC 3973
>
> Hi Jonathan,
>
> > > +-------------------------------+------------+------------+-----------
> > > +
> > In the case of Forwarding state, the most likely situation is that
> > the RPF'(S) has changed, but the upstream interface has not, most
> > likely as the result of an Assert.  In this case, a Prune would be
> > redundant, and potentially misleading to others on that interface.  If
> > the actual upstream interface has changed, then the appropriate
> > response would be an Assert, but since the previous upstream router is
> > likely reassessing its own upstream interface, you should just wait for
> > an actual data packet.
> >
> Got the first part where upstream interface has not changed. There is
> no need to send a Prune as assert state would have told him that he has
> lost it.
>
> For the second part where upstream interface has changed, how will the
> previous upstream neighbour would cleanup the state? Will it be based
> on the timer?

The previous upstream router will do several things.  First, it will most likely reevaluate its own upstream interface.  If this has changed, it will execute the same sort of procedure that the first router did, and traffic will probably cease flowing to the network through that router.  If the network remains downstream of the previous upstream router, then when the next data packet comes through, an Assert exchange will happen, determining an Assert Winner.

> > The most likely situation for this case is if the upstream interface
> > has changed, making the previous upstream interface a downstream
> > interface and causing olist(S,G) to become non-NULL when it was
> > previously NULL.
> >
> But how an upstream interface will become downstream interface until
> that interface has receivers. Even if it has receivers, this interface
> may not be an upstream interface to reach the source.
>

Please keep in mind that the default action in PIM-DM is to Forward.  Therefore, any previous upstream interface will immediately be in the Forwarding state when it becomes a downstream interface, resulting in olist(S,G) being non-NULL.  If another router is a better upstream router for the network, it will be resolved through Asserts.

> > > +-------------------------------+------------+------------+-----------
> > > +
> > The state could transition from Forwarding or AckPending if the
> > upstream interface failed, forcing the router to (potentially) use the
> > only active downstream interface as its upstream interface.  If the PLT
> > was running, we want to permit an immediate Prune if a message is
> > received, so we cancel the PLT.  You could send a Prune to the new
> > upstream router, but we felt it was better to wait for a message to
> > arrive.
> >
> I still did not understand that if olist(S,G) is NULL, how can it be in
> forwarding state? Is this something similar to what you have mentioned
> above? In this case, the downstream interface is moved to becomes
> upstream interface and if we had only one downstream interface,
> olist(S,G) will now become NULL.

Yes, exactly.  The old downstream interface that was the sole entry in olist(S,G) becomes the upstream interface, forcing olist(S,G) to be NULL.

> Why do you think it was better to wait for the message to arrive? Is
> this because there may be other routers who would have joined that
> (S,G) and they would send a join-override if we generate a Prune?

No, rather that such a change to the network topology implies a certain network instability such that it may be better to wait and see what traffic flows.  Remember, PIM-DM defaults to forwarding and should remain idle if traffic is not flowing.

> > All should read '(S,G,I)' - I believe an errata has been filed forthis.
> >
> Another question on assert. Assert typically uses the routing
> preference/metric to decide an Assert winner. This routing is for the
> source so why not just keep it as (S,I) instead of (S,G,I).

If the errata has changed it to (S,I) then that is correct.  The 'G' played no role in the decision, but since all other states were (S,G) there was some push to keep it for consistency.

> > This is here to cover the NoInfo case when you should be sending
> > traffic.  It would probably be better to say 'AND AssertWinner(S,G,I) != NULL'.
> >

No.  If you are the only Forwarder on a network, then your Assert state will be NoInfo and the Assert Winner will be NULL.

> Last question is, are we looking at a next revision where we can bring
> out PIM-DM from experimental status to proposed standard?

The PIM Working Group moderators should be consulted for this.  My understanding is that a revision is planned to address the errata, but the actual status is unlikely to leave experimental.  While PIM-DM has some nice properties for certain applications and I have a certain fondness for it, PIM-SM is better for most applications and PIM-DM has not seen much deployment.

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 11 Nov 2011 13:19:04 +0530

Hi Jonathan,

     Thanks for your replies. Please see my response in line.

Regards,
Bharat

Ok.

> Please keep in mind that the default action in PIM-DM is to Forward.  Therefore, any previous upstream interface will immediately be in the Forwarding state when it becomes a downstream interface,…
Ok. I thought about it a little more and now understand what you are suggesting.

It would have been great if RFC could describe few things like above so that it becomes easier to follow.

Ok.

> No, rather that such a change to the network topology implies a certain network instability such that it may be better to wait and see what traffic flows.  Remember, PIM-DM defaults to forwarding a…
Ok. There may be a case where this new upstream router may not be forwarding this multicast traffic.

> If the errata has changed it to (S,I) then that is correct.  The 'G' played no role in the decision, but since all other states were (S,G) there was some push to keep it for consistency.
Ok. Let me check this if it is now consistent. If not, we can have another errata to get this fixed.

> No.  If you are the only Forwarder on a network, then your Assert state will be NoInfo and the Assert Winner will be NULL.
But in both these cases, AssertWinner(S,G,I) won't be equal to 'me'. Right?

> The PIM Working Group moderators should be consulted for this.  
> 
Stig/Mike, any inputs on this?

My understanding is that a revision is planned to address the errata, but the actual status is unlikely to leave experimental.  While PIM-DM has some nice properties for certain applications and I have a certain fondness for it, PIM-SM is better for most applications and PIM-DM has not seen much deployment.

Ok.

---

From: "Nicholas, Jonathan - ES" <[email-masked]>
Date: Fri, 11 Nov 2011 08:09:20 -0500

I think there are just a couple items left, so I will pull those out and discuss them individually.

> that it becomes easier to follow.

Authors strive to explain in more detail the items that they believe are complicated and need more discussion.  The WG then reviews and will often suggest that detail to make things easier to follow be added to the draft.  Unfortunately, not everyone finds the same things easy and a balance must be struck between enough detail to understand and having every RFC number in the 100s of pages.

> > > But this will be taken care by the first statement
> 'AssertWinner(S,G,I)
> > > != me'. Right?
> >
> > No.  If you are the only Forwarder on a network, then your Assert
> state will be NoInfo and the Assert Winner will be NULL.
> >

No.  Please read the macro carefully.  If the Assert Winner is NULL, then 'AssertWinner(S,G,I) != me' will evaluate to TRUE, which will result in a router evaluating lost_assert(S,G,I) to TRUE, which would be incorrect.