Draft multi6 minutes

[Brian E Carpenter <brc@zurich.ibm.com>]

Comments this week please, after which the minutes will be submitted.

   Brian

Multi6 WG meeting minutes  

(Tim Chown, 2nd August 2004, edited by co-chairs)

Both co-chairs present:
Brian Carpenter
Kurt Lindqvist

Meeting opened 9:05 am, 2nd August

Brian reminded attendees of the terms and conditions of IETF meetings
and contributions as stated on the yellow sheet given to delegates in
the IETF registration pack.

There are three parts for this meeting on the agenda.  First, there
are four drafts to finalise, so we can WGLC and not have them in the
next meeting: 

     draft-ietf-multi6-v4-multihoming-01
     draft-ietf-multi6-things-to-think-about-00
     draft-ietf-multi6-multihoming-threats-00
     draft-ietf-multi6-architecture-00

Then a scenarios document:
     
     draft-palet-multi6-scenarios-00

And finally a further discussion of next steps, including the
Wedgelayer 3.5  / Fat IP approaches and required components. 

The three-part agenda was accepted, with no changes suggested. 

** draft-ietf-multi6-v4-multihoming-01 (Kurtis  Lindqvist)
 
Kurtis stated that the list comments were all taken on board. 
Only major discussion was Chapter 3 on motivations for multihoming,
so it had been suggested by Brian Carpenter and Kurtis, on the
mailinglist,  to take this out and leave it for Jordi's document. 
Only Pekka have objected to this at this time.

Pekka: Mechanisms are different in v4 and v6, so we should remember  
the scenarios we need to fix in this document.  It is not a trivial
rewording. Issues such as traffic engineering should be expanded.
Maybe half a page is needed.

Kurtis: I have no strong view.

Pekka: Not all v4 motivations may be supported by a v6 solution.

Eric Fleischman: RFC3582 in sec 3.1 has a list of these goals, and
the draft list is just a subset.   There are 7 reasons in the RFC and
4 in the draft.

Kurtis: Maybe we should just refer back.

Geoff Huston:  There is also the analysis at the end of the
architecture draft that could be merged in. 

Brian: I don't think that's probably the right thing to do. 

Kurtis: The documents should be consistent.

Brian: If things are missing, send text (aimed at Pekka).   To avoid
endless debate, Kurtis should try to refer draft text back to the RFC,
and make the motivation section leaner and more precise. 

The room agreed that the changes to the document were representative
of the list comments.

** draft-ietf-multi6-things-to-think-about-00 (Eliot Lear)

Some text based on Geoff's texts, the goal in the new version was to
make the questions a bit clearer, and to add applications
considerations, e.g. for backwards compatibility, e.g. what happens to
hostbyname. There is a danger of misinterpretation if these functions
are overloaded, e.g. if log analyser converting IP addresses back to
names.   Happy to get the document  to an Informational RFC, but main
goal is to list the problems people should think about.

Brian: chairs not sure whether to keep as living document or publish
it sooner.

Eliot: don't waste time making this perfect, just use it for solutions
documents.

Tim Chown: these issues should be preserved for future reference 

Brian: question is just when.

** draft-ietf-multi6-multihoming-threats-00 (Eric Nordmark)

Most changes in this version are editorial edits.  The biggest
addition was discussing the state of privacy in the Internet today, so
we can talk about "do no harm" additions in the context of
multihoming. Also some more background info for multihoming newcomers.
The appendix has been left in place because there is nowhere else to
put it. Christian Huitema made specific privacy comments; multihomed
hosts have different IP addresses per ISP (making correlation harder),
also that v4 middleboxes/NATs today make correlation for snoopers
harder.  These comments are added now. 

Christian: We should not just say "do no harm", i.e. not just say "be
no worse", rather we should actively try to do better.   For example
any use of unique  identifiers have a privacy risk.  Goal is we should
do better. 

Eliot: I disagree.   Principal goal is scalable multihoming solution -
adding privacy concerns degrades the situation. 

Brian: I detect Christian is saying "raise the bar".  That change is
one we should be clear about if we want to do that.

Christian:  My company is often criticised.  There are solutions for
multihoming that can make security or privacy harder.   We have to be
clear about the tradeoff between functionality and privacy. As with
the MAC address, our industry has not been cautious.

Geoff:  Bits of my identity need to be available to do multihoming.
If we go locator independent, you are exposing info about bindings
that was not previously exposed.  The fundamental question is whether
we're doing a locator-identifier split.   Is there a persistent
long-term identify, published, or a per-session method? These have
different issues.  We already had the debate in the bottom 64 bits 
for IPv6.   

Erik:  You don't have to expose the same identity to everyone, the
single identity is the more dangerous.

Geoff: You can't always bind by context, so it becomes longer term. 

Erik: You still need to make referrals work.

Geoff: Not sure.

Christian:  Making a session live over a change of IP address has
less implications.    You can engineer your solution to make your
identifier visible to your session peer and/or third parties.   We
should be more explicit. 

Erik: We should note the peer and 3rd party text in the document.   We
should make stronger statements about unique identifiers and their
concerns. 

Eric Fleishman?: We should have a solution that hits many layers.
Christian's idea of embedding MAC addresses is bad only in some
people's eyes. We can't say what is good or bad clearly, because it
may depend on the solution.

Christian: I would like the considerations there because they are
taken as input for the solution designers, hence privacy is
important in this document, even if that means the solution is harder
to build. 

Erik: I'll add those comments in the next update

Brian: We need WGLC on this very soon.

** draft-ietf-multi6-architecture-00 (Geoff Huston)

Has been revised by WG list comments and from the interim meeting,
and is now a WG document.  Geoff thinks it needs more review and
revision, so we can go to Informational RFC.   The changelog shows the
WG input, e.g. session initialisation when the state is not as you
might expect, and to consider traffic engineering across multiple
paths. Also some text on endpoint identifier structure - at what point
to do know you're dealing with a locator, or an indentity without a
locator context.   Also disambiguating in the case of load-sharing
(i.e. the machine may not be multihomed, the  service may be
multi-hosted). New text is added on triggering locator change, via
ICMP triggers. Also notes on whether identity is per session, or per
endpoint independent of session.   A new section on functional
decomposition of multihoming approaches has been added, due to WG
chair input. 

There is an open issue for which help is needed, wrt MIPv6.  There was
a comment that there is a "back to base" problem.   In multihoming, a
fixed, home locator may not be there.   So there needs to be text as 
to why MIPv6 is special in the multihoming space.

The appendix on "various approaches" should be split out, to get the 
main document through quicker.

We should document the architecture issues of identifier-locator
split, and on the capability negotiation initial handshake, and on
describing the various identify types and their potential for 
coexistence.   For example, the application may use identifiers or
locators; the capability and semantics need to be clearly
understood.  

Brian:  We should look at each of these issues.   We need text from 
someone, e.g. for multihoming and MIPv6 for the first issue. 

Eliot:  In order to initiate contact you need to be able to start by 
going via the home address.

Geoff:  That, and also there are timers when you go into care-ofs 
that you check back with the home address.  This may be inappropriate
to multihoming.  We need text on this.

Eliot:  Question is why are those timers there and whether or not if
we did  something else for multi6 we'd end up in the same position. 

Marcelo volunteered to provide text.

Brian: The appendix early analysis text (by Margaret Wasserman) could
be split out - it's not architecture per se.

Margaret: I am happy to split it out.  Is that valuable?

Brian: We did some analysis in the interim meeting.  This might make you rethink
the way the analysis is organised.

Margaret: We should structure based on the interim meeting discussion.  It needs a
lot of updating if it should be kept.   Originally it was a text to get people up
to speed.  maybe it's served its purpose.

Brian: We'd need a co-author...

Margaret: No, we need an author!

Brian: OK, we'll spin this appendix off.   It needs an author though.

Christian: I volunteer.

The WG hum passed the proposal clearly.   David Kessens (AD) agreed.

Brian (chair hat off): The broader implications debate is endless, so we should
not have it in this document, else we may not get closure.

Tom Henderson: Since last meeting there has been a new IRTF WG on this 
topic for locators and identifiers.   Looking at HIp on a wide scale, and the impact.

Brian: Good luck!

Geoff:  Persistent unique identities that are validatable and operate with integrity
have a heavyweight distribution mechanism, so think about that in the context
of DNS, or distributing locators.   There will be a comparable infrastructure, so
there are far-reaching implications.   There thus has to be a real value beyond
multihoming for identities agile beyond locators.    

Christian: Could be bad for privacy

Geoff:  If limited to multihoming, as cost-benefit, then session based resiliency
can be done without those long lived properties.  There are big architectural
implications.  We must choose with our eyes open.   This must be documented,
and this draft is one such place to do it.

Erik: What are you suggesting putting in?   Without saying all the tradeoffs and
how to weigh them.

Geoff: I think we should state dimensions and arguments, maybe 2 pages of
careful writing.  It's not easy, but I think it's necessary.

Erik: We might not get closure though.

Geoff: I'd like to document that choice space.

Brian: No binding vote now as Geoff may find it's too hard to write.  Are people
generally feeling this is good to document.

Majority agreed to documenting it.

Brian:  This must not become a war on this topic.  Just describe the dragon.

Brian:  The issue of initial handshake on capability seems less contentious.

Geoff:  We need text on signalling, negotiation, etc.

Brian: And whether per-session.

Geoff: Yes.

Brian:  The final issue also seems clear, so should go in.

Brian: Are there any other issues we missed?

No input from audience, so no issues raised.

Brian:  I urge people to have a final think for anything missing, so Geoff can
focus on editorial issues.   Glance over Eliot's draft for anything architectural
rather than just things to think about.

Eliot:  I'll provide some text.

Geoff:  Deadline is 2 weeks for text.   I'll edit in 3 weeks.


** draft-palet-multi6-scenarios-00 (Jordi Palet)

This document was written in response to a comment from Brian that such
text isn't written yet.

There are many scenarios: e.g. ISP, IX, enterprise, university, security, defence,
emergency, SOHO, 3GPP, ad-hoc, mesh.   Applications like VoIP in emergency
 situations is one example.   There are special services and applications, e.g.
GRIDs, mobility, special devices (WLAN and 3G interfaces), renumbering,
real time traffic, special protocols (CDN, IDC, DNS, DHCP, etc).

It would be nice to get the work adopted as a WG item, maybe to integrate it
with Kurt's document.   We need expertise in some areas.

Kurt (chair hat off);   Happy to work with this as appropriate.

Brian: This document should not become like other scenarios documents that
may take years to complete and become blocking factors.

Brian: Is this a good idea?    Is it bad?

Silence from room.

Brian: OK, let's continue with this.

Jordi: We need 3GPP input.

Terry Ernst: We could merge this document with our work on a mobility 
approach, we have the same motivation for fixed and mobile nodes.

Brian: Jordi needs help, else the document will not improve.   This should remain
a personal item until at least the next revision.


** Open session on next steps:

Brian:  We have just over an hour left.   Interim attendees should know what 
this is about.  The interim meeting sorted 30 or so proposals into groups, and
the top group turned out to be wedgelayer or Fat IP, as a shim layer.  So the
next step is to consolidate the work in that area.   We have a proposal for
progress; there are 7 drafts in this space, our goal is to get the common view
of the "functions" and components.

A design team of Erik Nordmark, Jari Arkko, Marcelo Bagnulo Braun, Iljitsch
van Beijnum, Geoff Huston and Yukka Ylitalo has been formed and all have all 
agreed to serve.

The goal is to get to a smaller set of proposals, without going into detailed
protocol specifics.   A single document should be produced for discussion at
IETF61.

Christian:  I see three separate areas that can be studied in the wedge space;
how to exchange an identifier, then the issue of ingress filtering, and how that
is handled, and also the issue of by which method you choose which 
locators to use.   These three things are essentially independent.  So is one
document best?

Brian: You're not wrong.

Christian:  We could redo IP, which is the identifier space, and we use that.
Or we could look at the minimal set of functions to adapt what we have today.

Brian: Let's keep this on hold for the next few slides today.

Brian: There are 7 drafts in this space:

draft-nordmark-multi6-cb64-00.txt 
draft-nordmark-multi6-noid-02.txt 
(draft-nordmark-multi6-sim-01.txt withdrawn)
draft-ylitalo-multi6-wimp-01.txt
draft-crocker-mast-proposal-01.txt 
draft-nikander-multi6-hip-01.txt
draft-van-beijnum-multi6-odt-00.txt 

We also looked at the mailing list for functional decompostion:

Establish mh session state
Locator selection for initial contact (both source and destination) 
  There are two items here: 
      - Path availability. i.e. if packets with a given pair of 
        source and destination address reach the other endpoint 
      - Policy: about locator selection 
Path failure detection mechanism / Trigger rehoming
Locator selection after a failure has been detected / Choose new address pair
Add/delete addresses
Execute rehoming
Delete mh session state
Identifier discovery mechanism 
Locator discovery mechanism 
   - for initial contact 
   - once that the communication is established 
Identifier validation mechanism 
Locator validation mechanism 
   - at the initial contact 
   - once that the communication is established 
Garbage collection 


We won't
discuss this point by point today as we don't have time.   We missed out
ingress filtering but will add it.   There is a scope of around a dozen or
so areas to consider, based on the observations.

Kurt: We need to get a document from this decomposition as a discussion
focus.

Christian:  Also the interoperability with existing IPv6 hosts needs to be 
considered.

Brian: Of course.

Erik:  The focus needs to be to bring together the different identifier aspects,
to see if we can build a method that will cover what is needed.   The ingress
filtering can be treated separately.

Brian: This list of components shows its not an easy problem.   You need to
think about all the goals, all the things to think about, to get a complete
problem statement.

Christian:   Also hardware acceleration, and load balancing, needs to be
considered.  

Jim Bound:  I'd like to see SCTP as part of the analysis.

Brian: SCTP tackles some of these issues, it may not be built into the wedge
layer.

Jim: It may reduce the wedge.  Is it part?   Or are we just reinventing a 3.5 layer?

Brian: we didn't list it as SCTP is Layer 4.   Components are relevant though.

Jim:  Some of us believe we're making this too complex.   I'm working also on
hardware acceleration- it should be transparent to us.    Vendors who ship
"funny link layer interfaces" - that's their problem.   We don't want to take on
too much.

Brian: yes, but there are tough problems with assumptions that offload devices
make.

Erik:  We should not force all existing hardware and apps to keep working.

Tony Li:  This is the IETF, so we work on running code.   We need to think about
hardware, not ignore it.

Jim: That's not what I'm saying. 

Christian:  The wedge layer only comes into action for session survivability, but
if you do not care about that, the picture is different.  We should acknowledge that.
Tying the 3.5 layer to session survivability has implications.

Brian: I suspect that's correct.  Geoff is this in the archictecture document?
Do you only need wedge layer if you care about session survivability?

Geoff:  Yes, I thought about it as Layer 3.4 or 3.6, depending on whether you
look up or down.  You could swing it either way a bit, depending on whether 
you want to share state across sessions, with longer running glue, or have
session survivability.    Being agnostic leads to complexiities, there's a 
different functionality depending on whether a previous session exists.  l lean
towards 3.6.

Brian: Are there common features that we don't need to discuss, or differentiating
features that we do need discuss, e.g. HIP vs NOID, or are there still things 
missing in the "things to think about" draft?    

Brian: Erik, anything to say about the design team process?

Erik:  We're trying to organise a get-together this week, no slot yet.   That's
about it at the moment.   We need to carve out more than we discussed today,
in terms of what to cover or not cover.  I'm concerned about the 7 drafts, but
also continue to get input from the WG.

Brian: we can identify what can be worked on independently, not everything
is in the scope of the wedge layer.   We could get other authors or another
design team in place for that.

Tim: What was the withdrawn draft of the 7 drafts?  ie.
draft-nordmark-multi6-sim-01.

Erik:  That was down to HIP, it felt redundant.

Brian: The revised wimp draft is quite different now, btw.

Marcelo:  How will we move forward on the components part?  I agree with
Christian's comments here.

Brian:  We don't have a plan yet but need one.  We need to find the gaps in
our plans.

Brian: We can close now if there is nothing else to raise now.   Anything to
add, David, as Area Director?

David: Nothing to say or add.

Close of meeting at 10:40am.