Re: [arch-d] Updates on IAB mailing lists

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 20 April 2020 21:10 UTC

Return-Path: <brian.e.carpenter@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 B078A3A100D for <architecture-discuss@ietfa.amsl.com>; Mon, 20 Apr 2020 14:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EzIa8jZhRJME for <architecture-discuss@ietfa.amsl.com>; Mon, 20 Apr 2020 14:10:39 -0700 (PDT)
Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 A52F03A1003 for <architecture-discuss@ietf.org>; Mon, 20 Apr 2020 14:10:39 -0700 (PDT)
Received: by mail-pg1-x541.google.com with SMTP id t11so5707950pgg.2 for <architecture-discuss@ietf.org>; Mon, 20 Apr 2020 14:10:39 -0700 (PDT)
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-language:content-transfer-encoding; bh=jM4R9R3cbeZ4fhKxZnoEt9OM2zyvMFc1JKFD71/9kSY=; b=PrNEUujl0M9kt/86vXy2nMKLXmypV8M+W195YdA0iQfJ1UkdJ7lWd27c5fXS6GzHNC 1ITFY+O2iDy/xL1pLHLxMwnt4cozNSjqparRfiL7/KWM+7UuOuSijlXnlpyuQRFyJOjt 7Z34k9YmLyIS61PJmtXmralEBkpUPMr+2hsw56FPcmWu3Xf8iilQd6sr2ZCppUlt7/ag 7LDdN+0fUuez1zYkrpecwkcKO8EHrVS+JgYwfVKuWy+7j77QIshnYtTUIhFIL0PmNTk/ uTRIhXFbf/D7TAwPe1Q7lu6z7wFd+HwR6+xLZMvvvhUl+ExiA/EmMJnzJJP4nHO+9kHD trIw==
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-language :content-transfer-encoding; bh=jM4R9R3cbeZ4fhKxZnoEt9OM2zyvMFc1JKFD71/9kSY=; b=iHdB2Zi3d8eyvkf1fogluzqK79pTcupYCLzFwCIhdB69Ldype+AAzOfD1kvIuTAiyj RyK4yma6sny1eU8zaQfv/X5l/UWwsmsBSwXhIuPT558MR0M1ZJHLaeJAg5X1heQ578ZX 0mB0of1Tb7oLQwgs4ehI+z0hoOF2ZxQFpvBdjb3jcPyxzB9qSV9X100Rtu2eTXVR02uk OF43N60CqsVXSvOjuXgAAkundw0qWdXweWoG4gVwfE5kDbvkkZqSfIK5K05dS6yMgExy yu8LiaNJytQtrzv0v4TtzfiYOTQfcHRKgyaE6h8gvOq6K5Un8my6ISt+EuYjS+7SaV7M IACA==
X-Gm-Message-State: AGi0PubbzLzo2ls0Eqb1tVZMXELD9dIBn+eBIe7I1wdDtJss2BZhr5gQ 5srw0wPIR36Q79J+rEAH9aO0w/WGz/A=
X-Google-Smtp-Source: APiQypKzYBI7aO3hPILTEP0Hpro8ILN3ELG003RBe5gNKvjSvaUTTh6V2obHh1AM9YbgsTwydGbxVQ==
X-Received: by 2002:aa7:8259:: with SMTP id e25mr18450582pfn.82.1587417038525; Mon, 20 Apr 2020 14:10:38 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id e7sm402540pfh.161.2020.04.20.14.10.36 for <architecture-discuss@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 14:10:37 -0700 (PDT)
To: architecture-discuss@ietf.org
References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <F6BDA4C7-614B-4C0C-A00A-6B5056541B6E@tzi.org> <CAHBDyN5fsp1AdaGuonAccGReEgYy8e0gaFL=-KCzD7W=dtdVEg@mail.gmail.com> <CAHBDyN5LQFnf7e+G9X4M+9MM9wZGiZmtL7xjfD-tsy0wZR5nGA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com>
Date: Tue, 21 Apr 2020 09:10:34 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAHBDyN5LQFnf7e+G9X4M+9MM9wZGiZmtL7xjfD-tsy0wZR5nGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/RjvoJ3chJtdvc8AebOhKnG7_Eec>
Subject: Re: [arch-d] Updates on IAB mailing lists
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 20 Apr 2020 21:10:42 -0000

On 21-Apr-20 07:34, Mary Barnes wrote:
> Just to be clear, my point is that architecture-discuss was not intended to be an IAB discussion list any more than IETF discussion list is scoped to IESG discussion. 

Not quite accurate - see below. Especially "This is an IAB-sponsored activity...".

   Brian

-------- Forwarded Message --------
Subject: New architecture-discuss mailing list forum
Date: Mon, 17 Oct 2005 16:00:54 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
To: IETF Announcement list <ietf-announce@ietf.org>
CC: iab@ietf.org, iesg@ietf.org, architecture-discuss@ietf.org

A new mailing list has been created to provide a forum for general
discussion of Internet architectural issues:

   architecture-discuss@ietf.org
   https://www1.ietf.org/mailman/listinfo/architecture-discuss

The architecture-discuss list serves as a technical discussion forum for
all members of the IETF community that are interested in larger
architectural issues. It is meant to be an open discussion forum for
all long and/or wide range architectural concerns related to the
Internet Architecture. In particular, it may be used to discuss and
bring forth different points of view on controversial architectural
questions. Discussions that drill down and dwell on specifics of
individual protocols or technologies are to be discouraged, redirected
to appropriate other fora, or re-cast to discussions of broader
implications for Internet architecture.

This is an IAB-sponsored activity, but IAB members will be
participating as individuals and not representatives of the IAB. As
such, postings to list must not be considered as IAB opinion, and must
not be quoted as such. Indeed, it is expected that IAB members will
disagree with each other, at least occasionally, just like the any
part of this community.  :-)  Note that questions asking for an official
IAB opinion, issues requiring immediate action (by anyone), issues
related to the way the IETF operates, do not belong on this list.
Issues pertaining to IAB business should still be directed to
iab@iab.org .


Leslie Daigle,
for the IAB.

------------------------

[Some examples of potential topics for discussion, provided by Pekka Nikkander]

1. Mobility and multi-homing

The IETF currently hosts a bunch of working groups focusing on  various aspects
of mobility and multi homing.  At the Internet Area,  there are five WGs and a
couple of almost-WGs charted for standards  track work: MIP4, MIP6, NEMO, SHIM6,
MONAMI6, and NETLMM.  In  addition to those, there are experimental approaches,
such as HIP,  and optimisations, such as MIPSHOP and MOBOPTS.  Outside of the 
Internet area, MOBIKE is focusing on mobility and multi-homing for  IPsec and
SCTP and DCCP folks have had their mobility and multi- homing discussions.  The
wider research community is full of various  proposals, including overlay
approaches (such as i3) and underlay  approaches (such as using MPLS tunnels to
implement host routes).

Given this multitude of work and even partially overlapping standards  track
solutions, what would be the right way or right ways forward?   Could we design
a way towards converging solutions?  How do we ensure  robustness of solutions
if we attempt to deploy multiple solutions at  the same time; for example, SHIM6
+ Mobile IPv6 + SHIM6?  How do more  unified solutions, like using CGA-based
mobility with SHIM6 contrast  to this?  What about using HIP with routable IP
addresses instead of  Host Identity Tags (HITs) as Upper Layer Identifiers? 
Going a little  bit furthermore, what are the architectural impacts of doing
mobility  and multi-homing at the IP layer vs. other layers?

2. IP virtualisation

In the recent discussion w.r.t. tunnelling at the Internet Area list,  a clear
need for virtualisation came up.  While tunnelling with clear 
implementation-level virtualisation boundaries is clearly one viable  way to
implement virtual IP networks on the top of the "real" IP  infrastructure, this
issue seems to warrant some deeper digging.   Tunnelling has well known
drawbacks, and we may want to ask what  would be the alternatives.  In order to
understand alternatives, if  any, we need to understand better the requirements
behind IP  virtualisation, or what people *really* want to achieve with it.  Is
it merely ease of configuration, or reduced operational costs?  If  so, could
there be other architectural ways of achieving the same  ease or perhaps even
larger capital and operational savings?  Some  people have been promoting adding
"realms" as a first class service  to the base IP.  Would that provide an
alternative solution?

While the mobility and multi-homing discussion seems to more circle  around
evaluating existing proposals and trying to navigate towards  more unified
solutions, here we seem to lack genuine alternatives and  deep understanding of
the real problem domain.

3. Overall open architectural issues

Some IAB members have been collecting open architectural issues for a  while,
with the intention of bringing up an up to date collection of  information at a
later date, probably in a form of a WikiPedia-like  web site.  This work is
going on, and we'd like to get as much  information as possible from the wider
community.  Hence, suggestions  on what are the more pressing longer-term open
issues are very  welcome.  To given an idea of the current issues so far
identified,  here is a partial list.  The list doesn't say much without 
explanation, but it may give an idea of the type of issues we are  looking at.

End-to-end connectivity
=======================

The original value of the Internet, the ability to connect to any  host with
any protocol, has eroded away during the last decade. While  it is impossible to
get back to the original mode of operation,  largely due to security reasons,
some form of better-than-today end- to-end connectivity would be very valuable.

o Living with NATs, filters, and firewalls
o Introducing identity realms or domains
o Evolving the application interface (API)

End-user experience
===================
o Transparent security
o Zero Configuration and Service Discovery

Balancing Accessibility, Security, and Privacy
==============================================
o System for plausible sender identity for received packets
o Secure self-configuration
o Integrating security across the stack
o Dealing with bad traffic

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce