- From: Mark Baker <distobj@acm.org>
- Date: Mon, 17 Oct 2005 17:36:28 -0400
- To: www-tag@w3.org
FYI. ----- Forwarded message from Leslie Daigle <leslie@thinkingcat.com> ----- 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 Subject: New architecture-discuss mailing list forum Date: Mon, 17 Oct 2005 16:00:54 -0400 X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 List-Id: ietf-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> X-pstn-levels: (S:53.92062/99.90000 R:95.9108 P:95.9108 M:94.8923 C:98.7678 ) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bork.markbaker.ca X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.5 tests=BAYES_00 autolearn=ham version=3.0.4 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 ----- End forwarded message ----- -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Monday, 17 October 2005 21:34:07 UTC