NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Thomas Narten <narten@raleigh.ibm.com>
Sean Doran <smd@ebone.net>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Randy Bush <randy@psg.com>
General Discussion:multi6@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe multi6
Archive: ftp://ops.ietf.org/pub/lists/
A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc.
Multihoming today is done largely by having a site obtain a block of address space and then advertising a route for that prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will explore alternative approaches with better scaling properties. Specifically, the WG will prefer multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ).
This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4).
The WG will take on the following initial tasks:
Produce a document defining what site multihoming is, the requirements for a multihoming solution (from both the end site and ISP perspective). This document will also include a taxonomy of different ways that multihoming might be achieved.
Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches.
The WG will also consider specific proposals to multihoming in IPv6 (both existing and new) and select a small number of them to work on as formal WG items. Development of specific solutions will require approval of the IESG (e.g., a recharter).
Apr 01 |
|
Submit initial I-D on requirements, terminology, etc. |
Apr 01 |
|
Submit I-D on how multihoming is done today |
Apr 01 |
|
Begin consideration of approaches and proposals that could be pursued. |
Aug 01 |
|
Evaluate approaches and select those to be worked on. |
Sep 01 |
|
Submit requirements ID to IESG for publication as Informational RFC. |
Sep 01 |
|
Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC. |
Sep 01 |
|
Evaluate progress, recharter or shutdown |
Multi 6 Working Group Meeting
Tuesday 1300 - 1400
These minutes are mostly from Geoff Huston (gih@telstra.net), augmented slightly with notes taken by Jun-ichiro itojun Hagino (itojun@itojun.org).
Vijay Gill: (vijay@umbc.edu)
Drafts Update
draft-ietf-multi6-multihoming-requirements-01.txt
draft-ietf-multi6-v4-multihoming-00.txt
Drafts were written up as strawman proposals to encapsulate the scope of the issues to be addressed. The documents are intended to document Best Current Requirements. i.e. Given what we know and observe, this is what we believe are the requirements. Any solution we come up is to support the current functionality we have today. This includes resiliency, traffic engineering and similar. The WG is soliciting input on these requirements documents.
Any solution should support these current requirements as a minimium.
Going forward includes sending comments, alternative proposals and requirements and practices.
Howard Berkowitz (hcb@clark.net)
draft-berkowitz-multireq-02.txt
The draft is not intended as an alternative proposal, but could be merged with the multi6 requirements document. This document deals with more than level 3 multi-homing, and addresses a number of issues at the datalink level as well as at the IP level. The draft addresses some of the customer motivations for multihoming and points to specific technologies to support these requirements.
It was suggested to the WG that a possible approach is to merge the wg req document with this draft. It was proposed that a services/requiments document and an architecture/framework and limitations document would be generated, and noted that both documents do not restrict themselves to multi-homing at the network layer.
Discussion:
Vijay Gill - that the multi6 document concentrated on network layer was a reflection of input and observation of current multihoming practices.
Geoff Huston - this broadens the scope of the working group and could defocus the working group and stall its progress
Perry Metzger - why Multi6? This is a more general operational requirement document.
Howard - there is a level of fit with the Multi6 scope
Steve Deering - this proposal depends on the charter of the WG. While there is some scope to explore more general issues, its up to the chairs and the ADs to see if this is in scope.
Joe Touch - we've been working on updates to the architecture documents of multi-homing requirements for hosts and routers. One of the problems of this group is one of understanding the terminology of multi-homing as defined in this document. This architectural principle of multi-homing could be undertaken in a chartered WG to look at these issues.
Atsushi Shionozaki (shio@csl.sony.co.jp) - Lin6
http://www.lin6.net/draft-teraoka-ipng-lin6-01.txt
Overview of lin6 - Location independant networking for v6. Based on a 64 bit node identifier and a "mapping agent". The constant node identifier part is used to base security associations which can be maintained over network prefix changes. The prefix change is not passed back to the end hosts. The source code has been released at www.lin6.org
Discussion:
Paul Francis: What are the security modifications?
Shio - there are no modifications to IPSEC as the input to the security association is unaltered.
Perry Metzger: performance issues with the use of DNS in this model?
Tony Hain (tony@tndh.net)
draft-hain-ipv6-pi-addr-00.txt
draft-hain-ipv6-pi-addr-use-00.txt.
The agenda item is the applicability of this PI address format and the use of it. The intent was to step back from the issues of multi-homing and examine the basic issues. Multi-homing in general is a subset of the general concept of 'provider independance' - this broader provider independance includes provider transition without renumbering for example. This provider independance is that the full prefix is in the DFZ. Comments were received that the proposal is suboptimal to some extent - it was noted that this is a tradeoff with simplicity and routeability. Is this intended to replace PA? Not as such.
The open questions in the draft include the match of the current format and the network topology to this proposed address format. The document also focuses on a multi-homed site, not a multi-homed ISP. How to keep the full knowledge of prefixes in a region over time.
Discussion:
Itojun - the issues of aggregation potential are not well understood
Christian Huitema - I think it does not work. The registration system cannot be avoided, and one is required.
Tony Hain - the inclusion of a registration system is not precluded by this proposal
Christian Huitema - a lot of address space is wasted on ocean surfaces. Tall buildings are problems too.
Christian - comparison of this proposal with the older Metro addressing scheme
Tony Hain- this is intended to address the issue of complete provider independance within and beyond the metro
Steve Deering - metro stuff is completely provide-independent (Tony may have misread).
Tom Narten - If we go in this direction how can we ensure that addresses will in fact be aggregated? There are always temptations not to.
Tony - worst case of no aggregatability is no different from today.
Tom Narten
draft-ietf-ipngwg-ipv6-2260-02.txt
Question to group for additonal comments on this document. No comments and no strong objection seen so far. Further comments to the mailing list.
Masataka Ohta
draft-ohta-e2e-multihoming-02.txt
Overview of the approach documented in the draft. The approach is to provide end hosts with multiple addresses and the aplpication or transport tries all destination addresses. The question is when to try alternative addresses, and the approach adopted is the either use directives in the applications or transport or a TCP default timeout. The advantages claimed for this approach is no change to router functionality, but a change to the API.
Comments:
Tom Narten - we are seeing two extremes of a spectrum where there is a push to the routing system to support multi-homing and a push to the host to support multi-homing. Each approach is not without considerable cost.
vijay: DNS reverse lookup in 8+8? no hierarchy, how to constract tree?
ohta: optional.
vijay: remove it if it is not necessary
Harald Alvestrand - the proposed host identifier space is non-hierarchical and as such is a large DNS flat space.
Randy Bush - this is illustrative of the issues of host-based multi-homing
Joe Touch - multi-homing is necessarily a combination of host and router functionality to be robust. Multihoming tunnelling (XBONE) experience showed that, endpoint should have some control over intermediate paths.
Erik Nordmark: how you recover from failure, scaling issue. scaling issue comparison with routing solutions.
ohta: more udp apps due to internet phone.
Agenda
To be Multihomed: Document harmonization?
Multi6 Issues
LIN6: A Solution to Multi-Homing in IPv6
End-to-end Multihoming
Multihoming Drafts Updates