Re: [mpls] Review of draft-mirsky-mpls-bfd-directed-03

Nobo Akiya <nobo.akiya.dev@gmail.com> Sun, 16 August 2015 03:27 UTC

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

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