Re: BFD WG adoption for draft-haas-bfd-large-packets

"Reshad Rahman (rrahman)" <> Fri, 26 October 2018 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D6C4130DDE for <>; Fri, 26 Oct 2018 11:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZMPzP23ThkcH for <>; Fri, 26 Oct 2018 11:32:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3796C130E5B for <>; Fri, 26 Oct 2018 11:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3602; q=dns/txt; s=iport; t=1540578748; x=1541788348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EYnyLacCqwdDicmSm1O2nKJ2mfEFRdfKXjxbcPFsUE8=; b=YWavmKc/V14P9pAzqCDPAMBLHnQx9vw/EdASEaMk/nCTVFFvL3SH81U6 7zlIgnIPEa4PjbUboojLTmzRGHHn3g8SDu6lOcyR+DZ+jsTGu/NJhHcPf gVoNf1rBb5UM8A2dlXozXQcEQ208y4bShEEPMXpDhgedr1GILdWSVPBqw s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208";a="191697759"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 18:32:27 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9QIWRYl030325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 18:32:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 13:32:26 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 13:32:26 -0500
From: "Reshad Rahman (rrahman)" <>
To: Jeffrey Haas <>, "Les Ginsberg (ginsberg)" <>
CC: "Naiming Shen (naiming)" <>, "" <>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Topic: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Index: AQHUZn7F2obCS5tWFUCJRL2ls+mZdKUo1C+ggAHIywD//67wkIAAV7mA///Hi8CABg0XgIABf/0A
Date: Fri, 26 Oct 2018 18:32:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Oct 2018 18:32:33 -0000


Inline <RR>.

On 2018-10-25, 11:38 AM, "Jeffrey Haas" <> wrote:

    I *think* the following text is yours.
    On Mon, Oct 22, 2018 at 12:36:52AM +0000, Les Ginsberg (ginsberg) wrote:
    > [Les:] So, this has some implications:
    > We have both a transmit interval and a multiplier for a BFD session because we allow that some BFD packets may be dropped for reasons which do not represent a true loss of connectivity. Therefore up to N-1 consecutive packets may be dropped w/o triggering a session state change. If large BFD packets are “occasionally” inserted this means there are intervals during which N-2 packets drops (not counting the BFD large packet) would be sufficient to trigger a BFD session state change. Further, if the processing of the large BFD packets makes it more likely that subsequent BFD packets will be dropped (e.g., because the processing of the large BFD packet simply takes longer) then it is possible that a BFD session state change might be triggered simply as a side effect of the insertion of the large packet into the data stream.
    > You also are now defining a “child session” which is embedded within the parent session. BFD large packets are then not meant to influence the parent BFD session state and therefore have to be processed separately. This – in many ways – is equivalent to defining “another protocol”. I’ll grant it might be a bit simpler as it can inherit some things from the parent session – but it certainly is no longer simply a transparent part of existing BFD session operation.
    The draft I had previously worked on with Xiao Min discussing probing using
    BFD Echo had the concept of probes that would happen wherein the session is
    not torn down.  The example carries similarly with the "send occasional".
<RR> We discussed use of echo at IETF102. The large-packets draft mentions that echo can only be used for single-hop, hence the need for padding the control packets. But isn't single-hop Albert's main use-case? I believe we should add the echo option in the large-packets draft, it has the benefit that you get the desired functionality even if only 1 side of the WAN link supports echo. I realize not all implementations support echo so they might have to do pad control packets instead.

Reshad (no hat).
    I suggest taking a look at a different draft that might help direct this
    portion of the discussion:
    -- Jeff