Subject: RE: [Tsvwg] SCTP AddIP Discussion compilation (was: Discussion compilation)

From: [email-masked]
Date: Mon, 6 May 2002 16:47:53 +0300

Hi Kashif!

> Hi Ivan,
> My mail box is not supporting the insertion so sorry for 
> writing from the
> begining.
> Regarding addition of addresses. If the peer which does not 
> support the
> dynamic IP addition sends an INIT for the newly added address 
> which is a
> part of endpoint now then it shall be treated as the 
> association restart by
> this end and would abort the old assoc and establish the new 
> one, isn't it?

	Nope... well, in fact I don't know... That was precisely my doubt... I think that the INIT should be discarded...

	The address to which the INIT went is not part of the association, so it should be treated as coming from an unknown association. Then it does not make much sense to treat is as a restart...

	However, you cannot start a new association with all the addresses of the endpoint because then there will be a conflict with the already established association... Thus, I think that either the INIT is discarded, or the INIT ACK includes only those addresses of the endpoint not used by the other association (I would not recommend to do this), or we invent a new error cause to indicate this situation, probably including one of the addresses of the already established association... In this last case, the peer could send the INIT to this new address and we could do a proper restart...

	But I'm not sure...

> While deleting the address if we remove the address from the 
> endpoint then
> offcource peer would mark it as down due to retransmission 
> losses or HB
> losses but local end may continue sending data keeping source 
> address as
> this one. Is it allowed?

	No! If the endpoint has deleted the address, then, no association should use it as its source address at all!! Even if the peer does not support the deletion of our source address, we should not use it any more!

	Note that I'm not one of the authors of the AddIP draft, and that I might have a different view than them about these issues... :-)

	BR Iván Arias Rodríguez

> Regards
> kashif
> 
>  
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, May 03, 2002 3:09 PM
> To: Khan, Mohammad; [email-masked]
> Cc: Pillai, Hari
> Subject: RE: [Tsvwg] Discussion compilation
> 
> 
> 	Hi Mohammad! Hi all!
> 
> 	See some comments inline...
> 
> > Hi Qiaobing,
> > This is regarding the compilation of the ongoing discussion. 
> > I have observed
> > the following from the ongoing discussions correct me if  i 
> am wrong.
> > 
> > 1)Assocatiation can have subset of addresses of Endpoint i.e. 
> > while sending
> > INIT it can send subset of address specified in the Endpoint.
> 
> 	Yes... A very clear example when this happens (even 
> without AddIP),
> is when you use link-local or site-local IPv6 addresses and 
> the peer is
> outside your link or site scope (i.e., you have link-local 
> and the peer is
> site-local and it is in another link, or you have either link-local or
> site-local, and the peer is outside your site). In this case 
> you cannot
> include all of your addresses, which are part of the endpoint...
> 
> 	Using AddIP, it is always easy to be in this situation. 
> If you add
> one address to the endpoint, then you may add it or not to your
> associations, since the peer may support AddIP or not (not to 
> comment if the
> address to be added is an IPv6 link-local or site-local 
> address, that might
> be added to some associations but to others).
> 
> 	In my opinion, you should first add the address to the 
> endpoint, and
> then to the associations that might be interesting to do so 
> (and can do it),
> not compulsorily adding that address to all the open 
> associations (I guess
> this is somehow an implementation specific issue). What the 
> rest of the
> people think?
> 
> 	In the opposite case, when deleting an address, I 
> imagine that the
> right way of doing would be first trying to delete that 
> address from all the
> associations inside the endpoint that are using it, and then 
> you delete it
> from the endpoint... During the elapsed time from these two 
> actions, the
> associations that have already deleted the address will have one less
> address than the endpoint (however, the idea is that it will 
> be deleted
> later).
> 
> 	In my opinion, one should allow to delete addresses 
> even if there is
> no intention to erase that address from the endpoint... Comments?
> 
> > 2) Addition/Deletion of IP address shall take place on 
> Endpoint not on
> > Association and all the association which belong to the 
> > Endpoint shall start
> > ASCONF procedure. There can be one ASCONF pending for one 
> association.
> > Addition/Deletion of IP address shall be considered 
> > successful even if it is
> > not successfull in few of the associations belonging to the 
> 
> 	See my comments above... I think that there should be 
> two kind of
> addition/deletions: at the endpoint level, and at the 
> specific association
> level.
> 
> 	However, one association can only add one address that 
> has already
> been added to the endpoint (or that was already part of the 
> endpoint), and a
> deletion of an address at the endpoint level must push all 
> the associations
> in the endpoint using that address to (try to) delete it before it is
> deleted from the endpoint (or maybe even later, this would be 
> implementation
> specific).
> 
> > endpoint.  ABORT
> > cause code "INIT with new address" shall take care for IP 
> > address addition
> > for those associations which don't support dynamic IP modification.
> 
> 	I don't think this would work... I will state again the 
> problem I
> proposed some days ago with minor changes...
> 
> 	Endpoint E1 uses IP1a, E2 uses IP2a and E3 uses IP3a. 
> There is an
> association A12 between E1 and E2, and another one, A13, from 
> E1 to E3...
> 
> 	Now, E1 decides to add one address, IP1b. E1 and E2 
> support AddIP
> but E3 does not. So the address is included only in A12. So 
> far, we have:
> 
> 	- E1: (IP1a, IP1b; Port P1)
> 	- E2: (IP2a; Port P2)
> 	- E3: (IP3a; Port P3)
> 	- A12: [(IP1a, IP1b; Port P1), (IP2a; Port P2)]
> 	- A13: [(IP1a; Port P1), (IP3a; Port P3)]
> 
> 	At this point, the user at E3 tells its SCTP stack to 
> establish an
> association with address IP1b and Port P1. This is not 
> illegal, as IP1b is
> not included in A13, and E3 does not know that IP1b is part of E1.
> 
> 	When E1 receives the INIT from IP3a, what should it do? 
> This was the
> original question...
> 
> 	If we let the association phase go, we WILL NOT go 
> through the "INIT
> with new address". At most, we would be in the "INIT ACK with 
> new addresses"
> case. Now that I think about it, maybe it would not be such 
> an stupid Error
> Cause... :-)
> 
> 	But the point here is that you are dealing with source 
> addresses,
> not with destination addresses... You have one more *source* 
> address... The
> peer at E3 is not behaving illegally...
> 
> 	On the other hand, if you are in the opposite case, i.e.:
> 
> 	- E1: (IP1a, IP1b; Port P1)
> 	- E2: (IP2a; Port P2)
> 	- E3: (IP3a; Port P3)
> 	- A12: [(IP1a, IP1b; Port P1), (IP2a; Port P2)]
> 	- A13: [(IP1a, IP1b; Port P1), (IP3a; Port P3)]
> 
> 	And you delete IP1b from E1, then, you will delete it 
> from A12 but
> not from A13. If E3 sends something directed to IP1b, then either:
> 
> 	- You have already deleted that address from your 
> endpoint (and not
> added it, with same port, to any other one) and thus the 
> packet is simply
> discarded (and eventually the address will be marked as 
> inactive), or...
> 	- E1 still contains IP1b and thus the packet is an OOTB 
> datagram and
> the association is aborted.
> 
> > Concern: While deleting an IP address from an Endpoint E1 
> > which has three IP
> > addresses(IPA, IPB and IPC) has three associations running on 
> > it (A1, A2 and
> > A3) while deleting IPA from E1 suppose A3 peer does not 
> > support the dynamic
> > IP modification and keeps IPA as primary destination address. 
> > So peer of A3
> > would keep on sending data chunks on IPA, untill it comes to 
> > know about the
> > status of this address through HEARTBEAT chunks, which shall 
> > not be received
> > by association A1.
> > Your comments......
> 
> 	See my comment above...
> 
> 	In any case, I think that we should first make the definition of
> endpoint crystal clear, before we can move forward... :-/
> 
> 	Have a nice weekend!
> 
> 	BR Iván Arias Rodríguez
> 
> > Regds
> > kashif
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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: Qiaobing Xie <[email-masked]>
Date: Mon, 06 May 2002 11:09:11 -0500

Hi, Ivan and Kashif,

As I indicated in an earlier email, there is quite some confusion on
various definitions in this discussion. Basically we kind of overly
"overloaded" the term endpoint. 

A few of us are working off-line to come up with a clarified definitions
on endpoint, etc. We will present the result to the list for your
review.

regards,
-Qiaobing