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

From: "Balani, Sandeep" <[email-masked]>
Date: Fri, 1 Mar 2002 18:01:17 -0800

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

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 01 Mar 2002 21:25:56 -0600

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