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

From: [email-masked]
Date: Sat, 2 Mar 2002 12:32:09 +0200

Exactly!

My concern was that if you simply parse the received ASCONF, there could be a possibility that your answer is not the same as it previously was. So the implementors must be aware of that, and do whatever they would like to (keeping always a copy of the last sent ASCONF ACK or by any other means), but always answer with the same ASCONF ACK as they did.

If you keep the last ASCONF ACK, obviously there is no need to parse the incoming ASCONF at all, once you realize that the Serial Number is the same as the last one...

BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 02 March 2002 05:26
> To: Balani, Sandeep
> Cc: 'Peter Lei'; Arias-Rodriguez Ivan (NRC/Helsinki); [email-masked]
> Subject: Re: [Tsvwg] More questions about the AddIP extension
> 
> 
> Sandeep:
> 
> No, I think what Ivan meant here is that if you DO NOT STORE
> it then you MUST parse it with some prior state knowledge to
> answer but NOT do anything..
> 
> However if you KEEP a copy of the old asconf-ack... all you
> have to do is NOT parase it but send it back again..
> 
> R
> 
> "Balani, Sandeep" wrote:
> > 
> > Hi all,
> >   I just want to add one comment in Ivan's mail. I know its 
> old but please
> > bear with me.
> > 
> >   We are saying If we receive a duplicate ASCONF, then we 
> will parse it
> > after which we will send the already stored ASCONF-ACK back 
> to the sender.
> > 
> > My question is why at all we need to parse duplicate ASCONF 
> if we are sure
> > that its duplicate and we already 
> acted(added/deleted/setprimary addresses
> > etc) on it? Why not just send stored ASCONF-ACK back ?
> > 
> > To me this make more sense because if i am correct the 
> draft says that
> > sender is not allowed to change ASCONF when it is retransmitting.
> > 
> > Please advice thanks
> > sandeep
> > 
> > > >
> > > > [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
> > 
> > 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...
> > 
> > >         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
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: Randall Stewart <[email-masked]>
Date: Sat, 02 Mar 2002 08:23:37 -0600

Ivan:

I do have a mark on your email in my inbox.. and the next
pass of the add-ip draft will get some text to the implementor
that if they do NOT choose to hold the last ASCONF-ACK they
must be very carefull to KNOW the state that things were
in previously so that they can generate the EXACT SAME
ASCONF-ACK. 

I think it is obvious that we want to hold the ASCONF-ACK 
but I don't think we should MANDATE it from a spec... we can
warn.. but I don't want to force ...

R