Re: BFD stability follow-up from IETF-91

"MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com> Mon, 08 December 2014 06:28 UTC

Return-Path: <mmudigon@cisco.com>
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 303B51A6F59 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 85d0j3XHJB_7 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:28:01 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1159E1A6F56 for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 22:28:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13232; q=dns/txt; s=iport; t=1418020081; x=1419229681; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bBzBFtuuf0satcN7egeFBBydZHY60HEJ0GbIu9Xbwx8=; b=gFKxfoKgSu8SGVyqxxCVpInzUuFr8GPgsfjBsbx3dyz3+Roc7Lmpnj+5 KfUNjM2MdFB9QXiTUOt/C5BUpoN1jtunHDOnQ5WtFuiUKxVeNnxiSOYB/ 40SE4jaQYVXuyOVwE883XL2XbUM6fazzlnueYzwmx89J3808xVOls1Etn E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFAIlEhVStJV2b/2dsb2JhbABQCoJDQ1JYBMNsiDkCgRwWAQEBAQF9hAIBAQEELUELEgEIEQMBAQEoJgIRFAkIAgQBDQWIJgMSzlwNhXUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjiKBUUsRBgGENgWGGIkuBYgrgWmBIowMgi+DYoNvb4FFfgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,536,1413244800"; d="scan'208,217";a="375240095"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 08 Dec 2014 06:28:00 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB86S0W6022819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 06:28:00 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 00:28:00 -0600
From: "MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Santosh P K <santoshpk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Subject: Re: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgABdKQD//6S3gIAAI96AgAAOuYCAAAYBAIAAAhWAgAWECQCAAAeGgIAAIrQAgAAERwCAAF25gA==
Date: Mon, 08 Dec 2014 06:27:59 +0000
Message-ID: <D0AB424E.28B01%mmudigon@cisco.com>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.143.25.106]
Content-Type: multipart/alternative; boundary="_000_D0AB424E28B01mmudigonciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LTJE_Mrn7YI_WETJzyGOS5B9XBs
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 06:28:03 -0000

Hi Greg,

Are we assuming that there is a single node in-between the sender and receiver for the multi hop case? The actual problem of packet loss may be happening after the next hop node. Since we don’t have a way to run echo for multi hop sessions, how do we identify packet losses in such a case if we use echo?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Date: Monday, 8 December 2014 11:52 am
To: Santosh P K <santoshpk@juniper.net<mailto:santoshpk@juniper.net>>, Manav Bhatia <manavbhatia@gmail.com<mailto:manavbhatia@gmail.com>>, Marc Binderberger <marc@sniff.de<mailto:marc@sniff.de>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD stability follow-up from IETF-91

Hi Santosh,
do you envision scenario when BFD multi-hop and single-hop sessions that share the same sender behave differently? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the network and thus is real, rather than in the BFD sender and more implementation specific. Thus running BFD Echo even without cooperation of the next hop node (no timestamps there) would give sender information about latencies BFD is subjected to in this node.

                Regards,
                                Greg

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91

Hello Mac and Manav,
     Are we just talking about singlehop? How about MPLS BFD and multihop where echo does not work?

Thanks
Santosh P K

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91

Hi Marc,



* 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.

For the echo mechanism to work, do you agree that you would have to continuously send Echos so that you can detect the issue?

Or are you suggesting that once BFD flaps we will start sending Echoes overloaded with debug information to detect the issue?

I'd like to understand this before the mailing list sees a barrage of emails. Alternatively, we can also take it offline and only report the summary of our discussion to the list.

Cheers, Manav