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

"Naiming Shen (naiming)" <> Sun, 21 October 2018 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 531BC130DF7 for <>; Sun, 21 Oct 2018 15:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 NEpPmdGy630O for <>; Sun, 21 Oct 2018 15:35:49 -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 1C82A130DCD for <>; Sun, 21 Oct 2018 15:35:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=40274; q=dns/txt; s=iport; t=1540161349; x=1541370949; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Gtq0Nv6nTsJm9CXef5au8pGX3OHB0YG21sJ/YN5lGgI=; b=aGI21YpE1d1njmEBobYwlOTCU7yKUK74RRABd9C5Jximwgz/p4w3nlDT WPMZWjwjCDv5IpX2nyUKAZ6d/ObWPj0rNv0bCbus2ewsR+kY4N/N4YJ0W S0b+A3YefmrCfCClrqtA76RQlqsTQv6u07KKAla46C3hMxYYZY7akB25m k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,409,1534809600"; d="scan'208,217";a="188793217"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2018 22:35:48 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9LMZlFU022574 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Sun, 21 Oct 2018 22:35:47 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 21 Oct 2018 17:35:47 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Sun, 21 Oct 2018 17:35:47 -0500
From: "Naiming Shen (naiming)" <>
To: "Les Ginsberg (ginsberg)" <>
CC: "Reshad Rahman (rrahman)" <>, "" <>
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
Date: Sun, 21 Oct 2018 22:35:46 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_59DD4DA16C834D3D92E7B4271EB259E8ciscocom_"
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: Sun, 21 Oct 2018 22:35:51 -0000


On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) <<>> wrote:

Naiming –


From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) <<>>
Cc: Reshad Rahman (rrahman) <<>>;<>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

It probably should say “the payload size MAY be increased to this value and it is
not recommended for a BFD session to always use the large size packet for padding.
How frequent the large size packet being used is application specific”.

[Les:] This does not address the question as to why we want to use a mechanism specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

Since we already have a session between two end-points, a BFD session, why not utilize that
instead of having to explicitly configurae another ‘MTU discovery protocol’ session with burden
of configuration and management.

Since most of the application traffic does not fill the full size of the pipe to reach the MTU, so
this detection does not need to be sub-seconds, unlike normal BFD down we have to switch
the traffic immediately. MTU change can be detected by variing the BFD size say once
every minute (just like the BFD authentication proposal, once a while is sort of ok). Not knowing
the path MTU has changed for days is bad, but got notified in 2 minutes is good:-)

for the variety of encaps, the internal application probably can deduced from a
BFD one into their own as long as we have a number for path MTU.

[Les:] If “your” MTU requirements are smaller than “mine” – would you want the BFD session to go down even though you could continue to use the link successfully?

No, I think this document can also specify that, the BFD should not go “DOWN” if MTU has reduced, it should
only to be used as a ‘discovery’ mechanism ontop of the BFD itself. Say I’m sending large packets every 5 minutes
for 10 packets, this can be on top of the existing BFD schedule. It smaller packets still comes back to keep the
session alive. The big packets will give us the “indication” of extra data we have learned,

- Naiming


- Naiming

On Oct 20, 2018, at 5:14 PM, Les Ginsberg (ginsberg) <<>> wrote:

I have some concerns.

It has been stated that there is a need for sub-second detection of this condition – but I really question that requirement.
What I would expect is that MTU changes only occur as a result of some maintenance operation (configuration change, link addition/bringup, insertion of a new box in the physical path etc.). The idea of using a mechanism which is specifically tailored for sub-second detection to monitor something that is only going to change occasionally seems inappropriate. It makes me think that other mechanisms (some form of OAM, enhancements to routing protocols to do what IS-IS already does ☺) could be more appropriate and would still meet the operational requirements.

I have listened to the Montreal recording – and I know there was discussion related to these issues (not sending padded packets all the time, use of BFD echo, etc.) – but I would be interested in more discussion of the need for sub-second detection.

Also, given that a path might be used with a variety of encapsulations, how do you see such a mechanism being used when multiple BFD clients share the same BFD session and their MTU constraints are different?



From: Rtg-bfd <<>> On Behalf Of Reshad Rahman (rrahman)
Sent: Wednesday, October 17, 2018 6:06 PM
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

We have received an adoption request for “BFD encapsulated in large packets”.

The adoption call will end on Friday Nov 9th.

Please send email to the list indicating “yes/support”  or “no/do not support”. If you do not support adoption, please state your reasons.

Reshad & Jeff.