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

From: "Balani, Sandeep" <[email-masked]>
Date: Fri, 26 Apr 2002 15:34:27 -0700

Hi Qiaobing, 
  My comments.

thanks
sandeep

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 3:24 PM
> To: Balani, Sandeep
> Cc: 'Qiaobing Xie'; [email-masked];
> [email-masked]; Khan, Mohammad; [email-masked]
> Subject: Re: [Tsvwg] End point and association Address conflict
> 
> 
> Hi, Sandeep,
> 
> It is very good point. Please see below for my answer.
> 
> > [ Sandeep ]  A slight change in the example above. What if 
> initally I have 2
> > Associations.
> > 
> >            E1                  E2
> >   A1 = [(IPa,IPb; Port1), (IPz; Port 65535)]
> > 
> >               E1                      E2
> >   A9 = [ (IPa, IPb; Port1), (IPm; Port 76577)]
> >
> > And then i perform DELETEIP(IPb) from association A1,  then 
> i have something
> > like
> > 
> >           E1'                  E2
> >     A1' = [(IPa; Port1), (IPz; Port 65535)]
> > 
> >     And
> >                  E1                      E2  /* call it E3 */
> >     A9 = [ (IPa, IPb; Port1), (IPm; Port 76577)]
> > 
> >  Which is also illegal ....
> 
> Yes, this is illegal. Your implementation should never allow this to
> happen. 
> 
> You may have some confusion over an important definition in 
> SCTP. It is
> conceptually WRONG to say "deleting IPb from association A1". One can
> only add or delete addresses to or from __an SCTP endpoint__. 
> 

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

There are similar references like this in the DRAFT, which mentions
ADD/DELETE IP procedures assocaitions-wise. 

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

> 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 

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

---

From: Randall Stewart <[email-masked]>
Date: Sat, 27 Apr 2002 07:59:04 -0500

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

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

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:
> 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.
> 
> >
> We will improve the text and make it tighter.
> 
> 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
> 
> >

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 26 Apr 2002 18:40:41 -0500

Hi, Sandeep,

-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Apr 2002 01:49:31 -0500

Qiaobing,

Multi-homing is OPTIONAL.  Are you saying that a group of
associations that are not multi-homed (single IP address
in INIT), and on different IP addresses for the same host
is somehow splitting the host into multiple end-points?
I don't see how this is different than for TCP when the
host has multiple IP addresses: each connection may be
from a different IP address...  Please explain.

--brian

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 11:44:03 -0500

Hi, Brian,

The entire chapter 2 of Randy and I's SCTP book is spent on defining
SCTP endpoints. If you have it handy, take a look at Figure 2-2 on page
23 and Figure 2-3 on page 24 (too hard for me to re-draw them in text
here). That shows what "split" endpoints look like.

-Qiaobing