Subject: [Tsvwg] FW: SCTP multihoming and INIT

From: <[email-masked]>
Date: Mon, 25 May 2009 15:46:54 +0400

Thanks!

It's clear. But we have an equipment which initiate association only by primary ip address of peer end. So, if we have problem with primary ip backbone, association will never be established. I think it's the disadvantage of the equipment.
Unfortunately I didn't find any comments about this problem in RFC2960. Moreover, vendor thinks it's equipment is fully agreed with RFC2960.

BR/Sergey

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Monday, May 25, 2009 3:35 PM
To: Смирнов Сергей
Cc: [email-masked]
Subject: Re: SCTP multihoming and INIT

Hi,

you can send the INIT to any of the addresses of the peer.
The notion of primary/secondary is only relevant to the
data transmission.

Please send further questions regarding to [email-masked].

Best regards
Michael

On May 25, 2009, at 11:51 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Hello!
>
> As wrote in RFC2960(4960) <A) "A" first sends an INIT chunk to "Z".>
> Must “A” sends INIT message to primary and secondary destination  
> addresses at peer end when we use multihoming?
> In other words, must be association initiated by secondary path only  
> (so, primary path is not available)?
>
> BR/Sergey
> NSS engineer OJSC “Megafon”, Russia
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Randy Stewart <[email-masked]>
Date: Mon, 25 May 2009 08:27:32 -0400

Sergey:

No such equipment would NOT be in compliance with either RFC2960 OR  
RFC4960(its successor).  The
equipment manufacture really needs to attend an inter-op session next  
time one
is planned and find out where they are NOT in compliance... at least
my guess is they have never attended one. Since this is one of the tests
we always do... i.e.

PEER-A (IP-A1/A2)                          PEER-Z (IP-Z1/Z2)
    from A1-------INIT(A1/A2) ---> to Z1
       to A2 <----INIT-ACK(Z1/Z2)-- from Z2

The PEER-A must be able to handle the above INIT-ACK and recognize
it has part of the association that it is forming. Likewise when
Peer Z gets back the cookie-echo it too must recognize the cookie
from either network IP address A1 OR A2.

R

On May 25, 2009, at 7:46 AM, <[email-masked]> <[email-masked] 

> Thanks!
>
> It's clear. But we have an equipment which initiate association only  
> by primary ip address of peer end. So, if we have problem with  
> primary ip backbone, association will never be established. I think  
> it's the disadvantage of the equipment.
> Unfortunately I didn't find any comments about this problem in  
> RFC2960. Moreover, vendor thinks it's equipment is fully agreed with  
> RFC2960.
>
> BR/Sergey
>

-----
Randall Stewart
[email-masked]