draft minutes from London multi6 session

[Thomas Narten <narten@raleigh.ibm.com>]

These minutes are mostly from Geoff Huston <gih@telstra.net>,
augmented slightly with notes taken by Jun-ichiro itojun Hagino
<itojun@itojun.org>.

Please send corrections/clarifications to myself (if minor) or to the
list.

Thomas

Multi 6 Working Group Meeting
Tuesday 1300 - 1400

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.