Subject: RE: [Tsvwg] EndPoint and Association Address conflict

From: Tuexen Michael <[email-masked]>
Date: Mon, 29 Apr 2002 14:20:03 +0200

Brian,

see my comments below.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Monday, April 29, 2002 2:15 PM
> To:	Tuexen Michael
> Cc:	Jacob Heitz; Khan, Mohammad; [email-masked]'; Pillai, Hari
> Subject:	Re: [Tsvwg] EndPoint and Association Address conflict
> 
> Tuexen,
> 
> On Mon, 29 Apr 2002, Tuexen Michael wrote:
> > > 
> > > Why restrict Add-IP to an endpoint basis?
> > > 
> > 	[Tuexen Michael]  Consider E1 = ({IP'}, Port), E2 = ({IP'''}, Port),
> > 	E3 = ({IP''''}, Port) with pairwise different IP', IP''', IP'''' and two associations
> > 	A1: E1 <-> E2
> > 	A2: E1 <-> E3
> > 
> > 	Now if we add IP'' to the association A1 we get
> > 	A1 : E1' <-> E2
> > 	with E1' = ({IP', IP''}, Port).
> > 	E1' and E2 share one transport address which is in violation to RFC
> > 	2960, page 13.
> 
> There is only one MUST on page 13: "Two SCTP endpoints MUST NOT have more
> than one SCTP association between them at any given time."
> 
> How does this violate anything on page 13?
	[Tuexen Michael]  I did not mean this sentence. 
> E1' and E2 only have one association between them.  E1 and E3 only have one
> association between them.  Everthing appears ok as far as page 13 is
> concerned.
> 
> Did you mean another page?
> 
> Or, did you mean the statement: "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."  ...which
> is absurd, particularly as it is done in TCP all the time, and when
> you consider that non-multihomed SCTP associations need to reuse
> dynamic port numbers for connection to other hosts.
	[Tuexen Michael]  I mean this sentence. This sentence
	is NOT absurd, at least if you use the definition of
	SCTP end-point I have given earlier. This is one of the reasons
	I'm quite sure that the RFC authors had the defintion I gave
	in mind.

> --brian
> 
> > 
> > 	Please note that an association has two SCTP end points and these end
> > 	points have the IP addresses. So changing IP addresses means modifying
> > 	the end points.
> > 
> > 	Best regards
> > 	Michael  
> 
> -- 
> Brian F. G. Bidulock    > ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 07:37:15 -0500

Tuexen,

It is absurd, because it is an artificial restriction without merit
and without parallel in TCP.  Removing (ignoring) this sentence causes
no problems for the protocol.  Also, the peer has no way of detecting
or enforcing this restriction, making it even more absurd.

The other way of looking at it is to say that E1 and E1' *are* the
same "SCTP Endpoint", but are different communications endpoints (i.e.,
they are engaged in different associations).  Then even this absurd
statement is not violated (E1 and E1' are the same "SCTP Endpoint")
yet IP addresses can be added on a per-association basis.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦

---

From: Randall Stewart <[email-masked]>
Date: Mon, 29 Apr 2002 13:14:50 -0500

>         I'm quite sure that the RFC authors had the defintion I gave
Michael:

Yes this IS the definition we had in mind and as the writer
of add-ip it as always been our intention of having addip be
on an ENDPOINT basis.. as your observations have been...

Regards

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)