Subject: RE: [Tsvwg] More questions about the AddIP extension

From: [email-masked]
Date: Mon, 25 Feb 2002 15:03:04 +0200

Hei!

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 25. February 2002 13:35
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Tsvwg] More questions about the AddIP extension
> 
> 
> [email-masked] wrote:
> > 
> >         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.
> > 
> 
> Yep...
> 
> >         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... :-/
> 
> No... you are required to give the same answer.. 

	Yes. But then, for example, answering with an "Unresolvable Address" error cause to a Set Primary if the address stated is not in use can cause problems. In the example where there is a (weird) ASCONF that requires to set one address as the primary and then it deletes it, if we receive a duplicate ASCONF and re-parse it, we will generate an "Unresolvable Address" while the first time we simply accepted it... Thus, you really need to know what happened before...

	Well, now that I think about it, you could always "undo" the changes required by the ASCONF to be in the same state you were... But then you are not sure either if you did that last time... :-0

	In any case, I think that this discussion is not really important, as these things happen when the ASCONF sender is playing strange games... :-)

	However, that case in the other mail about adding an address that is in use in another association, but due to a deletion in becomes a valid addition in the second ASCONF is a little bit more tricky... The ASCONF sender could receive two ASCONF ACK, one saying that the address was not added, and another one stating the opposite... But I'm not sure I'm young enough to see such corner case situation ever... :-)

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

	Yes sure...

	Then, if you add to the IMPLEMENTATION NOTE something like "But no matter how it is implemented, the ASCONF ACK sender must be sure that the ASCONF ACK chunk sent upon the receipt of a duplicate ASCONF chunk is exactly the same it sends when it received the original ASCONF chunk", I won't disturb you anymore ;-). I you don't, I won't disturb you either :->

	Thanks for your answer!

	BR Iván Arias Rodríguez

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

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

---

From: Peter Lei <[email-masked]>
Date: Mon, 25 Feb 2002 10:46:53 -0600

>         Well, now that I think about it, you could always "undo" the changes required by the ASCONF to be in the same state you were... But then you are not sure either if you did that last time...…

Right, the implementation does need to know what the state is before the first
ASCONF was received and processed;  in the scenario described, we still would
NOT send a (second) ACK with a different result.  Since there can only be one
outstanding ASCONF at any given time per association, there is only a single
set of "previous states" to keep around to "undo the changes" before responding.
*How* it does this should be implementation specific...