Re: [arch-d] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)

Stewart Bryant <stewart.bryant@gmail.com> Tue, 10 January 2017 10:15 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DB01293DC for <architecture-discuss@ietfa.amsl.com>; Tue, 10 Jan 2017 02:15:17 -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, 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 Qf3ZRnK9DDST for <architecture-discuss@ietfa.amsl.com>; Tue, 10 Jan 2017 02:15:16 -0800 (PST)
Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::22c]) (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 BD3E9127A91 for <architecture-discuss@ietf.org>; Tue, 10 Jan 2017 02:15:15 -0800 (PST)
Received: by mail-wj0-x22c.google.com with SMTP id kq3so34117111wjc.0 for <architecture-discuss@ietf.org>; Tue, 10 Jan 2017 02:15:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=CZUrfUdOwLHJ3QWuCHJijibOF1wkFvWRoDYbzTnoTUU=; b=gFhjA/oEuXgBwQS+eau4l6KoXwpL6R5Rn/25JmPPqznaggnbyPQjhAeqbmQir/3g7H EhajFOgG/k836IYHOSYQRhK2jZIpFLUmUtmxaE6O6apLl68frrjnYtGPhYqTuyKbk0B2 eqVuukprq5W4GBtf5oYRkWDQI7hrdoqB0Ij67mJB51jb7ju70+e+tDVhY9Y3TUuZhg1P 8A8aBrq/zUeh8zcWAh7NYVUofqS8IvKdbYbTCo2N8LaC6hI5elNFKmGSPN6QcMP8xopn D4+rDWuGCZxU0hYzs6N/He60Um5bgJwCtRLUqg5BznSNYutJkEcxCKZLAVkEcLKxwD3J +esA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CZUrfUdOwLHJ3QWuCHJijibOF1wkFvWRoDYbzTnoTUU=; b=X0mvh/WqVkW504jRTdcY/UbOSG8pBe6jgZ1d6BkIBncq0Gau0m5hzOW4rXjJYePP/r 6dRVjUQyJECfGNYuSfbP33YlW7+ayvjzSNsMzkjoiLhkhAJnWcwFKqMyanwY6gxTh2pD HuucrRmA9cc9XmKelqYEOqv4L7hRgle8ggQUIcJYfMIz172JIvEIojsHUSZ2Ceb1TD4s kZOQH1E8Z8y3Es184uqc2nvp0N9n+A70DewRvQtQhCYur/EbfRrw0p8Sztxb1bidrSMX hSyMi/y2KsJMztB8iyyvc3Te42MN3iawMRXm0PYi/IQqfqrI8nvwLWtYILfhnaoJmpxJ B5qA==
X-Gm-Message-State: AIkVDXJteLeLqSZRqfV4Oy1gC0oJcqeCg8+AmyT0gnwIdnCWx620u+lAPBAWC3ort2gNXg==
X-Received: by 10.194.243.231 with SMTP id xb7mr1563356wjc.60.1484043313955; Tue, 10 Jan 2017 02:15:13 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ei2sm2365929wjd.47.2017.01.10.02.15.13 for <architecture-discuss@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 02:15:13 -0800 (PST)
To: architecture-discuss@ietf.org
References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <d079c169-a60b-21db-a031-7e3658166443@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <637543fe-ece5-1562-d000-f4d2d3c4f3d1@gmail.com>
Date: Tue, 10 Jan 2017 10:15:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <d079c169-a60b-21db-a031-7e3658166443@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/yCn32F3XX2YaWy1DXxa48PH55aw>
Subject: Re: [arch-d] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 10:15:17 -0000

A really good example of a transition mechanism that is not called out 
in this draft is the RIB.

In routing we have for years used the RIB as a clearing house to allow 
the routing protocols
which run ships in the night and are incompatible with each other to 
exchange connectivity
information between each other.  We can thus introduce new local routing 
protocols at will.
The (unsolved) routing equivalent of a problem of IPv6 proportions is BGP.

An example from ancient history outside the IETF was the DECnet Phase 4 
to Phase 5
transition. This was required to have a transition method indeed a as 
recall a hands-off
transition method. It was designed about the same time as IPv6. The word 
at the time
was that migration design too 80% or so of the design effort. It is 
likely that if IPv6
which presumably would have been fundamentally different, had stated 
this as a day one
goal we would be in a better place now.

Where this document appears to stop short is to recommend, maybe even 
require that all
revisions to Internet scale protocols MUST include a documented seamless 
migration
technical design, and that all new protocols that are expected to be 
deployed at that scale
MUST include the capability of being seamlessly replaced.

Best Regards

Stewart