RE: [bmwg] Updates to MPLS Protection Meth/Term draft- Requestforcomments/review

"Jay Karthik \(jakarthi\)" <jakarthi@cisco.com> Sat, 10 March 2007 02:58 UTC

Return-path: <bmwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPrmm-0004MZ-Oa; Fri, 09 Mar 2007 21:58:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPrml-0004MU-Ls for bmwg@ietf.org; Fri, 09 Mar 2007 21:58:19 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPrmk-0001Mx-CB for bmwg@ietf.org; Fri, 09 Mar 2007 21:58:19 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2007 21:58:18 -0500
X-IronPort-AV: i="4.14,269,1170651600"; d="scan'208"; a="115298854:sNHT50118032"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2A2wIdk001726; Fri, 9 Mar 2007 21:58:18 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2A2wHZn000652; Sat, 10 Mar 2007 02:58:17 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 21:58:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [bmwg] Updates to MPLS Protection Meth/Term draft- Requestforcomments/review
Date: Fri, 09 Mar 2007 21:55:53 -0500
Message-ID: <8983EC086A9D954BA74D9763E853CF3E02DE18D6@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <B107F3933E266542AA79CA90C1C95E1D01A5A678@wsgpmb01.sgp.agilent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [bmwg] Updates to MPLS Protection Meth/Term draft- Requestforcomments/review
thread-index: AcdiAaYtW63KhAjGRnSHOjwxwOrKQAAvISqA
References: <B107F3933E266542AA79CA90C1C95E1D01A5A678@wsgpmb01.sgp.agilent.com>
From: "Jay Karthik (jakarthi)" <jakarthi@cisco.com>
To: cary_wright@agilent.com, bmwg@ietf.org
X-OriginalArrivalTime: 10 Mar 2007 02:58:17.0806 (UTC) FILETIME=[F42AA6E0:01C762BF]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2977; t=1173495498; x=1174359498; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jakarthi@cisco.com; z=From:=20=22Jay=20Karthik=20\(jakarthi\)=22=20<jakarthi@cisco.com> |Subject:=20RE=3A=20[bmwg]=20Updates=20to=20MPLS=20Protection=20Meth/Term =20draft-=20Requestforcomments/review=20 |Sender:=20 |To:=20<cary_wright@agilent.com>,=20<bmwg@ietf.org>; bh=h3oEJbV/UlhT4sQu6Eqa5zoB691ycL2N2oHCyBL/9XE=; b=aG3WAovZ8txxJR5AtI7aMyAjhA1BClW7Do7OMsvK+9lHZ48kdthzgxWY8yZtqEQiRB8t72Kr YgTRZfNkFoGGxyzLLBQCL5fel5YarJpRtM9HLoMTI7QyPcG2uJoFFFHf;
Authentication-Results: rtp-dkim-1; header.From=jakarthi@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc:
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
Errors-To: bmwg-bounces@ietf.org

Thanks Cary. 

1 ms sounds like a reasonable sampling interval for MPLS Protection
Benchmarking. Let's get a consensus on whether this interval is adequate
or too aggressive for a 'Testing Tool' from others on the list as well.
We'll include this question as an open issue for the presentation in
Prague and request feedback from the working group.

Cheers,
Jay  
 

________________________________

	From: cary_wright@agilent.com [mailto:cary_wright@agilent.com] 
	Sent: Thursday, March 08, 2007 11:16 PM
	To: bmwg@ietf.org
	Subject: RE: [bmwg] Updates to MPLS Protection Meth/Term draft-
Requestforcomments/review 
	
	
	I'd like to comment on the questions posed below.
	 
	Using accurate packet timestamping mechanisms it is feasible to
measure data plane convergence much more accurately, modern measurement
tools have timestamp resolution down to 10ns resolution. When using
packet timestamps, the resolution and accuracy of a convergence or
switchover measurement will be mostly limited by the packet frequency on
the link. 1,000,000 packets per sec will provide a resolution of 1us for
a data plane convergence measurement if packet timestamps are used,
requiring about 50% of a GbE link's available bandwidth. 
	 
	I believe 1ms is an appropriate sampling interval for data plane
switchover and convergence tests. This is feasible in most scenarios,
and better matches the high availability expectations of modern
services.
	 
	Regards,
	Cary Wright
	 
	________________________________

			*	To: <bmwg at ietf.org
<mailto:bmwg@DOMAIN.HIDDEN> > 
	*	Subject: RE: [bmwg] Updates to MPLS Protection Meth/Term
draft- Request forcomments/review 
	*	From: "Samir Vapiwala \(svapiwal\)" <svapiwal at
cisco.com <mailto:svapiwal@DOMAIN.HIDDEN> > 
	*	Date: Thu, 8 Mar 2007 09:28:28 -0500 
	 
	Further to Rajiv's earlier email we as MPLS Protection
benchmarking Author team would like to seek input to the following
unaddressed items on the mailing list so that we can get closure on
these open items prior to the BMWG meeting:
	 
	 Since the packet smapling interval recommended in the
"draft-ietf-bmwg-igp-dataplane-conv-meth-12.txt,  section 3.2.5
Convergence Time Metrics" may not be applicable to the MPLS FRR scenario
where failover times have to be below 45ms, here are some of our
thoughts or questions to the list: 

	1.	We would like to adapt similar approach the IGP
convergence as this defiinition applies to current work item 
	2.	We feel that 100ms is large for MPLS FRR application,
under which the target is always keeping the failover times below 45ms. 
	3.	We are considering changing this number to 10ms, and
would expect test tool to offer this smapling interval

	Please provide your input to this suggested value so that we can
have a conclusion before the next meeting.
	 
	 
	Regards,
	 
	MPLS Protection Benchmarking Author Team

_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg