Subject: [Tsvwg] More questions about the AddIP extension

From: [email-masked]
Date: Sat, 23 Feb 2002 19:07:25 +0200

Hi again!

	Suddenly I realized about one thing. The AddIP extension is designed in a way that if the ASCONF ACK chunk is lost and the ASCONF chunk is resent, the ASCONF receiver should answer in the same way as if it would have never received the first ASCONF chunk, not modifying anything as it should have done it the first time. This is of course the right way of doing.

	But, there is an implementation note in page 15 that suggests keeping the ASCONF ACK chunk sent as an "optimization"... I tend to think that this is not an optimization but a compulsory thing to do... The reason is that when parsing the ASCONF chunk for the second time the answer might be different because:

	- If we agree that we treat as a success adding an address already in use or deleting an address that was not in use, then the answer to the second ASCONF (including additions and deletions of addresses) will be effectively the same. However, in this case I think that this fact (considering these situations as successes) should be stated in the draft.

	- I can think about another weird but still valid situation. If in the ASCONF the peer tells us to set our primary address to A, and in the same chunk it tells us in a subsequent parameter to delete that address. Upon the receipt of the second ASCONF, the "Set Primary Address" parameter would fail, since that address is not in use... The ASCONF sender is doing strange things, but for example Peter Lei's implementation would produce a different answer for the second ASCONF... :-/

	So, I think that either keeping the ASCONF ACK chunk is compulsory, or the behavior in these "corner case" situations (actually the first case is not a corner case at all) should be clearly stated in the draft...

	Comments?

	Thanks!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Feb 2002 05:34:41 -0600

>         Suddenly I realized about one thing. The AddIP extension is designed in a way that if the ASCONF ACK chunk is lost and the ASCONF chunk is resent, the ASCONF receiver should answer in the s…

Yep...

>         - I can think about another weird but still valid situation. If in the ASCONF the peer tells us to set our primary address to A, and in the same chunk it tells us in a subsequent parameter…

No... you are required to give the same answer.. 

>         So, I think that either keeping the ASCONF ACK chunk is compulsory, or the behavior in these "corner case" situations (actually the first case is not a corner case at all) should be clearly…

I disagree here Ivan... there may be some better way than keeping the
asconf-ack around. Peter and I do this in our implementation but
let us not limit implementors. It is required they they always
answer the same but let's not dictate how you implement that.

I could also image an implementation that keeps a state history
of some kind and thus can reconstruct a state (ip addresses, primaries
and such) at any given time. So when an ASCONF-ACK arrives it
can send back the exact same answer. Remember you can only
have ONE ASCONF out at a time.. so in a state keeping implementation
you would only have to keep one set of state (if you were worried
about space)..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)