Re: BFD stability follow-up from IETF-91

Marc Binderberger <marc@sniff.de> Mon, 08 December 2014 03:32 UTC

Return-Path: <marc@sniff.de>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AFA1A1BA9 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 19:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ofrz9IVO0kkg for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 19:32:31 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356AD1A1BA5 for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 19:32:31 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0ABFD2AA0F; Mon, 8 Dec 2014 03:32:26 +0000 (GMT)
Date: Sun, 07 Dec 2014 19:36:10 -0800
From: Marc Binderberger <marc@sniff.de>
To: Manav Bhatia <manavbhatia@gmail.com>, Nobo Akiya <nobo@cisco.com>
Message-ID: <20141207193610211284.1f098741@sniff.de>
In-Reply-To: <CAG1kdoh5DwdKrJWK_aSvo4KQ6Xu5ZaTObe_PLhV66YZ4yQozmg@mail.gmail.com>
References: <CO2PR0501MB823C222B7D62779F4DF58CDB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <D0A647C1.28843%mmudigon@cisco.com> <CO2PR0501MB8234A1BDDFD008EE12C847AB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE38D@xmb-aln-x01.cisco.com> <CAG1kdogkUr2YyodeUPWOqea+2jqOkmdYnPywVHCw8j1+=9eM6A@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE4AE@xmb-aln-x01.cisco.com> <CAG1kdoh5DwdKrJWK_aSvo4KQ6Xu5ZaTObe_PLhV66YZ4yQozmg@mail.gmail.com>
Subject: Re: BFD stability follow-up from IETF-91
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: base64
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5ZWUPmZzezTq-HjDZTAFJcH_rnI
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Dec 2014 03:32:32 -0000

Hello Manav,

many emails on this thread - hard to follow up :-)

Anyway, several comments:

* if such a debug supports becomes informal, experimental or standard is IMHO 
irrelevant for it being actually implemented. As it looks like we talk about 
aspects that are implementation specific, e.g. when exactly a packet is 
timestamped, by hard- or software and so on, I have my doubt about a standard 
document though.

* Greg's echo idea is of course do-able - when you think timestamping in 
hardware can be done then it can be done in the forwarding path for echos as 
well. Depends on your hardware :-) and on an agreed (minimal) format for 
echo. As mentioned BFD echo is not defined/used for multiple BFD features, 
which limits it's use though.

* the local timestamps cannot create an interop problem as they are _local_ 
and not exchanged :-) A stability draft could define the minimum requirements 
we have for what timestamps should be (locally) collected. For interop all 
that is needed is an agreement on the "ID", i.e. the sequence number, 
encoding in the packet.


Regards, Marc







On Thu, 4 Dec 2014 20:52:17 +0530, Manav Bhatia wrote:
> Hi Nobo,
> 
> The echo proposal doesnt make any sense. I thought the one with carrying 
> some info as part of the the UDP or the IP payload made some.
> 
> Having spent countless number of hours debugging a "BFD flap" i would 
> definitely like to have a std-track mechanism that aids me in debugging the 
> root cause.
> 
> Cheers, Manav
> 
> On Thu, Dec 4, 2014 at 8:44 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
>> [no hat on, btw]
>>  
>> Hi Manav,
>>  
>> If what you say is the only requirement not met, one approach may be to 
>> pursue a non-standard-track document describing some suggested 
>> implementation techniques to locally store TX/RX timestamp.
>>  
>> Given that echo approach will be less accurate and given that we seem to 
>> be having difficulty converging, I thought I’ll throw out another idea.
>>  
>> Thanks!
>>  
>> -Nobo
>>  
>> From: Manav Bhatia [mailto:manavbhatia@gmail.com] 
>> Sent: Thursday, December 04, 2014 9:53 AM
>> To: Nobo Akiya (nobo)
>> Cc: Santosh P K; MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan 
>> (venggovi); Gregory Mirsky; Marc Binderberger; rtg-bfd@ietf.org
>> Subject: Re: BFD stability follow-up from IETF-91
>>  
>> Nobo - Locally storing TX/RX timestamps is not interoperable.
>>  
>> Cheers, Manav
>>  
>> On Thu, Dec 4, 2014 at 7:30 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
>> A quick question to understand where we are.
>>  
>> If we had:
>>  
>> 1.      Standardization of Null Authentication (i.e., sequence numbers)
>> 2.      Implementation of local TX/RX timestamp mechanism described by 
>> Marc below
>>  
>> What are the core requirements which have not been satisfied?
>>  
>> Thanks!
>>  
>> -Nobo
>>  
>> P.S. No, there is no need to standardize BFD echo contents.
>>  
>>>  
>> 
>