Re: The usecase of the BFD application

Jeffrey Haas <jhaas@pfrc.org> Sat, 09 November 2019 19:08 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A7120046; Sat, 9 Nov 2019 11:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 A-KMVsC2uCpB; Sat, 9 Nov 2019 11:08:19 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF83D12001A; Sat, 9 Nov 2019 11:08:18 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DE2D11E2F5; Sat, 9 Nov 2019 14:12:04 -0500 (EST)
Date: Sat, 9 Nov 2019 14:12:04 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Weiqiang Cheng <chengweiqiang@chinamobile.com>
Cc: bfd-chairs@ietf.org, rtg-bfd@ietf.org, =?utf-8?B?J+eOi+eRnumbqic=?= <wangruixue@chinamobile.com>, liu.aihua@zte.com.cn
Subject: Re: The usecase of the BFD application
Message-ID: <20191109191204.GC19227@pfrc.org>
References: <028a01d59380$e2350480$a69f0d80$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <028a01d59380$e2350480$a69f0d80$@com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/YU64rnriJIYGUu3g_ywpHJURAAY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Nov 2019 19:08:22 -0000

Weiqiang Cheng,

BFD appears to be likely to have a small amount of business at the upcoming
IETF-106. The working grooup needs to find a secretary to commit to minutes
for us to meet.

If we do meet, you may have 10 minutes to discuss this.

I will ask you to include the following information in your presentation:
- How does this proposal differ from BBF TR-146?
  (https://www.broadband-forum.org/download/TR-146.pdf)
- What are the implications for BFD clients?  This would include BFD yang
  models.

-- Jeff

On Tue, Nov 05, 2019 at 10:29:43AM +0800, Weiqiang Cheng wrote:
> Hi Chairs,
> 
> We prepared a draft to use BFD in datacenter application scenario.
> 
> Because the time zone difference, we missed the submission deadline and we
> will upload it on Nov. 16.
> 
> If possible, we still hope to apply a slot to present it. Could you see if
> it is Ok for the group?
> 
>  
> 
> B.R.
> 
> Weiqiang Cheng
> 

> 
> 
> 
> BFD Working Group                                                R. Wang
> Internet-Draft                                                  W. Cheng
> Intended status: Informational                              China Mobile
> Expires: May 7, 2020                                             Y. Zhao
>                                                                   A. Liu
>                                                                      ZTE
>                                                         November 4, 2019
> 
> 
>                    Using One-Arm BFD in Cloud Network
>                    draft-wang-bfd-one-arm-use-case-00
> 
> Abstract
> 
>    Bidirectional Forwarding Detection (BFD) is a fault detection
>    protocol that can quickly determine a communication failure between
>    devices and notify upper-layer applications [RFC5880].  BFD has
>    asynchronous detecting mode and demand detection mode to satisfy
>    different scenarios, also supports echo function to reduce the device
>    requirement for BFD.  One-Arm BFD this draft descripted supports
>    another BFD detecting function rather than the echo as described in
>    [RFC5880] [RFC5881], it needs nothing BFD capability to one of the
>    devices deployed BFD detecting.  Using One-Arm BFD function, the one
>    device works on BFD detecting normally and the other device just
>    loopback the BFD packets like echo function.  One-Arm BFD is suitable
>    for the cloud virtualization network, the One-Arm BFD is deploy on
>    NFV gateways, and NFV virtual machine vNICs just enable the echo/
>    loopback process.
> 
> Status of This Memo
> 
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on May 7, 2020.
> 
> 
> 
> 
> 
> 
> Wang, et al.               Expires May 7, 2020                  [Page 1]
> 
> Internet-Draft     Using One-Arm BFD in Cloud Network      November 2019
> 
> 
> Copyright Notice
> 
>    Copyright (c) 2019 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (https://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>      1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
>        1.1.1.  Terminology . . . . . . . . . . . . . . . . . . . . .   3
>        1.1.2.  Requirements Language . . . . . . . . . . . . . . . .   3
>    2.  One-Arm BFD Use Case  . . . . . . . . . . . . . . . . . . . .   3
>    3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
>    4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
>    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
>    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
>    7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5
> 
> 1.  Introduction
> 
>    To minimize the impact of device faults on services and improve
>    network availability, a network device must be able to quickly detect
>    faults in communication with adjacent devices.  Measures can then be
>    taken to promptly rectify the faults to ensure service continuity.
> 
>    BFD is a low-overhead, short-duration method to detect faults on the
>    path between adjacent forwarding engines.  The faults can be
>    interface, data link, and even forwarding engine faults.  It is a
>    single, unified mechanism to monitor any media and protocol layers in
>    real time.
> 
>    BFD has asynchronous detecting mode and demand detection mode to
>    satisfy different scenarios, also supports echo function to reduce
>    the device requirement for BFD.  BFD echo function is used when two
>    devices are connected but only one of them supports full BFD
>    capability.  When the echo function is activated, the local system
>    sends a BFD control packet and the remote system loops back the
> 
> 
> 
> Wang, et al.               Expires May 7, 2020                  [Page 2]
> 
> Internet-Draft     Using One-Arm BFD in Cloud Network      November 2019
> 
> 
>    packet through the forwarding channel.  If several consecutive echo
>    packets are not received, the session is declared to be Down.  BFD
>    echo function reduces one of the two devices requirement for BFD.
> 
>    With the development of network cloud and NFV virtualization, there
>    are many connections between gateway devices and the virtual machine
>    devices.  The virtual machine devices don't support BFD capacity at
>    all.  There is difficult to deploy BFD between the gateway devices
>    and the virtual machine vNICs.  One-Arm BFD supports this scenario,
>    it supports gateway enable full BFD capability and virtual machine
>    don't support BFD at all, just simply loopback BFD packets on vNICs.
> 
> 1.1.  Conventions Used in This Document
> 
> 1.1.1.  Terminology
> 
>    BFD: Bidirectional Forwarding Detection
> 
>    NFV: Network Function Virtualization
> 
> 1.1.2.  Requirements Language
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
> 
> 2.  One-Arm BFD Use Case
> 
>    With the development of network cloud and NFV virtualization, there
>    are many connections between gateway devices and the virtual machine
>    devices.  The virtual machine(VM) devices don't support BFD capacity
>    at all.  If the gateway devices are deployed BFD protocol, there are
>    some problems including scalability, detecting period and so on.  And
>    the VM can't support BFD protocol currently.  One-Arm echo BFD can
>    resolve these problems.  One-arm echo BFD is used when two devices
>    are connected and only one of them supports BFD.  A one-arm BFD echo
>    session can be established on the device that supports BFD, the other
>    device just loopback BFD packets.
> 
>    After receiving a one-arm BFD echo session packet, the device that
>    does not support BFD immediately loops back the packet, implementing
>    quick link failure detection.  As shown in Figure 1, Device A such as
>    a NFV gateway supports BFD, whereas Device B such as a virtual
>    machine does not.  To rapidly detect faults in the link between
>    Device A and Device B, configure a one-arm BFD echo session on Device
>    A.  After receiving a one-arm BFD echo session packet from Device A,
> 
> 
> 
> Wang, et al.               Expires May 7, 2020                  [Page 3]
> 
> Internet-Draft     Using One-Arm BFD in Cloud Network      November 2019
> 
> 
>    Device B immediately loops back the packet, implementing rapid link
>    fault detection.
> 
> 
>    Device A               One-Arm Echo        Device B
>    +--------+             BFD session         +---------+
>    |   A    |---------------------------------|   B     |
>    |        |Inf 1                       Inf 1|         |
>    +--------+10.1.1.1/24           10.1.1.2/24+---------+
>    BFD is supported.                          BFD is not supported.
> 
> 
>                  Figure 1: One-Arm BFD deploying scenario
> 
> 3.  Discussion
> 
>    One-Arm BFD detecting function is better than BFD echo function mode.
>    First One-Arm BFD can use full BFD capacity in the BFD-supported
>    device.  So One-Arm BFD can also support fast detecting and manage
>    BFD sessions effectively.  Second it is scalable using one-arm BFD
>    detecting to adapt the NFV virtualization.  Finally, it is the same
>    process in the non-BFD-supported devices with echo function.  So one-
>    arm BFD can be deployed to the cloud network, and the VMs don't
>    require to support BFD capacity.
> 
> 4.  Security Considerations
> 
>    TBD.
> 
> 5.  IANA Considerations
> 
>    This document has no IANA action requested.
> 
> 6.  Acknowledgements
> 
>    TBD.
> 
> 7.  Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119,
>               DOI 10.17487/RFC2119, March 1997,
>               <https://www.rfc-editor.org/info/rfc2119>;.
> 
>    [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
>               (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
>               <https://www.rfc-editor.org/info/rfc5880>;.
> 
> 
> 
> 
> Wang, et al.               Expires May 7, 2020                  [Page 4]
> 
> Internet-Draft     Using One-Arm BFD in Cloud Network      November 2019
> 
> 
>    [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
>               (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
>               DOI 10.17487/RFC5881, June 2010,
>               <https://www.rfc-editor.org/info/rfc5881>;.
> 
>    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
>               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
>               May 2017, <https://www.rfc-editor.org/info/rfc8174>;.
> 
> Authors' Addresses
> 
>    Ruixue Wang
>    China Mobile
>    Beijing
>    CN
> 
>    Email: wangruixue@chinamobile.com
> 
> 
>    Weiqiang Cheng
>    China Mobile
>    Beijing
>    CN
> 
>    Email: chengweiqiang@chinamobile.com
> 
> 
>    Yanhua Zhao
>    ZTE
>    Nanjing
>    CN
> 
>    Email: zhao.yanhua3@zte.com.cn
> 
> 
>    Aihua Liu
>    ZTE
>    Shenzhen
>    CN
> 
>    Email: liu.aihua@zte.com.cn
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wang, et al.               Expires May 7, 2020                  [Page 5]
>