multi6 minutes

[Kurtis Lindqvist <kurtis@kurtis.pp.se>]

Please find attached the minutes from the multi6 meeting in Minneapolis.
Please comment / send corrections or additions before April 1th.

Best regards,

- kurtis -


---------- Forwarded message ----------
Date: Thu, 24 Mar 2005 06:07:24 +0200
From: john.loughney@nokia.com
To: kurtis@kurtis.pp.se
Cc: brc@zurich.ibm.com
Subject: RE: MULTI6 rough notes

Kurt,

Here is some clean-up on this text. I didn't dramatically rewrite anything, just some basic correction.  It is a bit he said, she said, but a little higher quality than shim6 (too many universal deployments of IPv6 before shim6).

John


=================


CHAIRS: Brian Carpenter <brc@zurich.ibm.com>
Kurt Lindqvist <kurtis@kurtis.pp.se>
AGENDA:
o Administrivia, 5 mins - Chairs
- Agenda bashing
- Scribe / Jabber Scribe
o Presentation on changes to updated documents
- Erik, 10 mins
- Marcelo, 10 mins
- Jarko, 10 mins
o Outstanding issues, 25 mins
- Any topic that should be addressed elsewhere (outside shim6)
- Decide on open ends (not addressed by updated documents)
o AOB, wrap-up and closing of WG.

Time to start.

Hopefully last multi6 meeting.

audio streaming info here: http://videolab.uoregon.edu/events/ietf/

Adminstrative stuff:
Friday there is a shim6 bof. This is in the interenet area. Output of multi6 wg is moving into this bof. 2? drafts in RFC editor's queue.  Couple of drafts in IESG review.

David (AD) mention that the DISCUSSes should have been just cleared, so a few minor issues should be fixed shortly.

The plan is to talk to the current documents, then discuss any issues still outstanding.

Brian - just to be clear, we've set a direction that will be filled by shim6 in Internet area. We are not going to revisit old points.

Jari Arkko presents an Update on Failure detection draft in MULTI6
Summary of content is existing work in the space.
It provides a model where lower layers provide info to multi6 protocol and defines a few basic concepts:
- available addresses
- locally operational address pairs
- operation address pairs

Gives guidelines on selection of address pairs & suggests a protocol for testing reachability.

Major changes are:
- relaxed rules on the use of non-global address


Marcell is up - 2 drafts
Draft-ietf-multi6-hba-00 update
HBAs are new type of address with cryptographic properties and provide protection when rehoming.
Changes to the draft include
  -- added examples of reaming scenario
  -- added privacy concerns
  -- added flooding attacks discussion
  -- added the multi-prefix extension in step 6.1 of the hba-set generation process
  -- added Ext type value recommended for trials

Brian asked for DNS consideration discussion to be added. Also mentioned that DNS could be used as a cource of trust for available addresses.  Brian didn't ask for an update of DNS inside this document, but to carry to shim6

draft-ietf-mult6-functional-dec-00 update
This draft analyzes the trade-offs on different parts of a mult6 archetecture, presents different options, etc. Addressed some comments on locator set management. Removal of multi6 session state and fixed some editorial comments.  Added comment on rehoming may be run for other reasons than just failure

Geoff Houston - doesn't know what will happen with this document, but the title doesn't match the body. It isn't a functional decomposition and doesn't provide steps. It is more a high level discusison with some discussion points.  Either need to change the title or rework the document.

Marcello - we took Geoff's architecture document as a basis and tried to provide mechanisms to fit that document.

Geoff - that document was a set of questions; this document fleshes out the questions, but doesn't provide solutions.

Marcello - that was the intention and wanted to have a discussion about this at the last meeting. Was told to leave the document as-is for now, and it would be sent to shim6.  We'll fix the title and need more discussion on the trade-offs.

Kurtis - The state document is more like what Geoff wants.  Leave that discussion for shim6.  Geoff's point is probably valid, need to revisit it in a document revision.

Eric is up.  This is about the l3-shim document.
Changes in the update & some comments recieved since then. Change log shown
 - clarified ingress filtering
 - clarified use of ULAs
 - added text about IP multicast
 - added text about ICMP handing in this scenario
 - clarified text on recieved site multiplexing
 - added text on renumbering issues
 - clarified flow-lable text.

To Do things
 - using address, locator & ULID more carefully
 - Does the interaction between source locator selection and ingress filtering implies a stronger assumption - it might be too soon to assume that.
 - make it clear that the probablitlity of prefix reuse causing address reuse is very small
 - point out that MTU change can occur from locator pair switch
 - more clarifications on what is ULA specific vs. using reverse DNA

Other questions?
Issue 01 with To Do things added.

Brian - confusion when handing drafts to another working group. Maybe its best to resubmit current draft with new wg (to be) label. Any other comments?

Kurtis - my name is Geoff ... you can make same comments with respect to this document as to the previous document

Geoff - These documents don't really tie into each other.  Trying to look at this as a whole is important. The current linking between the drafts are weak.

Eric - agrees that this is missing.

Geoff - it is hard to read all 3 and draw the big picture from all of them. They need a little bit of work.  Geoff sends a list of to the mailing list

Someone who said that they were Brian (joke) What to do if the shim6 doesn't become a WG.

Brian - He's not worried about that. Margaret is possitive about the bof, so he's not worried that this a dead-end. Does David Kessens want to comment?

David - From the beginning the idea was to move the WG to a new area; there is not much reason to worry about any problems though.

Outstanding issues or other business

No comments

Pekka Savola - I want to say 2 (or 3 or 4) words  - Traffic Engineering and Provider Independence.

Kurtis - provider independence is maybe not a problem to tackle here.  Traffic engineering may move to shim6.  Do you have another point or were you thinking about something.

Pekka - I'm trying to remind that we've focused on connection survivability, but this is not sufficent.

Kurtis - Yeah, there is nothing cooler than having your own address block.

Tony Hain - are you suggestion we hold PI in another WG.

Pekka - just reminding everyone about this topic.

Geoff - There is a large list of things that are nice to do, but some things are easier to do. Traffic engineering is harder when you are doing host-centric services as hosts don't know topological info.  TE falls down to the bottom of the list when you do host multihoming.  There's not enough information at the host to do all of this.

Pekka - I agree, but we should try to find out ways to mitigate this when using multi6.

Eric - my take is that there is a lot of things people can do with TE.  If there is a subset that is interesting, we can look into this, but it is a balancing act.

Brian - this may be an area that isn't covered, Mr. AD?

David - wants to say he is Margaret Wasserman, but says this is the engineering task force, if you can't solve everything, then you do what you can.

Kurtis - should we keep this for Friday?

David - Yes.

Brian - it can be covered by an individual submission by someone who really cares ...

Kurtis - last 10 minutes and mic is free ...

Brian thanks Kurtis & David.

Applause!