Return-Path: <nobo.akiya.dev@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 52AEC1A1A7E
 for <mpls@ietfa.amsl.com>; Sat, 15 Aug 2015 20:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0zZMF-6SLhgF for <mpls@ietfa.amsl.com>;
 Sat, 15 Aug 2015 20:27:00 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com
 [IPv6:2a00:1450:4010:c03::234])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 3AAE11A1A76
 for <mpls@ietf.org>; Sat, 15 Aug 2015 20:27:00 -0700 (PDT)
Received: by lagz9 with SMTP id z9so61926836lag.3
 for <mpls@ietf.org>; Sat, 15 Aug 2015 20:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=/5bnc2FSKoxOCqLFB+4KomvGn+GGIT7c4y2hjVZOv4A=;
 b=DYYBwmnpLdbQH3j59HvH5enoyPwjLlDi5802LblUYFHL7wIk+kSHEwRlLwvt2et7o1
 ah1xBdKj0u5vRyfRKr4lq06T0Qr9j4t0CSdXUdxE5EnZ3GaTMJU6K0EB5uZ3aXbX5Jtp
 k7uNNGYusr5/02iz/m3T77YwR2fgyGDS24fkYNC9miISXPzKV1h0qR9NuAkkmEan25al
 nhy++hheZa9DKRJ5P5A036mSX91tDEuJn8iu551ES6n+I6NbypGbz+QL8pD9qdCav5AS
 Yh/99hIELRo6YfDq1SR/qt1/QF1gc8sKGXsXFCiERNZBhMhpfa23qf4GL+HPJ/xdgsow
 zF8Q==
MIME-Version: 1.0
X-Received: by 10.153.7.137 with SMTP id dc9mr49402899lad.16.1439695618434;
 Sat, 15 Aug 2015 20:26:58 -0700 (PDT)
Received: by 10.112.12.198 with HTTP; Sat, 15 Aug 2015 20:26:58 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF1122188F2A6@eusaamb103.ericsson.se>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B486F6B@SZXEMA510-MBX.china.huawei.com>
 <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B4B901E@SZXEMA510-MBX.china.huawei.com>
 <7347100B5761DC41A166AC17F22DF1122188F2A6@eusaamb103.ericsson.se>
Date: Sun, 16 Aug 2015 12:26:58 +0900
Message-ID: <CAFqGwGt4WcBggA0V6O7MSDpLL9cDc9r5undFGwRmc12fd1uiPQ@mail.gmail.com>
From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113462a4ebec70051d654181
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/bzs_dNvozpiv7_z9O1BFXpmkvUI>
Cc: Ross Callon <rcallon@juniper.net>, mpls <mpls@ietf.org>,
 "draft-mirsky-mpls-bfd-directed@tools.ietf.org"
 <draft-mirsky-mpls-bfd-directed@tools.ietf.org>
Subject: Re: [mpls] Review of draft-mirsky-mpls-bfd-directed-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>,
 <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
 <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2015 03:27:02 -0000

--001a113462a4ebec70051d654181
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi March, Greg,

My apologies for very delayed response.

Please see in-line with [NOBO].

Note I've snipped out sections that I accept your response.


> > Section 2
> >
> > o if reverse direction is in Down state, the head-end node would not
> >    receive indication of forward direction failure from its egress
> >    peer.
> >
> > [NOBO] I found above to be slightly unclear in 2 aspects.
> >
> > Since this section is describing the limitations of using BFD on an
> > unidirectional explicitly routed path, what does "if reverse direction
> is in Down state" mean?
> >
> > Additionally, "would not receive indication of forward direction
> > failure from its egress peer" is a bit cryptic. If the egress peer
> > detected that forward direction failed (e.g., BFD session timed out),
> > then the egress peer will send few BFD control packets with DOWN
> > state, IP routed. Thus the ingress peer will notice the problem of the
> forward direction.
> >
> > Readers can likely benefit from having this bullet point better
> clarified.
> >
>
> GIM=E2=89=AB Would the following wording be more deterministic:
>    o  failure detection on the reverse path cannot reliably be
>       interpreted as bi-directional failure and thus trigger, for
>       example, protection switchover of the forward direction;
>
>    o  if a failure of the reverse path being ignored, the ingress node
>       would not receive indication of forward direction failure from its
>       egress peer.
>
>

[NOBO] The second bullet may create more confusion. Can we keep just the
first bullet and add a bit of clarifications as below?

* a failure detection on the reverse path cannot reliably be
  interpreted as bi-directional failure and thus trigger, for
  example, protection switchover of the forward direction.
  When the BFD session on the egress node declares a failure
  (i.e., forward direction failure), the failure may or may not
  reach the ingress node. Therefore, the BFD session on the
  ingress node declaring failure may be a result of just the
  reverse path failure or both forward and reverse paths
  failures.

Regards,
Nobo

--001a113462a4ebec70051d654181
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi March, Greg,<div><br></div><div>My apologies for very d=
elayed response.</div><div><br></div><div>Please see in-line with [NOBO].</=
div><div><br></div><div>Note I&#39;ve snipped out sections that I accept yo=
ur response.</div><div><br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><font face=3D"Calibri" size=3D"2"=
><span style=3D"font-size:11pt"><div><br></div><div><div class=3D"h5">
<div>&gt; Section 2</div>
<div>&gt; </div>
<div>&gt; o if reverse direction is in Down state, the head-end node would =
not</div>
<div>&gt; =C2=A0 =C2=A0receive indication of forward direction failure from=
 its egress</div>
<div>&gt; =C2=A0 =C2=A0peer.</div>
<div>&gt; </div>
<div>&gt; [NOBO] I found above to be slightly unclear in 2 aspects.</div>
<div>&gt; </div>
<div>&gt; Since this section is describing the limitations of using BFD on =
an </div>
<div>&gt; unidirectional explicitly routed path, what does &quot;if reverse=
 direction is in Down state&quot; mean?</div>
<div>&gt; </div>
<div>&gt; Additionally, &quot;would not receive indication of forward direc=
tion </div>
<div>&gt; failure from its egress peer&quot; is a bit cryptic. If the egres=
s peer </div>
<div>&gt; detected that forward direction failed (e.g., BFD session timed o=
ut), </div>
<div>&gt; then the egress peer will send few BFD control packets with DOWN =
</div>
<div>&gt; state, IP routed. Thus the ingress peer will notice the problem o=
f the forward direction.</div>
<div>&gt; </div>
<div>&gt; Readers can likely benefit from having this bullet point better c=
larified.</div>
<div>&gt; </div>
<div>=C2=A0</div>
</div></div><div>GIM<font face=3D"Cambria Math">=E2=89=AB</font> Would the =
following wording be more deterministic:</div>
<div>=C2=A0=C2=A0 o=C2=A0 failure detection on the reverse path cannot reli=
ably be</div>
<div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interpreted as bi-directional failure a=
nd thus trigger, for</div>
<div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 example, protection switchover of the f=
orward direction;</div>
<div>=C2=A0</div>
<div>=C2=A0=C2=A0 o=C2=A0 if a failure of the reverse path being ignored, t=
he ingress node</div><span class=3D"">
<div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would not receive indication of forward=
 direction failure from its</div>
<div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 egress peer.</div>
<div>=C2=A0</div></span></span></font></div></blockquote><div><br></div><di=
v>[NOBO] The second bullet may create more confusion. Can we keep just the =
first bullet and add a bit of clarifications as below?</div><div><br></div>=
<div>* a failure detection on the reverse path cannot reliably be</div><div=
>=C2=A0 interpreted as bi-directional failure and thus trigger, for</div><d=
iv>=C2=A0 example, protection switchover of the forward direction.</div><di=
v>=C2=A0 When the BFD session on the egress node declares a failure<br></di=
v><div>=C2=A0 (i.e., forward direction failure), the failure may or may not=
</div><div>=C2=A0 reach the ingress node. Therefore, the BFD session on the=
</div><div>=C2=A0 ingress node declaring failure may be a result of just th=
e</div><div>=C2=A0 reverse path failure or both forward and reverse paths</=
div><div>=C2=A0 failures.</div><div><br></div><div>Regards,</div><div>Nobo=
=C2=A0</div></div></div></div></div>

--001a113462a4ebec70051d654181--

