Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

David Farmer <farmer@umn.edu> Wed, 22 February 2017 19:24 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BC1297B8 for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 11:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 vNJ4juaFT8Qi for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 11:24:57 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DC1129A69 for <ipv6@ietf.org>; Wed, 22 Feb 2017 11:24:56 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 3390A290 for <ipv6@ietf.org>; Wed, 22 Feb 2017 19:24:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1XJMl7XXSKE for <ipv6@ietf.org>; Wed, 22 Feb 2017 13:24:56 -0600 (CST)
Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 006B3B4D for <ipv6@ietf.org>; Wed, 22 Feb 2017 13:24:55 -0600 (CST)
Received: by mail-qt0-f200.google.com with SMTP id 42so8604463qtn.2 for <ipv6@ietf.org>; Wed, 22 Feb 2017 11:24:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N5i+ZN2KMqrnBpL5uHZ+34m+vXA4ndQDZKBRFtoMIi0=; b=o3Qqz7asdhjRbMi8FVR0q9uNHesWCPpgvk0DlmU3x+Es8Lhte5cilNla3WViwjgDm8 714doPCu+p86x1bPLYuIcHUk4Dlv6iTFPcq8L6wMBvgCWxRYxEzlNKnKrot4mNZOTfsp mYeBS/i6iLuOWKXQR1u2cVO3hvdOfHaOjx/ymJ0fTKnLxeAFEtQat/DDZW4A21AomZiJ U+mGS7iqfjg97tSbDrpOiP4Q6kLMzI2fDcz8XtSQaPP1qPczREIZEqpm2c4/0U1S0NIK jastn3swweaNqfigeR6m2JV8dqeI4DsrvtRGK3InMolMrOO9MjWibAR33w4Fm54NRdS5 +xCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N5i+ZN2KMqrnBpL5uHZ+34m+vXA4ndQDZKBRFtoMIi0=; b=enh19MAC23avdKUHXjyB2MgQ3smZojcxHVV6rjNeNtb/zf6XEVWaaU6C4ON3JUq/Zn y4gZrKEfICoNrZ2DAEcSYfdme5TSWLU9Thqwwx+GZfeH6TpGVXXSFZKxNuclDlDCxvr+ KmqMLh0bRoRMkQnI4XrbDXVF3wyhjocj9BKlhHr3c7fxEzIFy0QSzTvZuD6roJmUgX64 xhEo1fBjTnDyPN0YxYeev6hp4B1zBH1uyhbxHNYOLSM6OwEm2DQjokxp4FphQ15VmvVz /xSCwEIU1umMFylORb1Rki3dRTFOViTrS4yILbnmi3/ogNonID3KH+vz/VHIt/5Ya+cw H7cg==
X-Gm-Message-State: AMke39lwpmbHszt8BHGhFoMUDIqTZxP3hTn6FBjsjDcArb9CCx5rMByaeXUCdowVpfjFxTXmhGiAShvRuGfhV3KiIJFDiwD2fSbu0twu428j+QVdwc9dWL7wog+KSoRuBbPjj8/OROlFli3US1I=
X-Received: by 10.55.39.147 with SMTP id n141mr17222657qkn.103.1487791495455; Wed, 22 Feb 2017 11:24:55 -0800 (PST)
X-Received: by 10.55.39.147 with SMTP id n141mr17222638qkn.103.1487791495255; Wed, 22 Feb 2017 11:24:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.41.83 with HTTP; Wed, 22 Feb 2017 11:24:54 -0800 (PST)
In-Reply-To: <CAKD1Yr0F0e7CbieLr4+7mMJ7xZXponPS+5-nbcDWh_dRP7wR9w@mail.gmail.com>
References: <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org> <20170220235734.GA84656@Vurt.local> <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com> <20170221172739.GT84656@Vurt.local> <CAO42Z2xEqnz4=E7JDOA_FCg_RxkMuZgnBc3KuaxwY1oZryed9g@mail.gmail.com> <20170221202821.GB32367@Vurt.local> <CAO42Z2yK_rZksa4xQkuW8Q_hwaitH610m6kVBmFisN7toaSoPw@mail.gmail.com> <CAKD1Yr3pNBCNFRkZiDYoOp7CDDG-4pbuzkLW8UeJB_bbS7QEWw@mail.gmail.com> <CAN-Dau1e0uac2qkxW-6xk-ToYROw6ipkQV3RjtMqFm6RuWq0EQ@mail.gmail.com> <CAKD1Yr0F0e7CbieLr4+7mMJ7xZXponPS+5-nbcDWh_dRP7wR9w@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 22 Feb 2017 13:24:54 -0600
Message-ID: <CAN-Dau0iYOD-WLq7J_23M3oZKiBTTKV-jbsG+WTZ7GYNABwD-A@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary="94eb2c095c7e93437305492373e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QpITBamTDUYTA_Fth3SLEaMb-iI>
Cc: 6man WG <ipv6@ietf.org>, IETF <ietf@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 19:24:58 -0000

I'm perfectly fine with "should be" or even "almost alway", but that's not
"required", "must be", or "always", just like 5 - 9s uptime isn't never
have an outage.  And yes you still need to deal with that 0.1% or 0.0001%
in the case of 5 - 9s, there is no way off that hook.

On Wed, Feb 22, 2017 at 12:04 PM, Lorenzo Colitti <lorenzo@google.com>
wrote:

> From a complexity, reliability, and cost point of view, it is likely
> better to say that everything should be /64 rather than say that 99.9% of
> links will be /64 or /128 but we still need to support other prefix lengths
> for 0.1% of cases.
>
> On Thu, Feb 23, 2017 at 3:01 AM, David Farmer <farmer@umn.edu> wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 11:46 AM, Lorenzo Colitti <lorenzo@google.com>
>> wrote:
>>
>>> On Thu, Feb 23, 2017 at 2:42 AM, Mark Smith <markzzzsmith@gmail.com>
>>> wrote:
>>>
>>>> Let's leave behind unnecessary practices that have been used to extend
>>>> IPv4's life, and that make things unnecessarily complicated and more costly
>>>> to operate and troubleshoot.
>>>>
>>>
>>> What he said.
>>>
>>
>> Yes, what he said is a very compelling argument to use /64 in most
>> places, the default. However, you cannot extrapolate there exists no places
>> were something other than /64 make sense.
>>
>> --
>> ===============================================
>> David Farmer               Email:farmer@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
>> ===============================================
>>
>
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================