Mobility for IPv4 WG ======================================================================= Friday, November 12, 2010 1300-1515 Afternoon Session I and II Emerald ======================================================================= CHAIRS: Henrik Levkowetz Pete McCann chair: henrik pete on jabber. no comments on the agenda. document status --------------- document status, see Henrik's slides. Charlie: this says rfc3344bis needs OK from me, but I already did that. Henrik: we'll check. we are in a good shape, very close to final. no worries. generic notification draft, approved. 3344bis. changes are fine the way Charlie proposed. Charlie: there are tons of editorial changes with the previous version. nemov4 dynamic Kent: no relation of nemo to 2006bis. Henrik: still needs a WG last call. did we have it already? need to check. Pete: 2006bis is more important. we need to get it finished. Kent: getting review on 2006bis is challenging. Kent: we need to change the order of last calls, so we don't hold things back. udp tunnel mib henrik: not sure if we'll ever able to complete that. Kent has the only possibility to complete. kent: it depends on 2006bis going thru. not sure about the status of this mib kent: there is really no body pursuing this draft henrik: correct. nobody to pick it up or fix it. i suspect we'll drop this. will verify on the list. Pete: it is ok to change the order of reviews. we need a reviewer for 2006bis mcbc henrik: ready for LC? Alper: nods yes. Charlie: haven't read it yet. haaro henrik: maybe ready for LC. gre key extensions henrik: there is a new version, fixing issues. multiple tunnel support henrik: do we need a new version? we need to kick people to look at this. kent, parviz, alper, can you look at this in the coming weeks? jouni will look at it. Home agent assisted route optimization (haaro), Jouni ----------------------------------------------------- (see slides) changes since 00. we have simulation work. we actually implemented it. we actually demonstrated it here. we had only few guys comment on it. we'll put out 03 version. then we'll be done on our part henrik: one more rev and we'll have last call. jouni: one more review will be good. henrik: either pete or I will do it. jouni: wait for the 03. pete: I'll commit to doing a review. gre extensions for mobile ipv4, parviz -------------------------------------- (see slides) charlie: why shouldn't be have a similar document for gtp encapsulation? henrik: you are considering writing one? charlie: I already wrote one 10 years ago, it was not taken. henrik: doews it make sense to have one? charlie: opinions will vary on that. parviz: that (gtp tunneling) seems to be more exciting. parviz: i guess that's a great idea. the only issue is, gtp carries other baggage. if you can clean that. gtp is more than mobility, due to 2g and 3g. charlie: you should only enable data encap. other interesting stuff is in control plane of gtp. henrik: i see no reason why we should not do it. jouni: gtp-u is another udp encapsulation of data. there is a bit of semantics in gtp-u. you'd keep this in data path encapsulation. kent: on the control plane we need to support concepts like PDP. kent: we need to find the reason why we need to change mip. i am not aware of any one planing to use mip4 with gtp. charlie: i cannot give you a deployment scanrio case. it's a low investment for high potential. parviz: gtp is a network based mobility protocol. did you mean client-based protocol? what would be the behavior of client mobile IP? henrik: if somebody sees a potential use, then we can do it. we can consider a draft. jouni: gre and udp encapsulation is the same. henrik: we expect a draft from charlie. kent: this is mip4 context. something else has to happen (to use mip4 with gtp). kent: if we are trying to justify gtp-u, i don't see the reason why ietf defining gtp-u as a standard in ietf wg. ----- henrik: any other topics? parviz: there is a disconnect beteween what we do in ietf and what the industry is promoting? like mip vs gtp. can we bring this to ietf? with operators involvement. henrik: this is becoming much bigger question than mip4. henrik: speaking as henrik as non-chair... we are already moving in that direction. some industry players having interest in gtp, are giving more attention to following and influencing what is happening at ietf. we may get even more of it than we want. we want coooperation and things that work togehter. we don't want strong industry to dictate what happens. they have certain apps and usages in mind, but we need to consider all usage. 'm happy with the gradual narrowing of the gap. i don't want to make that much faster. parviz: sadness of seeing so much effort put behind, like pmip. operators pushed pmip to aside. henrik: henrik as individual... i have a different take. pmip wasn't what the industry wanted. netlmm worked out a protocol, and design team took input from people in the industry. at the point where we were ready to adopt that design team spec, lot of industry representatives came and pushed for a different solution -- pmip. it was not what they needed. to me, this is the failure of ietf. we failed our standards. we adopted something that did not have rough consensus. it was majority decision from people who are not involved in the work. it's kind of funny to me in a sad way. kent: i was part of the design team as well. pmip was pushed aside for different reasons and not always technical. ntt docomo and verizon wanted ietf solution. but then over time certain operators have given up on it. they have their own rationale. verizon given up and moving to gtp. even for non-3gpp access. in some ways, it is not a protocol design, but a system design issue. you have to look at the overall system view. jouni: at that time I was working in a carrier. you didn't have established roaming with pmip. gtp had romaing. even moving from gto0 to gtp1 was hard. that was one of the reasons why it didn't fly. pete: there is no point in doing work with emulating gtp. we should be doing something more frontier working. parviz: ietf can become irrelevant. pete: we should look into aaa-driven model. henrik: we need to look forward close and further away. industry tends to focus on close. pete: actually I meant to say we move away from aaa. we can go with pki, like dnssec. charlie: if we propose an external mechanism that does not fit their business model, then we are telling them we don't want to participate.