Re: [v6ops] Please review the No IPv4 draft

"George, Wes" <wesley.george@twcable.com> Thu, 17 April 2014 12:41 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614DD1A012B for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 05:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.737
X-Spam-Level:
X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
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 Y34k_RqkpS2Q for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 05:41:58 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA831A0118 for <v6ops@ietf.org>; Thu, 17 Apr 2014 05:41:58 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,879,1389762000"; d="scan'208";a="273220079"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Apr 2014 08:41:27 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 17 Apr 2014 08:41:53 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Dale W. Carder" <dwcarder@wisc.edu>
Date: Thu, 17 Apr 2014 08:41:52 -0400
Thread-Topic: [v6ops] Please review the No IPv4 draft
Thread-Index: Ac9aOmkp2jmHcRmOTfGlMJ2uzfaBiA==
Message-ID: <CF75418B.1878F%wesley.george@twcable.com>
References: <534BF5A5.5010609@viagenie.ca> <20140415142103.GA50776@ricotta.doit.wisc.edu> <534D4D32.7080001@viagenie.ca> <489D13FBFA9B3E41812EA89F188F018E1AFE5ACB@xmb-rcd-x04.cisco.com> <CF72FB46.18429%wesley.george@twcable.com> <20140416144528.GA62773@ricotta.doit.wisc.edu>
In-Reply-To: <20140416144528.GA62773@ricotta.doit.wisc.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ruPgqgLphGoYAOl1wd7s9adeu08
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 12:41:59 -0000

On 4/16/14, 10:45 AM, "Dale W. Carder" <dwcarder@wisc.edu> wrote:


>Modern enterprise wireless controller
>networks are way, way more sophisticated than their wired counterparts
>due to the management of scarce RF time.  So, I don't buy any argument
>in this draft that there is a problem in this direction.

A fair point, but this extends beyond simply enterprise networks, and I’m
not willing to assume that all wireless networks will have a controller,
modern or otherwise. There are plenty of small and midsize networks that
are simply one or more APs all strung together on the same LAN. And given
how universally bad hotel and conference center networks usually are, I’m
skeptical that even those networks are consistently using a modern
controller, or if they are, it’s not set up particularly well. I don’t
know for sure whether DHCPv4 and related IPv4 junk traffic constitutes
anything more than a trivial amount of additional load on the RF if we
assume that the network is less than a certain size, but my thought was
that anything that contributes extra traffic on a network that is already
overloaded and performing poorly is something that should be removed if
reasonably possible. So I look at it as an opportunity for optimization if
we can come up with a way to do it that is worth the tradeoffs and
relatively transparent to network operators and users.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------



This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.