Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed]

Keith Moore <moore@network-heretics.com> Fri, 18 November 2011 03:25 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4533711E80A5 for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 19:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.35
X-Spam-Level:
X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 uOWSaUIktWl4 for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 19:25:45 -0800 (PST)
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 86CEF11E8097 for <mif@ietf.org>; Thu, 17 Nov 2011 19:25:45 -0800 (PST)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 40AC220E3B for <mif@ietf.org>; Thu, 17 Nov 2011 22:25:45 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 17 Nov 2011 22:25:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=/PX 4FQYhJO+kZTr6xFWfApZSG/A=; b=p8vUNjn05PBqguESsiOLl8MzMWiz2AExDA/ jaCHV9+t8kJ3yfs/q4/PZY1AijjP7H47kAbsu/OT746Bzgrl9Op7P0sCMO2o8bqG Ere+su+TO7QIL17u5CdvKGGxscW63HSLiKH/VRup8KmFpXCXm2MJzvbLJFFDCZva oz9OgIeo=
X-Sasl-enc: ZTAKkoU6mvj32Akq8MsPtGv1kG48pEdqBNo0mF26g54K 1321586744
Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 268568E013E; Thu, 17 Nov 2011 22:25:44 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-183--317840142"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4EC5B720.8020605@gmail.com>
Date: Thu, 17 Nov 2011 22:25:43 -0500
Message-Id: <005FBBC0-A025-4282-B7CF-3A37845135C0@network-heretics.com>
References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed]
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2011 03:25:46 -0000

On Nov 17, 2011, at 8:38 PM, Brian E Carpenter wrote:

> Operators say that they want (approximate) feature parity so
> that they can have (approximate) alignment between their
> operational procedures for v4 and v6, especially in a dual stack
> network. I assert that this is a very good engineering reason,
> and it isn't for the IETF to get on its high horse and say that
> experienced operators don't know how to manage OPEX.

I agree that it's a good engineering reason, but it's not the only factor that should be considered.   A number of things were broken in IPv4, and we'd like to not have those things become permanently a part of the architecture.

On the other hand, second-system effect is arguably one of the factors that has delayed adoption of IPv6.   We need to be aware that change comes with a cost, even if it seems like a change for the better.   That doesn't mean to never make changes, it means consider the cost when considering whether to make a change.

Keith