Re: [Tsvwg] End point and association Address conflict

[Qiaobing Xie <[e-mail]>]

Hi, Michael,

> on local host         on remote host(s)
> A1: E1 <-----------------> E3
> A2: E1 <---------------------> E4
> A3: E1 <-------------------------> E5
...
> > Rule 2: when adding a transport to a local endpoint that has
> > associations to multiple peers (ie, a fan-out config), one MUST send an
> > add-ip ASCONF to each of those peers. And the new transport can only be
> > used until ALL the peers ack successfully. If anyone of the peers denies
> > the add-ip then you can't add it. So, if you add a new transport to E1
> > above, you have to send ASCONF to both E3 and E4 and have to get a
> > positive ack from both of them.
> >
> I do NOT like this rule. How do you handle the case if E3 and E4 support
> AddIP, but E5 does not. Do you say that you can not add an address to E1 
> because one of the peers does not support AddIP? for deployment this means 
> that AddIP only be used if all implementations support this...

An alternative is to find a way to abort E5 and force it to restart with
E1. Maybe we should introduce an ABORT(error code=please restart with
me).
 
> Why not add it to E1, but it is not allowed to be used as a source
> address for A5.

This will split E1 into two logical endpoints: E1-with-new-addr, and
E1-without-new-addr. And the two logically different endpoints will end
up sharing all original addresses. This breaks the basic RFC2309
definition/rule that says: 
    "A transport address used by an SCTP endpoint must not be used
     by another SCTP endpoint.  In other words, a transport address 
     is unique to an SCTP endpoint."

-Qiaobing


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