Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

Suresh Krishnan <suresh.krishnan@gmail.com> Tue, 14 November 2017 03:22 UTC

Return-Path: <suresh.krishnan@gmail.com>
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 3C09F128990; Mon, 13 Nov 2017 19:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ViZ_0ZaGI2xc; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B02F1242F7; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s2so14282268pge.10; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tNFKHABHncooQ3XRsgLFTOKPFteln/kgHfYPT4+xHdk=; b=GUt6QUnGZu4uq/hIlSXLjkGhcXHp95XLG4kqS+rsILxfNwns3MnIo6iD12yMIWJxBo UU61AbyNKQxnIkccIsc/fVkKb1xeZLJT0pOIwHjXNBfyTSebDIJksqNx4olNLrcNodZa Np0ULdRWsYWKpU820vg7rEjxihE/UUODuYD7+Xv9t15khVQyiztrNSbrGyiBkN8Dog5Y 0jPbjNyVLLmTuzyCBWay0rH1DTiaiA3bnqDDhK98VBHH+NXHYa7Zj0PTT9mRPzgwQMWs GEyg7MYPu+A2pMN9bJE2L7kmQyxzLtfKmG9hJiJPOvuI2coJMmwV6MXAXynZiWWx82/G siHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tNFKHABHncooQ3XRsgLFTOKPFteln/kgHfYPT4+xHdk=; b=H41RWCC6ezFcl3UjtiQBGCuFwByMI9KoZEkVmS0D5YVK0IH2jIQ+zbCGS/PiZp/Bxn EzqWnkREjV7NYqWKyz5o0+gUNvMNLxA9Xz1T80tAd4MJ0M+fQYW2N/dtwShXNx7RiiDm S0OCrP2WOP+++LT2UNSq+S4MgAdLw2nbSODfy2gE3Y+1G7eeTETH27apIKtGrnKW1t14 eHFHTCjb8oV38+3xFS6oJJPi5IiC2FM538dj7mZklun+buWdkYe4bzmtqX5Mr2nzfq4K 2Tki0hQXtnJBZpFgY6JrbF8o28L1C7+VSploGwOHKUbY3b/Rs18yqrTpvAdXDN/ORhqX j4Zw==
X-Gm-Message-State: AJaThX6fXQw+jLsyGur07Z1WB0jBJPdhqBuDHIgUiKeXJuj0TdPrOKJI gbYHC5KQKLh/4X8qMSvG0IrUeuTf5xs=
X-Google-Smtp-Source: AGs4zMYOr5Bl4E5HcfVEKXW98+YV+L93pJ9UMav+T7A4EaGdru9c83J9DATqxnFvWPIU+uvVpcojOg==
X-Received: by 10.99.170.66 with SMTP id x2mr10854917pgo.117.1510629769138; Mon, 13 Nov 2017 19:22:49 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:e88d:8fb9:5eb5:14b0? ([2001:67c:370:1998:e88d:8fb9:5eb5:14b0]) by smtp.gmail.com with ESMTPSA id a9sm21633499pff.31.2017.11.13.19.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 19:22:48 -0800 (PST)
From: Suresh Krishnan <suresh.krishnan@gmail.com>
Message-Id: <F762F88F-ABCE-4B91-BA75-66D464420AEE@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C560EE03-2FC3-4C6F-9BB3-A32150979E70"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Date: Tue, 14 Nov 2017 11:22:49 +0800
In-Reply-To: <AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280@AM5PR0701MB2836.eurprd07.prod.outlook.com>
Cc: Ted Lemon <mellon@fugue.com>, Mark Smith <markzzzsmith@gmail.com>, Fernando Gont <fgont@si6networks.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <AM5PR0701MB2836C00EA1AAC73E7E63F583E02B0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <CAO42Z2xacRco7ne7biQ93so0k-x4xSnM2jzoB13-sdVRLshQDQ@mail.gmail.com> <CAKD1Yr0Zz6Jxg_ZuEbBkMhBdEaZKOrtx-eUns7KWi9v-5PDBzg@mail.gmail.com> <CAO42Z2xqwRH94dw=XJf5mt3STdDcTYmB_i1NbXP46shdJQeaPA@mail.gmail.com> <E7F9E3EF-B5AA-4698-8BBC-772228129277@fugue.com> <AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280@AM5PR0701MB2836.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/k-RVElzgh9ByXeW_J75aLOW3KPk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 14 Nov 2017 03:22:52 -0000

Hi all,
  I would like to summarize the issues that have been brought up, along with my views (I apologize for the long mail but I think it is warranted in this case)

a) Changes were made to the draft after most of the IESG balloted on an older version of the document

Yes .This is an issue but hardly limited to this draft. I keep reading newer versions of the draft if I balloted DISCUSS and/or have some open issues that need to get resolved. After the issues are resolved, I do not usually read newer versions unless I am the shepherding AD for the document in which case I do. I spoke to some of the other ADs and their workflows are similar. This is something we need to discuss on the IESG in order to see how we can improve.

b) Mechanism does not work

Given that the mechanism has been implemented and deployed by the authors, I have a hard time taking this claim at face value. Providing an unique prefix per host has been standard practice in 3GPP mobile networks for the past *15 years*. based on recommendations from the IETF back at that time. When a mobile attaches, there is state created on the first hop router that does exactly what this draft wants to do. The only issue I see is a lack of mechanism to clean up stale prefixes if the hosts go away, but depending on the deployment this may or may not be an issue.

c) The document should be Informational and not BCP

Regardless of people claiming on this thread that the IESG chose this to be a BCP, it is the *v6ops WG* that decided to send this in as BCP. The document was IETF Last Called as BCP way before it even hit the IESG. Given that there is no objective guidance in RFC2026 on what constitutes a BCP (“best” and "what is believed to be the best way” are not exactly objective) we could go either way. I am inclined to go along with the wishes of the WG (v6ops), the shepherding AD (Warren) in the absence of a more definitive measure of suitability. That said, as I conveyed to Warren, I would not object if this was made Informational either.

d) Draft should have been done in 6man

Let me start off by stating that (AFAIK) there is no written agreement between 6man and v6ops as to the split of work. We have mostly used common sense to decide where things go. Specifically, if there have been bits-on-the-wire changes we have insisted that the work be done in 6man and this is certainly not the case for the document in question. I think this work is certainly pertinent to v6ops based on the following text in their charter

Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.

In closing, looking at where the document is in the publication cycle (It is in AUTH48 and it was probably an hour or so away from being published as an RFC), I think making major changes to the draft without a clear justification and WG consensus is not appropriate .

Thanks
Suresh

> On Nov 14, 2017, at 9:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
> 
> This may be a good moment to halt this discussion.
> The original reported finding that this draft makes protocol changes “making SLAAC statefull” has been found invalid.
> This means that there is no procedural issue caused by this draft.
>  
> AUTH48 process can now go forward as planned.
>  
> G/
>  
>   <>
> From: Ted Lemon [mailto:mellon@fugue.com] 
> Sent: Tuesday, November 14, 2017 09:46
> To: Mark Smith <markzzzsmith@gmail.com>
> Cc: Lorenzo Colitti <lorenzo@google.com>; Fernando Gont <fgont@si6networks.com>; v6ops@ietf.org WG <v6ops@ietf.org>; 6man@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
> Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
>  
> On Nov 14, 2017, at 3:43 AM, Mark Smith <markzzzsmith@gmail.com <mailto:markzzzsmith@gmail.com>> wrote:
> Why are we holding this document up on this?
> Half baked cakes aren't cakes, even though they may look like them.
>  
> FWIW, "we" aren't holding up this document.   It's in AUTH48.   The working group already has consensus on the document, the IESG has approved it, and at this point the only changes allowed are editorial changes that do not substantively change what the document says.   The working group has no agency here: this is entirely up to the authors and the AD.
>  
> If the authors or the AD were to make substantive changes to the document, that would be grounds for an appeal by the working group.
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------