Phil,
Opinions below:
-----Original Message-----
From: ext Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Wednesday, April 18, 2001 11:37 AM
To: 'mip-qos@research.nokia.com'
Subject: RE: [MIP-QOS] MIP QoS requirements
Hi,
I'd like to interject a few discussion items into what seems to be a most
productive dialog.
It's probably worthwhile thinking about which requirements we're discussing
are MIP specific. The AAA requirements draft has items which are not MIP
specific, but not a lot. This work should stay focused on requirements
which are closely coupled to MIP and its network model.
Would you consider keeping the discussion of location privacy separate from
this for now? We're not very sure what to do about it in general for MIP.
GM] It seems to me that people have been bringing in solutions to this problem for over 7 years both in the IPng and MIP WGs. It also seems to me that the MIP WG should learn from the past with respect to context transfer and the IPv6 HO WG about avoiding issues. They should also take note of the recent MIPv6 security rejection because of hand-waving away issues. This avoidance of the issue and trying to basically "hide your head in the sand" will only serve to slow the progress of MIP and its usefulness for deployment. IMO, other solutions based upon other protocols will likely take hold from a deployment perspective unless this "let's ignore the requirement" mentality is changed. I believe the issue will not be ignored in the new WG as others in other WGs, the IAB and the IESG are aware of it. In short, the avoidance of this issue and others is a bad policy to set. Other SDOs can't change IP. I'm sure they would if they could. The IETF can. IP signaling should be used to handle these requirements. I believe the privacy requirement was already brought up at the NSIS BOF anyway. So I don't think it is going to matter if the requirement comes from the MIP WG or not.
Wireless is obviously an area in which this will be used, but MIP has
managed to avoid being coupled too much to wireless so far and perhaps it
would be worthwhile decoupling this as much as possible. Perhaps there will
be a separate effort on QoS characteristics of particular links.
GM] Excuse me, but wireless is obviously the biggest customer for an IP that is built for mobility. This is like saying, let's create a solution just for my play-pen network or "Oh, this problem doesn't exist on ethernet - the link layer of wireless should be like ethernet so I don't want to help solve this problem". Again if you avoid the issues related to wireless, you will simply impede the "useful" MIP deployment into these networks and these networks will be promoting the use of coupled solutions when there really was no need. It seems to me that there is big timer running with MIP with the customers of these other SDOs and it is about to run out. The blatant and seemingly purposeful avoidance as you are illustrating is the reason why the MIP WG has been in existence since 1993 with the current lack of progress. This is also why there is a Seamoby WG, MIDCOM and why people came in with SIP mobility proposals as well. I do not believe these people are afraid to deal with these problems - why should you unless you wish to force these coupled solutions into these other SDOs. If this WG continues to avoid these issues you will simply have to continually rework any drafts and RFCs that have been done without considering these issues as time progresses.
I haven't seen any mention of the presence of a foreign agent. Does the
presence of lack of a foreign agent impact the requirements at all? What
about regional registration?
GM] Aaahh, doesn't this come from wireless requirements - why the change of heart all of the sudden? Sorry about the pounding but at least don't be a two-faced hypocrite. This isn't just directed at you.
From a requirements point of view can we really say anything more about
interactions with other protocol sets (such as diffserv, intserv) than allow
this kind of protocol in the paths between the mobile and the mobility
agent(s) or correspondents? And is saying even that too much? (I know this
is hard not knowing what the scope of the new working group will be).
GM] I don't think they are going to be just dealing with mobility related QoS issues.
Can we couch the discussion of fast recovery requirements in terms of the
failure of an FA/HA? Otherwise it seems not to be too connected to MIP.
GM] I do not know what you mean here. Are you saying you want to only include requirements for the HA/FA?
Phil