Subject: [Mipshop] Minutes: 58 IETF Minneapolis

From: gabriel montenegro <[email-masked]>
Date: Tue, 25 Nov 2003 00:10:01 +0100

Folks,

These are the preliminary minutes for the Minneapolis minutes.
Please look over and send any corrections that may be applicable.
I'll submit them by Thursday at 20h00 GMT.

Many thanks to Henrik and Behcet for their notes.

tnx,

-gabriel
<pre>		
Minutes by:
	Henrik Levkowetz <[email-masked]>
	Behcet Sarikaya <[email-masked]>

Some edits by the chair.

; MIPv6 Signaling and Handoff Optimization WG (mipshop)
; 
; THURSDAY, November 13 at 1530-1730
; ==================================
; 
; CHAIRS: Gabriel Montenegro <[email-masked]>
; 
; 
; Agenda:
; 
; 
; 1. Preliminaries        10 Mins                 Chair
;    - Minutes
;    - Document status
;    - Agenda bashing
; 

3 workgroup drafts:
	WG last call completed on the lmm requirements document
	Some comments came in; new last call expected Nov. 26
	through Dec 3, going to IESG (as informational) on 
	Dec 5.

	HMIPv6 and FMIPv6 drafts currently in last call
	until Nov. 24.

	Group is adopting Pete's 802.11 handover draft as per
	the charter. Target: WG LC on feb and to IESG as informational
	on April 4.

Next steps:
	Dec 03 - LMM to IESG as informational
	Jan 04 - FMIPv6 to IESG as experimental
	Jan 04 - HMIPv6 to IESG as experimental
	Feb 04 - 802.11 Fast Handoff WG LC
	Apr 04 - 802.11 Fast Handoff to IESG as informational

; 
; 2. Localized Mobility Management Requirements: 20 min
;    I-D: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-lmm-requirements-00.txt
;    Presenter: Carl Williams
; 
;    Slot to discuss comments received during WG last call.
; 

Carl talked about the LMM issues; 

	1. Make the document less MIP-specific.
	2. Clarify the intro with respect to the intent and background
	   of the document. 
	3. Title change; 'Localized Mobility Management Requirements' 
	   to 'Localized Mobility Management Goals'
	4. FMIPv6 listed as reference but not cited; led to discussion
	   of including reference to the mobiliy terminology draft from
	   Seamoby wg.
	5. Add security consideration section
	6. Minor editorial comments

	A timeplan running up to submission to IESG on December 5th
	after a new wg last call was shown.

Gabriel:	Issue 3 - go with goals, issue 4 remove the reference

James:		Agree, but we'll need a security considerations section

Carl:		Yes, Pekka and I will work on this; and then submit
		etc. according to the time plan.

; 
; 3. Fast Handovers for Mobile IPv6 (FMIPv6): 30 min
;    I-D: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fast-mipv6-00.txt
;    Presenter: Rajeev Koodli
; 
;    Slot to discuss comments received during WG last call.
; 

Rajeev		presented the wg last call comments on the FMIPv6 drafts.

	A change log of revisions since IETF57 was shown.
	Last call comments were shown, mostly relatively minor
	adjustments, see slides for details.

	Input from mailing list (ML). codevalue=0 change should to MUST.

	LinkLayer Address option. Change length to 8 octets to accommodate
	EUI-64 addresses,

	Lifetime of NCoA by NAR in NAACK? Same as lifetime for the prefix
	in RA.

	Change destination address of FBack to source address of
	FBU. Maybe leave as it is.

	PAR should start buffering after processing FBU not after
	processing PrRtSol?

	No need for PAR to buffer after processing FBU. It is not clear
	why we need this change.

Greg:		On the processing after FBU, the issue was rather one
		of the semantics of the FBU.

Rajeev:		...

Greg:		Maybe the spec is not clear on when it is permissible to
		start tunnelling. Need to be clarified

Rajeev:		(About setting the U bit at different times)

Greg:		So the confusion seems to be about the U bit. So
		possibly there is a problem there.

Rajeev:		The router is buffering a sliding window

Greg:		Yes , then it might work

Gab:		Maybe some clarification with respect to the U bit would
		be needed?

James:		Who signals the buffer is the vital point
		Might make sense to put in some words about how to
		implement the buffer. 

Rajeev:		It now says the router must 'buffer and forward'

James:		Ok, that may be sufficient.

Rajeev:		(more issues)

Alper		Are we going to recommend a working group item behind
		this last item (where to specify link-layer triggers)?

James		We have said that we will specify in other places the
		various link-layer triggers.

Alper		I just want to make sure that it is picked up
		somewhere...

Rajeev:		(more issues)
		- Using PrRtAdv both as a response to PrRtSol and as a
		handover trigger.
		  - either different code value
		  - or code=0 and a NcoA option

James:		Prefer new code value.

Greg:		Next - Identifier value in grat. PrRtAdv could create
		re-transmission confusion. Propose having an increasing
		sequence number as identifier, with a different code.

Rajeev:		Ok

Rajeev:		(more issues)

		James/Rajeev interchange about how does PAR know FBU is
		sent from the new link? No change from proposal on
		slide.

Vijay:		Matching FNA with NAACK:
		We don't need to match these up.

Greg:		We're optimizing a corner case. If you just left this
		out, it would probably be fine, because there's stuff
		in the pipe (Opti Dad) which will fix it.
		Why have an NAACK at all? Why have this in the FMIP at
		all?

Rajeev:		Fine with deprecating NAACK.

(longer interchange Rajeev/Greg/James/Vijay about having this address
configuration as part of FMIP. Turns out Greg is basing his comments on
an earlier version of the draft. )

James:		The draft should not in any way imply that there is any
		other way than DHCP to do stateful address configuration
		
(Gab/Greg/Rajeev continues FNA/FBU/NAACK discussion.)

Gab:		I guess we can take this on to the list.

; 
; 4. Hierarchical Mobile IPv6 mobility management (HMIPv6): 30 min
;    I-D: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-hmipv6-00.txt
;    Presenter: Chair (slides by Hesham Soliman)
; 
;    Slot to discuss comments received during WG last call.
; 

Gab presents Hesham's slides. Last call still on, please send slides.
Some technical comments, lots of nits.  

	- Role of P, I and V flags not clear

Greg:		In most cases you'd be reverse tunneling to the MAP,
		so maybe you don't need the P and I flags

James:		Relies on having to turn of ingress filtering.
		However re. FMIP, the MAP is going to be in the same
		adm. domain; but it might not here, so using these flags
		might open a security risk.

Greg:		Essentially, there is text about holding on to MAPs as
		long as you can, but if you use these flags you're going
		to loose your binding then. We need to take this to the
		list.

Gab:		I'd be in favour of deprecating these flags.

James:		That would be my preference too.

Gab:		Proposal to be confirmed by the list to remove these
		flags.

Greg:		Going on to the R flag, this is historic.
		It was for extended mode but now no extended mode. Will
		talk to Hesham about removing this.

	- Remove section 9. Hesham has expressed he's ok with this.

	- Add text to explain that a MAP further away from the MN may 
	  provide better location privacy.

That's about it, please send comments by next monday.

; 
; 5. WG discussion:  30 min
;    I-D: none
;    Moderator: chair
; 
;    Recent email exchanges have suggested for the working group
;    to produce a requirements (or "goals") document that, while
;    still limited to mobility at the IP level, would not be strictly
;    limited to MIP-based schemes (as the current LMM document is).
;    Another question is whether or not a thorough threats analysis
;    should be done by the working group, and if so, if this would
;    be captured in an existing document or in a new one.
;    This slot is aimed at discussing at least these questions, and
;    at finding WG direction in this respect.
; 

Gab: Current milestones go up to april, this should be a short-lived
working group, maybe end by July. Some people think that we should
recharter after that, but Vern Paxson is now about to start the mobility
research group (MOBOPTS), the charter is about done and the mobility list
will be created, so this is an alternative place to do experimental work.
Any comments from the floor?

James:		Short working groups are GOOD. Gives sense of
		accomplishment. It's fine to do the work shown on the
		slide in IRTF.

Carl:		What about location privacy? This is something we might
		consider doing here.

James:		Advice against that - this is not an easy problem to
		solve. We've done some work in NTTDoCoMo. Not sure it's
		even right for IRTF yet.

Greg:		Not sure. There are some things that can be done.

James:		Maybe a 1-page draft. But it would be a BCP, and maybe
		should be done in the IRTF. It's a deployment issue, and
		until these things are getting to be deployed, it's hard
		to get a grip on

Greg:		Why tie it to HMIP? If your HA is close enough, it's
		nothing to do with HMIP

Eric Nejdjou:	Do we need to deny new workgroup items just to keep the
		lifetime short?

Gab:		If we want to keep to the milestones, I think the answer
		is yes.  We can have the research group work for a
		while, and then maybe reopen MIPSHOP to take on new
		stuff.
	       
Basavaraj:	Rechartering might be a worthwhile thing in a year or
		so. 

Gab:		So new submissions would be individual submissions, and
		then when the milestones are done, then we could
		reconsider the charter.

Vijay:		Should complete current wg items and then come back to
		this issue in the next IETF.

James:		We can do as Basavaraj suggests, but I'll argue that we
		should shut down at the next IETF too 

Carl:		We're about to deploy MIPv6, till such a time Raj's
		comment about reevaluating later is a good idea.

Behcet:		DNA type of work falls into this wg, especially fast
		DAD. So I would encourage extending this working group
		to include this, and work on different link layers. Why
		generate a new group.

Thomas:		We have homes for that work already, so do we need to
		bring it over here? The thing is, do we have real work
		that needs to be done? Then we should do it. For
		instance location privacy, it would be nice to have it,
		but it's pretty profound, and is it the most immediate
		problem? Better to have some people work at it in the
		back room, and then when the work is well baked, then
		form a working group to standardize it.

Gab:		Ok, clear direction - till we finish the milestones, we
		won't discuss other stuff, and after that we can get
		back to this question.

; 
; Status of MIPSHOP WG I-Ds
; =========================
; 
; 1. draft-ietf-mipshop-lmm-requirements-00.txt
;    WG Last call
;         started:   oct 16
;         completed: oct 30
; 
; 
; 
; 2. draft-ietf-mipshop-fast-mipv6-00.txt
;    WG Last call
;         started:         nov 3
;         to be completed: nov 24
; 
; 
; 3. draft-ietf-mipshop-hmipv6-00.txt
;    WG Last call
;         started:         nov 3
;         to be completed: nov 24
; 
</pre>