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

Fernando Gont <fgont@si6networks.com> Sat, 11 November 2017 03:08 UTC

Return-Path: <fgont@si6networks.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 06344128D2E; Fri, 10 Nov 2017 19:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 io1Eqbu0SPKS; Fri, 10 Nov 2017 19:08:38 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5AC1200C1; Fri, 10 Nov 2017 19:08:38 -0800 (PST)
Received: from [172.19.248.110] (unknown [57.190.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CB70D82759; Sat, 11 Nov 2017 04:08:25 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Joe Touch <touch@strayalpha.com>, james woodyatt <jhw@google.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" <v6ops-ads@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <BBB987EF-D91C-4FD1-9084-21382F24E7BF@gmail.com> <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <52C752BD-2347-4704-9103-89BD979D7C2D@google.com> <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <ae36072e-5cf3-1bd3-88ed-bf1d3d0f6507@si6networks.com>
Date: Sat, 11 Nov 2017 00:10:09 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fs8wxyM2TqrtWRRvCVbZeFbxyck>
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: Sat, 11 Nov 2017 03:08:39 -0000

FWIW, I agree with everything that Joe said below.

Now, consider the FSM of router side of SLAAC, and compare it with the
FSM of the mechanism being proposed. The difference should be evident.

Thanks,
Fernando




On 11/10/2017 09:36 PM, Joe Touch wrote:
> 
> 
> On 11/10/2017 1:58 PM, james woodyatt wrote:
>>
>> I think the definition of “protocol” in the New Oxford Dictionary is
>> adequate.
> 
> The definition there is certainly true, but not adequate except for an
> English paper. "rules" are too vague.
> 
> In networking, a protocol is:
> 
>     a set of rules
>     a set of states
>     a set of messages that are exchanged (often called the "on the wire"
> part)
>     a set of events/messages/actions that represent the behavior of each
> endpoint (i.e., to upper layers)
>     a set of time events
>     a set of rules that relate incoming
> messages/timer-events/user-actions and state to yield outgoing
> messages/timer-sets/user-reports and new states
> 
> (the simplest way to express this is as a FSM, which is the most generic
> form of computation where a machine cannot revoke its output - which is
> why it accurately represents the ends of a protocol)
> 
> If you take away any of these (except state and, in limited cases,
> time), you cease to have a useful protocol.
> 
> If you change any of these, you have a new protocol.
> 
> Joe
> 
> 


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492