[nmrg] Comments on autonomic use cases

Joe Marcus Clarke <jclarke@cisco.com> Thu, 06 March 2014 15:55 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: nmrg@ietfa.amsl.com
Delivered-To: nmrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF01A00AE for <nmrg@ietfa.amsl.com>; Thu, 6 Mar 2014 07:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 23fO7Q76qB24 for <nmrg@ietfa.amsl.com>; Thu, 6 Mar 2014 07:55:52 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 96F581A013E for <nmrg@irtf.org>; Thu, 6 Mar 2014 07:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1394121349; x=1395330949; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=2meFDWCQNt21M3uV/P8UdUey3/BSDo7c+rg6RqMwHB0=; b=Rap4VtoL2dPhkY9j3Buem9/DaGBnwuoc0zoiKoUAGriorgwrymfdWqtS 0J8QNKf84f8yyarpJaJoW6JzPyvUJHlnhBOZ03DHA9f5/Y3ohwhZ2nxsT /zDzvyG+/+ii3s7HsayrET4ignee2n/aDZy3wNvMbvLs9gjqxPx4fWnYO w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAOmZGFOQ/khN/2dsb2JhbABagwbDSRZ0gmR9NAJZCAEBh3WfJ7AOF454hCIEiUyOcoZKi2GDSx4
X-IronPort-AV: E=Sophos;i="4.97,601,1389744000"; d="scan'208";a="7461991"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 06 Mar 2014 15:55:48 +0000
Received: from [10.82.247.40] (rtp-vpn2-1829.cisco.com [10.82.247.40]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s26Ftk20022891 for <nmrg@irtf.org>; Thu, 6 Mar 2014 15:55:47 GMT
Message-ID: <53189A82.80404@cisco.com>
Date: Thu, 06 Mar 2014 10:55:46 -0500
From: Joe Marcus Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: nmrg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/nmrg/sRl076KwPwyH4KX_A2nz71FClgY
Subject: [nmrg] Comments on autonomic use cases
X-BeenThere: nmrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Management Research Group discussion list <nmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nmrg>, <mailto:nmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/nmrg/>
List-Post: <mailto:nmrg@irtf.org>
List-Help: <mailto:nmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nmrg>, <mailto:nmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 15:55:54 -0000

After listening to the talks today, I have an overall comment related to 
network traceability in an autonomic environment.  I was very intrigued 
by Laurent's talk as I have been doing work in this area using Cisco 
embedded automation.  I strongly feel that we should be doing more 
autonomic cross-device analysis of problem conditions to do smart 
rerouting in the case of instability.  For example, in addition to local 
factors like temperature and load, we could look at path or hop 
stability in terms of dropped packets along a flow, jitter, latency, 
etc. and determine a new optimum/stable path.

Additionally, with respect to the troubleshooting section in 
draft-jiang-nmrg-an-gap-analysis-00, I think there is something that can 
be done autonomically relating to hardware failure.  Given Laurent's 
ideas again, a device that can detect imminent failure (e.g., SMART-like 
operations on harddrives), and make proactive changes to the network to 
reroute around an impending hardware failure until humans can get 
involved.  This can prevent extended outages.  Perhaps this is something 
that could supplement this section of text.

Joe