Re: [Tsvwg] EndPoint and Association Address conflict

[Michael Tuexen <[e-mail]>]

Dear all,

one possibility to capture this stuff is in an separate ID. It could
deal with such terminology stuff and usage stuff for AddIP. Maybe
an applicability statement or BCP. Don't know, but it could life for
some time as an ID and become an RFC later on.
If this seems a good idea I could try to write up some text ...

Best regards
Michael

On Monday, April 29, 2002, at 09:44 PM, Jon Grimm wrote:

> Thanks for the remarks, Randy.
>  I have a few comments still below.  Thanks, Jon
>
> Randall Stewart wrote:
>>
>> Jon:
>>
>> a couple of comments :>
>>
>> Jon Grimm wrote:
>>>
>>> Ivan/All
>>>
>>>         I think something that needs to come out of this discussion 
>>> are
>>> scenarios and mandatory behavior in those scenarios (or why 
>>> flexibility
>>> is allowed if not mandatory behavior).  Its a little disturbing that a
>>> similar 'what is an endpoint?' discussion seems to pop up again every 
>>> so
>>> often.  (e.g.bindx discussion last Sept in
>>> ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/2001-09.mail ) and still 
>>> does
>>> not seem to be completely clear even to those following SCTP closely
>>> over the last year.
>>
>> I agree.. it is a discussion that seems to NEVER end :>
>>
>>>
>>> For each of the following scenarios,
>>>
>>> 1) A new address is to be added an endpoint. (manual)
>>> 2) An address is to be deleted from an endpoint.  (manual)
>>> 3) A new NIC/address is configured and an endpoint is bound to all
>>> (auto)
>>> 4) An address bound is brought down (no longer available) (auto).
>>> 5) An address bound is brought down for maintenance and then brought
>>> on-line again. (auto)
>>>
>>> consider each of the following subcases (assuming multiple 
>>> associations
>>> under an ep).
>>>
>>> a) All Peers have ADD-IP.
>>> b) No Peers have ADD-IP.
>>> c) A subset of Peers support ADD-IP.
>>>
>>> What happens?
>>>
>>
>> Where are you proposing putting these examples? I think some
>> text is needed for clearification but I am not sure that a protocol
>> spec is where you illustrate all these different examples...
>
>
> In some I-D,of course.   I see you are considering the Sockets API I-D,
> yes this could work for me as an appendix there.  Given this latest
> round of discussion, folks may wildly disagree, but I'm coming from the
> angle that I just want it captured.  ;-)
>
>>
>>> Another comment:
>>> Dropping down a little bit into the Sockets API for illustration:
>>>
>>> Depending on one's interpretation of endpoint, what is the endpoint 
>>> for
>>> the association of a peeled-off UDP style socket or for that matter an
>>> 'accepted' TCP-style socket.  If the strict interpretation of the
>>> endpoint is kept.. wouldn't an ADD-IP on the child sockets (peeled off
>>> or accept TCP) affect the local endpoint of the parent socket?  Or 
>>> vise
>>> versa, should an ADD-IP on a TCP-style listening socket, affect the
>>> accepted sockets?  If yes, was this expected?  If no, does the 
>>> original
>>
>> In my view the ADD-IP is done against the listening type endpoint. So
>> in the case of connected and/or peeled off associations they are
>> a different critter. In some ways they have formed a "new" endpoint. 
>> But
>> a interesting thing about them is they CAN NOT listen. So maybe in
>> this case Brian's adding an address to the association is the right
>> approach. They can NEVER receive a new association.. only the single
>> listner (in the TCP or UDP case) can do that.
>>
>> So a peeled off or "connected" socket with only one association may
>> well be a candidate to do an add-ip on an association basis.. but not
>> on the listening endpoint or a UDP model grouping of associations...
>>
>
>
> Has this gone full circle then?   This sounds more like you are always
> doing add-ip on associations.   Or you are really always doing add-ip on
> (Brian's or Ivan's ??) individual communication endpoints that belong to
> a grouping (group of 1 (peeled off) or many (udp style))?
>
> Consider two cases:
> 1)  If not bound-all, and an address is added via bindx.. I'd want the
> bindx to apply to the listening endpoint, as well as the associations
> currently grouped under that socket, but not the peeled-off socket.
> 2) If however, if the original socket was bound-all and a new interface
> is configured, I'd want to this new information to propogate both to the
> original listening socket and any peeled off sockets.
>
> Do these make sense?
>
>
> A related question:  should Add-ip happen on associations waiting in the
> TCP-style accept queue?   manual bindx()?  auto INADDR_ANY??
>
>
>
>>> definition of endpoint still hold?
>>>
>>> Even if each expected behavior does not get spelled it, it would be 
>>> nice
>>> for the SCTP Sockets API I-D to clarify the relationship between a
>>> socket and an endpoint, so implementors can at least infer what the
>>> intended behavior should be.
>>
>> Hmm this may be the best place for this information since it will
>> be informational..
>
> Sure.  If thats were folks want it, as long as gets agreed on and
> captured somewhere.
>
> Thanks,
> Jon
>
>
>>
>> R
>>
>> --
>> Randall R. Stewart
>> [e-mail] 815-342-5222 (cell phone)
>>
>> _______________________________________________
>> tsvwg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/tsvwg
>>
[e-mail]



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