Subject: [Tsvwg] Discussion compilation

From: "Khan, Mohammad" <[email-masked]>
Date: Thu, 2 May 2002 22:11:29 -0700

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.

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

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

Regds
kashif

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

---

From: [email-masked]
Date: Fri, 3 May 2002 12:39:22 +0300

Hi Mohammad! Hi all!

	See some comments inline...

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

> 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

	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.

> status of this address through HEARTBEAT chunks, which shall 

	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