From: <Karen.Nielsen@tieto.com>
To: <nishida@sfc.wide.ad.jp>, <tsvwg@ietf.org>
Date: Thu, 8 Dec 2011 13:52:04 +0200
Subject: RE: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
Thread-Topic: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
Thread-Index: Acx0ScS6O/e5brZKRfezgpNBqPFrThBVWdDg
Message-ID: <CF340E42AED0874C81947E18863DE77B13340F715E@EXMB03.eu.tieto.com>
References: <20110916075854.4673.6360.idtracker@ietfa.amsl.com>
 <CABxaRLET3w_MhRtakjuA1Mc4sXd1-FpmorSgjK78K_6WjOX-Qg@mail.gmail.com>
In-Reply-To: <CABxaRLET3w_MhRtakjuA1Mc4sXd1-FpmorSgjK78K_6WjOX-Qg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list

Hi,

One additional comment to the draft.
Not sure about whether it has been raised already though.

The aggressive HBs sent on a potentially failed destination address should =
not contribute
to the association overall error counter. I.e., a failed HB should not incr=
ement the associations error counter.

At least that it how I firmly believe that things should be as the robustne=
ss of the=20
association error count should not be impacted by the more aggressive HB pr=
obing
(Also simply following the approach of RFC4960 Path Verification. 5.4 of RF=
C4960)

Would it be possible to have this explicitly clarified in the draft ?

Thanks.
BR, Karen

-----Original Message-----
From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Y=
oshifumi Nishida
Sent: 16. september 2011 10:22
To: tsvwg
Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

Hi folks,

Based on the michael's review, we have updated the sctp failover draft.
We believe we addressed the comments we got so far.

Please let us know if we overlook something or if you have more comments.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp


2011/9/16  <internet-drafts@ietf.org>:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Quick Failover Algorithm in SC=
TP
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Yoshifumi Nishida
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Preethi Natarajan
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Armando Caro
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nishida-tsvwg-sctp-failove=
r-04.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-16
>
> =A0 One of the major advantages in SCTP is supporting multi-homing
> =A0 communication. =A0If a multi-homed end-point has redundant network
> =A0 connections, SCTP sessions can have a good chance to survive from
> =A0 network failures by migrating inactive network to active one.
> =A0 However, if we follow the SCTP standard, there can be significant
> =A0 delay for the network migration. =A0During this migration period, SCT=
P
> =A0 cannot transmit much data to the destination. =A0This issue drastical=
ly
> =A0 impairs the usability of SCTP in some situations. =A0This memo
> =A0 describes the issue of SCTP failover mechanism and discuss its
> =A0 solutions which require minimal modification to the current standard.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.=
txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.t=
xt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>