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

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]>
To: IETF Announcement list <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]

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

   [e-mail]
   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
[e-mail] .


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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce