--------------------------------------------------
MIPSHOP (MIPv6 Signaling and Handoff Optimization)

--------------------------------------------------


THURSDAY, November 13, 2003
1530-1730 Afternoon Sessions II


CHAIRS: Gabriel Montenegro <gab@sun.com>



tnx,


-gabriel
		
Minutes by:
	Henrik Levkowetz <henrik@levkowetz.com>
	Behcet Sarikaya <behcetsarikaya@yahoo.com>

Some edits by the chair.

; MIPv6 Signaling and Handoff Optimization WG (mipshop)
; 
; THURSDAY, November 13 at 1530-1730
; ==================================
; 
; CHAIRS: Gabriel Montenegro <gab@sun.com>
; 
; 
; 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
;