Subject: Re: [pim] Small doubt regarding the assert

From: "[email-masked]" <[email-masked]>
Date: Wed, 29 Oct 2003 05:18:11 -0500 (EST)

Thank you very much.
I have one more doubt. Consider the following scenario.

      R1             R2
       |              |
       |              |
       ----------------     
              |
              |
              R3

In the above case consider both R1 and R2 had down stream state for (*, G) or (S, G). Asserts will then happen between R1 and R2. Let us consider R2 wins the assert hence R1 will go to "Iam Assert Loser" state. But in R1 consider that after some time the Assert state machine of R1 goes into "No Info State" due to "could Assert" becoming false . Now it is clear that R2 has no worries and can forward traffic on the lan even without the help of Assert state machine. But to my understanding Draft provides no method by which R2 can forget about its assert state machine and start forwarding on the lan. Why wasnt it taken care in the draft. Is it left to the implementor?
Please forgive me and point me to the section if such technique already exists in the draft.

Thanks in advance
rajesh.

 --- On Tue 10/28, Isidor Kouvelas < [email-masked] > wrote:
From: Isidor Kouvelas [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked]
Date: Tue, 28 Oct 2003 11:51:13 -0800
Subject: Re: [pim] Small doubt regarding the assert 

<br>If the data packet that triggered the assert was forwarded on the link<br>by a router with (S,G) state, then a (*,G) assert with an INADDR_ANY<br>source address will not resolve the forwarding conflict. The reason is<br>that when the router with the (S,G) state receives the assert it will<br>not know that it has to respons with an (S,G) assert. <br>The forwarding conflict will have to wait to be resolved when the<br>router with the (*,G) state forwards a data packet onto the link and<br>the router with the (S,G) state responds with the assert.<br>By providing the source address of the data packet in the (*,G) assert<br>you optimise this behaviour by allowing the router with the (S,G)<br>state to respond immediately thus eliminating the additional delay.<br><br>Isidor<br><br>"[email-masked]" writes:<br>><br>>Hi all,<br>>Why does the draft state that. For the data triggered asserts the source addre<br>>ss MAY be set to the actual source of the data packet. Why can't!
  it be said th<br>>at the Source address in the assert for data packet arriving on the olist of a<br>> (*, G) state MUST be INADDR_ANY.<br>>Can I know the reason why it should be that way. Is it required to maintain ba<br>>ckward compatability?<br>>Thanks in advance<br>>Rajesh.<br>><br>><br>><br>><br>>_______________________________________________<br>>Join Excite! - http://www.excite.com<br>>The most personalized portal on the Web!<br>><br>>_______________________________________________<br>>pim mailing list<br>>[email-masked]<br>>https://www1.ietf.org/mailman/listinfo/pim<br>><br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Thu, 30 Oct 2003 06:41:23 +0000 (GMT)

Yes, you are right, when R1 assert looser state goes in to No_INFO state still the R2 will be sending the assert winner message on the network according to the present draft.

  I could see two ways 

1. Continue sending the assert winner message on the LAN even the loser goes off.

Advantage:

1. Even when the node looses the first assert messages of its neighbor, since it send winner message continuously so it will recover by listening to the assert message second time or further (here dead lock situation won't be there).

Disadvantage:

1. It will be sending the Assert winner message irrespective of the presence of assert interested nodes.

2. Change the state machine little bit to check whether any asserting node is present in the LAN for the given (S,G)/(*,G) and than the winner should send the assert message. It can be done as follows.

a. In (S,G) Assert state machine

   Previous version: 

   When the Assert state machine is in "Iam Assert Winner" state and if Timer expires than follow the action [A3]
   Action for [5] is “Delete assert info”

   Changed version: 

   When the Assert state machine is in "Iam Assert Winner" state and if Timer Expires And if any assert node is available than follow the action [A3]
   Action for [5] would be “Delete assert info” and “send a Assert Cancel (S,G)”

    NOTE: any assert node is available will be set when any one of its neighbor in that interface sends an assert message.

          Any assert node is available will be reset when there is no node is interested on assert on the same interface (when any node sends Assert cancel message or that particular neighbor goes off than it means that, that particular node is not interested on the assert).

b. Same thing should be done (*,G) Assert state machine.

Advantage:

1. When there is no node interested on assert other than my node than it won't send any assert winner message, which will reduce the traffic on the node.

Disadvantage:

1. When any node losses the first assert message from its neighbor than there will be more than one assert winner on the same node (both will be in dead lock situation)

2. It needs to maintain the other assert node information also.

  So this is the call which we need to take, is that we are concern about traffic due a single Assert winner message or prevent possible dead lock situation and burden of maintaining the assert information of other nodes on the same interface, which I have mentioned above.

   I would like to go with the first option where we can continue with the existing one, where we keep sending Assert winner message even there is no other Assert node interested on that LAN.

  Comments are welcome.

Jags

"[email-masked]" <[email-masked]> wrote:

Thank you very much.

R1 R2
| |
| |
---------------- 
|
|
R3

Thanks in advance
rajesh.

If the data packet that triggered the assert was forwarded on the link
by a router with (S,G) state, then a (*,G) assert with an INADDR_ANY
source address will not resolve the forwarding conflict. The reason is
that when the router with the (S,G) state receives the assert it will
not know that it has to respons with an (S,G) assert. 
The forwarding conflict will have to wait to be resolved when the
router with the (*,G) state forwards a data packet onto the link and
the router with the (S,G) state responds with the assert.
By providing the source address of the data packet in the (*,G) assert
you optimise this behaviour by allowing the router with the (S,G)
state to respond immediately thus eliminating the additional delay.

Isidor

"[email-masked]" writes:
>
>Hi all,
>Why does the draft state that. For the data triggered asserts the source addre
>ss MAY be set to the actual source of the data packet. Why can't!
it be said th
>at the Source address in the assert for data packet arriving on the olist of a
> (*, G) state MUST be INADDR_ANY.
>Can I know the reason why it should be that way. Is it required to maintain ba
>ckward compatability?
>Thanks in advance
>Rajesh.
>
>
>
>

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim
Yahoo! India Matrimony: Find your partner online.Post your profile.

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Thu, 30 Oct 2003 06:41:23 +0000 (GMT)

I could see two ways 

Advantage:

 

Disadvantage:

 

   Previous version: 

   Changed version: 

Advantage:

Disadvantage:

 

  Comments are welcome.

Jags

Thank you very much.

R1 R2
| |
| |
---------------- 
|
|
R3

Thanks in advance
rajesh.

Isidor

it be said th