Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 25 November 2013 19:31 UTC

Return-Path: <brian.e.carpenter@gmail.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 AC9011ADF8F for <v6ops@ietfa.amsl.com>; Mon, 25 Nov 2013 11:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 ob-Q_FBmUeAG for <v6ops@ietfa.amsl.com>; Mon, 25 Nov 2013 11:31:37 -0800 (PST)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4973D1ADBCB for <v6ops@ietf.org>; Mon, 25 Nov 2013 11:31:37 -0800 (PST)
Received: by mail-pb0-f50.google.com with SMTP id rr13so6436469pbb.9 for <v6ops@ietf.org>; Mon, 25 Nov 2013 11:31:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QG8DjpKxBc4SJycG9ZBm1paRlAxYOqqlvS0L6FgqDYw=; b=KaMI1rBvOQMMpZP6m371jWUbe1lo/Onkfk2NVyyByYi+jR6Qa+LYiWciGIaFWkpk+D fNKOTQB5NYn8853ec0vV+6sxWUy9QRuhaWlMAkgF0ieCddQU76+5sZVBT5wJfDKH04Qs gXsg2/lyfgYSzxK0UIkicrB1u1qJW4BcVKgh3N+Z2/Gtjds+K58JRHvlBgrAItHfQZ7K /2xgiAq+xqUi7EDh3huqK63FNGV5/L99b8PB1hQqGKeaibdJjds9lMOoUedPiEo7hiym RIKZB70fvBFdO6uVJpKCEusy9rvXDiHFgt8lXLf3g2aWPZ4FS84XpyM4GGQNzLFGEszk gv1g==
X-Received: by 10.68.251.133 with SMTP id zk5mr19610973pbc.69.1385407897405; Mon, 25 Nov 2013 11:31:37 -0800 (PST)
Received: from [192.168.178.20] (34.192.69.111.dynamic.snap.net.nz. [111.69.192.34]) by mx.google.com with ESMTPSA id gv10sm69279667pbd.0.2013.11.25.11.31.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 11:31:36 -0800 (PST)
Message-ID: <5293A596.2000304@gmail.com>
Date: Tue, 26 Nov 2013 08:31:34 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
References: <20131122183301.9E61C75E017@rfc-editor.org> <3135C2851EB6764BACEF35D8B495596806FB9EED1D@MOPESMBX01.eu.thmulti.com> <CAJc3aaPmsxTewQFznXo1GMao_pEpGicqoGk6ijfBjHOW-6sovw@mail.gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EEDED@MOPESMBX01.eu.thmulti.com> <OF1909BE08.00E4773F-ON85257C2E.004E2BAB-85257C2E.004F6601@videotron.com> <3135C2851EB6764BACEF35D8B495596806FB9EEF39@MOPESMBX01.eu.thmulti.com> <CAJc3aaPcfnsE0RgrZnxAh3U=iGRs4NCxsQr62r0EFiW53x0VOQ@mail.gmail.com> <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com>
In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB9EEFC9@MOPESMBX01.eu.thmulti.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers
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: Mon, 25 Nov 2013 19:31:38 -0000

On 26/11/2013 04:03, Wuyts Carl wrote:
> Hi Victor,
> 
> Agree.  I do always recommend our customers to assign /56.  This doesn't mean it is always being deployed like this of course, we have single /64s as well.  But this is better for the sake of future proof and leaves some room for expansion without having to fiddle in the back-end to aggregation etc.
> The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have public wifi, mostly not, etc.  It just makes customers asking questions on it, as they base themselves upon this RFC to send their reqs to CPE vendors.  Moreover, too small (too big too ??) is too much subject of interpretation.

If I'm implementing a device and the spec includes a SHOULD, I will read the
definition of SHOULD:

"SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

In the case in point, if I am unable to determine whether the
delegated prefix is too "small" to address all interfaces,
that is clearly a valid reason to ignore the requirement.
Therefore, I don't see this as a formal defect in WPD-3.

I think it's true that in many cases, the CPE will be unable to
determine whether the prefix is too "small". Also, if there happens
to be a subsidiary router hanging off one of the interfaces, it might
want a whole bunch of prefixes, and the CPE router can't possibly
know that in advance.

Also, "small" in this case turns out to mean "long".

WPD-3 could have been better phrased, but since product development
managers have never met a SHOULD that they couldn't ignore,
I doubt that it really matters.

    Brian