Re: [v6ops] draft-ietf-v6ops-design-choices-09 quick review :)

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 01 November 2015 22:01 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 942341AC3C4 for <v6ops@ietfa.amsl.com>; Sun, 1 Nov 2015 14:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.231
X-Spam-Level:
X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 NZem_-Sdn5Hu for <v6ops@ietfa.amsl.com>; Sun, 1 Nov 2015 14:01:33 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9E51AC3C1 for <v6ops@ietf.org>; Sun, 1 Nov 2015 14:01:33 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tA1M1UxV020550 for <v6ops@ietf.org>; Sun, 1 Nov 2015 22:01:30 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk tA1M1UxV020550
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1446415291; bh=ajGVmqmGr6YWGOnG5tfmnuQcNsQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=OJHvihPpeiRqRUfsd4IZ0wuo2N2lOD6icQq4mbPNR/tyTj2WzfMHmzDd34ULSBsse m/Z6MMKnXDPGGPReVFdFTui7ZaQdm77gFcUk9C+HdShGYgG53CeDQbUDcCBE2cpO5z tOguTEsUzfCjCo9AYYRPsSEp3dgzNpgs8WqQ5Z84=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id rA0M1U1860229185vm ret-id none; Sun, 01 Nov 2015 22:01:30 +0000
Received: from [192.168.0.10] (tchowndsl.claranet.co.uk [212.188.254.49]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id tA1M1QFM008060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <v6ops@ietf.org>; Sun, 1 Nov 2015 22:01:26 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <56340C02.7040505@go6.si>
Date: Sun, 01 Nov 2015 22:01:25 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|47c6d6c21f93656b81d7b520f3af05abrA0M1U03tjc|ecs.soton.ac.uk|AE20A382-709F-402C-90B6-881342ED2427@ecs.soton.ac.uk>
References: <56340C02.7040505@go6.si> <AE20A382-709F-402C-90B6-881342ED2427@ecs.soton.ac.uk>
To: v6ops list <v6ops@ietf.org>
X-Mailer: Apple Mail (2.3096.5)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=rA0M1U186022918500; tid=rA0M1U1860229185vm; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: tA1M1UxV020550
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/cmgaoK99m-Yt2Wg98m0JqU8Lj-w>
Subject: Re: [v6ops] draft-ietf-v6ops-design-choices-09 quick review :)
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 01 Nov 2015 22:01:36 -0000

Hi,

I also put my hand up alongside Jan to take a look at the -09 version when it came out.

Overall, I think the document is pretty close to being ready. It contains a lot of useful information and guidance. Indeed, while Informational, some parts are clearly documenting BCP. It’s certainly worth publishing.

Some comments:

The title of the document might now better be “Routing-Related Design Choices for IPv6 Networks”?

The introduction defines the scope of the document well, and gives useful pointers to topics not covered in the text.

There is an exception to this though - the introduction says ULAs (and address plans) are covered elsewhere (ULAs specifically in Sheng’s draft) but then dives into ULAs anyway. There’s some mixing here of "IPv4 thinking", e.g. “for an enterprise, the use of private address space is an option and may be seen as favourable operationally”, which may be the case in existing IPv4 networks, but for IPv6, if PI/PA is not recommended, or ULAs alongside PI/PA, there should be very clear guidance why not, and perhaps that is better handled in Sheng’s draft. We also danced around this topic in RFC 7381, but ended up punting to Sheng’s document. Perhaps the same should be done here?

I also found the PI/PA/Private table confusing. Perhaps it should come after the text explaining it? Even then, it might be formulated better.

The discussion of IGPs, and the hint of the result of an informal poll on IGPs, was interesting and useful.

The summary of the general themes at the end might be better placed in the introduction, to put them in the reader’s mind for the subsequent text?

Tim

> On 31 Oct 2015, at 00:32, Jan Zorz <jan@go6.si> wrote:
> 
> Dear WG, authors...
> 
> As promised I did a quick review of draft-ietf-v6ops-design-choices-09. I apologize for late review submission, but the -09 version came out just days ago ;)
> 
> I'm not entirely happy with the ULA discussion on pages 5 and 6, but at the end you (let's say so) adequately underline the fact that folx need to strongly reconsider using ULAs in their networks. Not strong language and message enough for my personal taste, but let it be.
> 
> Section 2.2.1:
> 
> Option b) is feasible choice for servers in data centers because of numerous reasons - security (each server on separate /64), measurements and others. Maybe you should mention this in the text. Endpoint host has no need for that.
> 
> Section 2.2.2:
> 
> Hopefully you are talking just about L3 interfaces on routers. There is no clear and visible clarification of that as just "Interface" notion is used ;)
> 
> End hosts also have interface and should not even think about that ;)
> 
> Page 11:
> 
> You can carry IPv4 also in OSPFv3 this days, so additional option would be OSPFv3/OSPFv3
> 
> See you all at v6ops WG meeting in few days ;)
> 
> Cheers, Jan
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops