Re: [dc] Requirement for a method to manage mac address in DC

Truman Boyes <truman@suspicious.org> Tue, 14 February 2012 01:38 UTC

Return-Path: <truman@suspicious.org>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A523821E802B for <dc@ietfa.amsl.com>; Mon, 13 Feb 2012 17:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEohH3SNFY0X for <dc@ietfa.amsl.com>; Mon, 13 Feb 2012 17:38:39 -0800 (PST)
Received: from mail.suspicious.org (research.suspicious.org [204.8.46.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3EB21E802C for <dc@ietf.org>; Mon, 13 Feb 2012 17:38:38 -0800 (PST)
Received: from [172.20.10.2] (43.sub-174-252-6.myvzw.com [174.252.6.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.suspicious.org (Postfix) with ESMTPSA id 590BC2290D; Mon, 13 Feb 2012 20:33:47 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Truman Boyes <truman@suspicious.org>
In-Reply-To: <201202131502.q1DF2lwo031814@cichlid.raleigh.ibm.com>
Date: Mon, 13 Feb 2012 20:38:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <7636F6E5-3A2F-4E87-8B78-C48CB572123B@suspicious.org>
References: <60C093A41B5E45409A19D42CF7786DFD522A9445A1@EUSAACMS0703.eamcs.ericsson.se> <201202130053.q1D0rggI051582@mse01.zte.com.cn> <60C093A41B5E45409A19D42CF7786DFD522A94465D@EUSAACMS0703.eamcs.ericsson.se> <4F38DD6E.6020807@cisco.com> <201202131502.q1DF2lwo031814@cichlid.raleigh.ibm.com>
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Apple Mail (2.1084)
Cc: dc@ietf.org, stbryant@cisco.com
Subject: Re: [dc] Requirement for a method to manage mac address in DC
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 01:38:39 -0000

On 13 Feb 2012, at 10:02 AM, Thomas Narten wrote:

> Stewart Bryant <stbryant@cisco.com> writes:
> 
>>> MAC conflict is perhaps true when vendors manufacture many NICs with 
>>> the same MAC
> 
>> Maybe  drivers should refuse to enable in the presence of
>> such a conflict?
> 
> That is what IPv6 effectively does, when stateless address autoconfig
> is done. If there are duplicate addresses, the interface shuts
> down.
> 
> You are pretty much guaranteed to get get duplicate IPv6 link-local
> addresses if there are duplicate MAC addrs in use.
> 
> But in a data center, I would not expect so much use of stateless
> autoconfig...  
> 
> Thomas


Really depends, you could quite easily use stateless autoconfig in data centers where the machines are designed for HPC or large compute farms where static addressing is too complex. SLAAC + DHCPv6 would fit the bill nicely. In this case, duplicate MACs would be pretty harmful to the whole idea of SLAAC. 

A lot of people have looked at Puppet / CFengine / or other automation technologies to do static IP addressing on DC machines, but we already have protocols to handle addressing, be it DHCPv6 or SLAAC.

Truman