Subject: RE: [Tsvwg] End point and association Address conflict

From: "Balani, Sandeep" <[email-masked]>
Date: Mon, 29 Apr 2002 10:07:32 -0700

hi Randy, 
  Please See my comments ....

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Saturday, April 27, 2002 5:59 AM
> To: Qiaobing Xie
> Cc: Balani, Sandeep; 'Qiaobing Xie'; [email-masked];
> Khan, Mohammad; [email-masked]
> Subject: Re: [Tsvwg] End point and association Address conflict
> 
> 
> Qiabing/All:
> 
> I agree 100% with Q here. We need to tighten the wording up
> but I don't think anything needs to be redefined... Now I
> want to bring up something for all of you to consider... 
> 
> FORGET ADD-IP for a MINUTE...
> 
> 
> In a NORMAL RFC2960 association I have the following
> 
> E1-(Bound INADDR_ANY)
> 
> I currently have
> 
> IP-A: Nic1/IP-B: Nic2
> 
> I setup an association with a peer
> 
> A1=(IP-A,IP-B:Port 4444)<====================>(IP-Z:Port 5555)
> 
> Now everything is fine...
> 
> Now My administrator plugs in Nic3 and does:
> 
> ifconfig nic3 IP-C
> 
> Now ... my endpoint has JUST CHANGED!! It is now
> 
> IP-A: Nic1/IP-B: Nic2/IP-C: Nic3
> 
> (remember we are bound to ALL)....
> 
> Now  my peer does 
> 
>                  <<------TO:IP-C Port4444----INIT(IP:Z port 5555)
> 
> .....
> 
> You have the SAME EXACT thing you have been dicussing ..
> 
> 
> This is one of the reasons we NEED Add-IP. 
> 
> ....If we think about the ADD-IP case... then when the ADDRESS
> was added to the ENDPOINT (automatically) ... you would have gotten
> 
> -----ADD-IP(IP-C)-------->
> 
> and not reached the above condition...
> 
[ Sandeep ] I agree, that ADD-IP in this case has saved us. But Just a small
question, What happens that if this endpoint E1 has associations A1 & A2,
And A1 supports ADD-IP & A2 Does *NOT* support ADD-IP, what should be done
for A2 after IPc nic was added ? 

I think disconnect A2 and re-establish it again, any other suggestion or
option ??????? 

If this is the case Network administrator should know the consequences(
disconnecting some associations )of ADDING IP addresses dynamically, Is'nt
it ? 

> The key is has Qiaobing stated, you ADD addresses to ENDPOINTs. I
> think we will add some text towards this clearfication in the next
> pass..
> 
 [ Sandeep] I am glad that this is being cleared UP, So the same statment is
TRUE for DELETE-IP also, I.E.  " You DELETE addresses from an Endpoint,
Although final beneficiary in both the cases is Association, but
ADDITION/DELETION of IP addresses is done on association."  Correct
????????????????????  

If everything said above is TRUE than what i am gonna assume is  " When User
Does ADDIP i will add that address in all the assocation for that Endpoint,
& When User does DELETE IP i will delete the address from all the
association "  

However i have real problem if some association does'nt support ADD/DELETE
IP procedures then what :-(   

> But the BIG thing I want to point our here is that this issue is
> NOT because of ADD-IP but is something that can happen WITHOUT
> ADD-IP... This is VERY important to remember... Add-ip actually
> helps this situation... as long as your implementation of it
> adds addresses to endpoints that is :->
> 
> R
> 
> Qiaobing Xie wrote:
> > 
> > Hi, Sandeep,
> > 
> > > [ Sandeep ] I totally totally agree with U on that " 
> Addition/Deletion of IP
> > > Address should be on an Endpoint & not on Association.  
> After all we are
> > > modifying the source IP addresses which is an essential 
> part of Endpoint "
> > >
> > > But Currently ADDIP/DELETEIP Draft Says :
> > >
> > > "
> > > - Dynamic IP address reconfiguration extension: For
> > >     computational or networking platforms that allow 
> addition/removal of
> > >     physical interface cards this feature can provide:
> > >
> > >      A) a graceful method to add to the interfaces of an existing
> > >         *******association*******. For IPv6 this feature 
> allows renumbering
> > >         of existing associations.
> > > "
> > 
> > I agree with you. These are loose wordings which may need to be
> > tightened up in the draft. But in a general sense, with the correct
> > understanding and clarification of the rules, the above 
> wording is still
> > fine - it simply depicts the final beneficiary of this add/delete-ip
> > feature, which is indeed the associations themselves.
> > 
> > More importantly, in the draft we need to explicit notify the
> > implementor that using add-ip/delete-ip is fine and 
> benefiting, but one
> > must not break the association rules, otherwise, it becomes 
> a misuse of
> > a good tool and you implementation will break.
> > 
> > I am glad this is brought up in this discussion thread.
> > 
> > >
> > > There are similar references like this in the DRAFT, 
> which mentions
> > > ADD/DELETE IP procedures assocaitions-wise.
> > 
> > We will improve the text and make it tighter.
> > 
> > > So Is there any plans to change the defination of 
> ADDIP/DELETEIP because If
> > > i would do ADD/DELETE on Endpoint I have to perform 
> ASCONF/ASCONF-ACK
> > > procedures on all the assocations  belonging to that 
> endpoint which seems
> > > correct to me but In that case I won't be  in compliance 
> with draft  ....
> > 
> > I don't think anything needs to be re-defined. We just need more
> > clarifications. To the implementor, a good add/delete-ip 
> API semantics
> > might help to provide a safeguard against misuses.
> > 
> > SCTP is different from TCP in that it allows a single endpoint to
> > associate with multiple peers (the "fan-out" config). But 
> no matter how
> > many peers the endpoint is concurrently connected to, 
> logically it is
> > _still_ a single endpoint.
> > 
> > With this being cleared, it should not be hard to 
> understand that it is
> > conceptually wrong to let a user apply add/delete-ip to 
> only a subset of
> > the fan-out concurrent connections on that single endpoint. 
> Because this
> > would in fact result in "splitting" the single endpoint into two
> > different ones. This is NEVER the intention of add/delete-ip - the
> > feature is meant to dynamically modify an endpoint without 
> tearing down
> > all the associations it currently has; it is NOT meant to 
> split a single
> > endpoint into two!
> > 
> > -Qiaobing
> > 
> > >
> > > > With this important clarification of concept, all above 
> should become
> > > > very simple and clear - what you are allowed to do here 
> is __to delete
> > > > IPb from endpoint E1 which is currently being used in 
> associations A1
> > > > and A9__. If your implementation is doing the right 
> thing, the result
> > > > should be
> > > >
> > > >                E1'             E2
> > > >     A1' = [(IPa; Port1), (IPz; Port 65535)]
> > > >
> > > >     And
> > > >                E1'                   E2  /* call it E3 */
> > > >     A9' = [ (IPa; Port1), (IPm; Port 76577)]
> > > >
> > > > If your intention is to transform the original A1 and A9 to the
> > > > following:
> > > >
> > > >                E1'             E2
> > > >     A1' = [(IPa; Port1), (IPz; Port 65535)]
> > > >
> > > >     And
> > > >                E1'                   E2  /* call it E3 */
> > > >     A9' = [ (IPb; Port1), (IPm; Port 76577)]
> > > >
> > > > I am afraid that you have to tear down A1/A9 and set-up 
> A1' and A9'
> > > > fresh. ADD/DELET-IP will NOT get your here without 
> violating the basic
> > > > association rules.
> > > >
> > > > -Qiaobing
> > > >
> > >
> > > Thanks
> > > Sandeep
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

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

> ADDITION/DELETION of IP addresses is done on association."  Correct

Well.. what you are proposing doing is exactly what our kernel work
in BSD's did.. only additional thing is that we do allow a user
to turn this off i.e. .. specify NOT to do the ASCONF.

Note as for the issue when someone does NOT support the ASCONF.. I
don't think you are in ANY worse situation then you were before.
If you really must get the IP address added then the side that
adds the address needs to restart the association...

R