Re: Service Identity (Re: Machine Identity)

Jeroen Massar <jeroen@unfix.org> Thu, 28 February 2008 14:55 UTC

Return-Path: <discuss-bounces@ietf.org>
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267AD3A6EA3; Thu, 28 Feb 2008 06:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTQTMgHz4KCS; Thu, 28 Feb 2008 06:55:43 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAC03A6B6E; Thu, 28 Feb 2008 06:55:43 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED163A6B6E for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 06:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-BR+sBZq3cI for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 06:55:37 -0800 (PST)
Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id C495A3A6999 for <discuss@apps.ietf.org>; Thu, 28 Feb 2008 06:55:36 -0800 (PST)
Received: from [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 1B1DE40202D; Thu, 28 Feb 2008 15:55:27 +0100 (CET)
Message-ID: <47C6CB64.9060704@spaghetti.zurich.ibm.com>
Date: Thu, 28 Feb 2008 15:55:32 +0100
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
Subject: Re: Service Identity (Re: Machine Identity)
References: <20080226130527.GA1404@generic-nic.net> <20080228112318.GA23196@nic.fr> <20080228114656.GD8439@elstar.local> <Pine.SOL.4.64.0802281405360.10117@kekkonen.cs.hut.fi> <20080228124038.GA8852@elstar.local><47C6B37F.2050505@ericsson.com> <47C6BA02.9090000@spaghetti.zurich.ibm.com> <0aea01c87a12$95cc8df0$0600a8c0@china.huawei.com>
In-Reply-To: <0aea01c87a12$95cc8df0$0600a8c0@china.huawei.com>
X-Enigmail-Version: 0.95.6
OpenPGP: id=333E7C23
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig477BB6741DE8E7B70B3301B3"
X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on abaddon.unfix.org
X-Virus-Status: Clean
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@ietf.org>
List-Help: <mailto:discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=subscribe>
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org

David Harrington wrote:

> In SNMPv3, we developed an identifier to identify each engine, but
> users actually prefer to model the network topology using the IP
> address, because when dealing with topology maps the purpose is to
> manage the devices in the network. 

With this whole identity stuff, people have to change their thinking and 
start thinking outside the box (buzzzzzzzzzzzzzzzzz-word :)

IP is great for talking from A to B. Once A and B where hosts, now they 
generally are virtual hosts, or even only a service.

As such the "IP" here is a reasonable ID, as it represents the service.

> If a device catches fire, you don't want to search through diagrams of
> virtual services; you want to know where the device is so you can put
> the fire out. ;-)
> 
> As Juergen said, which identifier works best depends on what you are
> trying to do, and no single identifier will always be the best choice.

It always depends on what you want to do, I fully agree, but for your 
example the "SNMP service" you will be looking at are 2 services:

  - cpu load, memory usage etc, on the virtual device
    => this is "SNMP service on vhost X"

  - temperature, harddisk status etc on the physical host
    => this is "SNMP service on physical host Y"

Those are two different services, not one, but two, and probably more.

Most very likely vhost X has a different IP from host Y, thus using IP's 
here is one way to go. The problem comes when the IP changes, your 
service is still the same, but you based your ID on something which is 
not a stable identifier.

This is of course also all a similar problem with Multihoming and 
Mobility etc. One day you are IP X the other moment you are IP Z.

The real way to solve this is the Identity layer, and HIP provides just 
that.

Greets,
  Jeroen