1. NETLMM Tuesday PRELIMINARIES (10 minutes) Agenda review Blue sheets Notes and Jabber scribe WG status NETLMM got a liason statement from 3GPP2 asking for expedited process on PMIP6 (and 4) drafts. PROTOCOL DRAFT DISCUSSIONS ---------------------------------------------------------------- Topic: Proxy Mobile IPv6 Presenter: Sri Gundavelli Time: 30 mins Draft: draft-ietf-netlmm-proxymip6 - V4 support got split into a separate document - Text related to CMIP/PMIP and multilayer mobility got removed and some of them got put into a separate draft (CMIP/PMIP) - Policy store mandatory fields: o MN-ID, LMAA, Address conf modes - Policy store optional fields o MN-HNP, MN-HNP length - One more round or revisn needed for consistency and clarifying text - Issue #160: time stamp vs seq o Conclusion was to adopt time stamp based approach for PCU sequencing o Will be in -02 - Vogt: there are other approaches that coiuld be even faster than time stamps.. - christian: another approach could be to apply some intelligence to figure out MN has moved. - Sri: there is no mechanism to predict the MN is still on the access link or not. It takes few seconds for MAG to detect that MN has nmoved away. No mechanims to quickly identify that. - ahmad: context transfer. - sri: if there is CT mechanism, then they can synch the seq number. - Issue #161: netlmm scope o New text about the scope o george: if you justify domain using SA... a MAG may use different access technologies. MN may move between different technologies. PMIP is applied in that case too. Then there is the additional requirements on the MN to handle that case. This should be reflected in the I-D? o sri: we didn't specify interworking case. o raj: i agree with George. All different technologies can be considered part of the same domain o george: pmip works. but when the mags have different tech, then we need some support in the MN. o vidya: we have a requirement not to modify anything on the MN. o Raj: these are MN implementation specifics o Goeorge: you need some text itherwise MNs unaware of this will break connections. o christian: what's the worst that can happen? MN with the same IP address on two interfaces. that may be the issue. o George: this is an error case o Vijay: we should add a statement that in multiple interfaces case there might be a case where two or more interfaces have the same IP o sri: what is the view of the mobile? o vijay: that can happen today. two interfaces with the same IP address. o vidya: implementation may shut down one of the interfaces. o sri: we need to explore this. o ryuji: one of the BU will be rejected by the LMA. o christian: the same problem can happen with bridged networks. o sri: we need to figure out the details. this is a prefix route. o hesham: this is confusing. two mags advertising the same prefix. this could be an error case, or intentional. how do you tell the difference? o jonne: take it to the list. - Issue #162; renumbering o How the LMA notifies MAG about renumbering in not to be addresses in the spec. this requires some investigation and expansion on ICMPv6 messages - Issue #163; local routing on the MAG o Based on the conf it should be possible - Issue #164: MN-HNP allocation o Should it be LMA only, or should it be possible that MAG retrieves the prefix before contacting LMA? o Vijay: I think we concluded that LMA takes care of prefix management & allocation o Ahmad: there was a conclusion on other issue that prefix could be In profile o Vijay: in MIP6 we decided that prefixes are managed by HAs - Open issue ? auth option support o Should IPSec be the only mechanism for securing PMIP signaling? o Vidya: we need to have one mandatory security mechanism if we want to have the doc approved. o Alper: we must not exclude other security possibilities and not shut the door for other deployment options o Hesham; ? must support, not must use o Bound: you can?t say to clients (military, gm etc) that they must do this anf that.. o Jari: we cannot be protocol polices for deployments.. o Raj: there is a default option that must be supported.. there may be others in the future o Vidya: this is the default mechanism in the draft - Jonne; the doc is a bit hard to read.. it does need more work on it to be more readable as it has customers from people outside IETF. - issue 165 vijay: i thought we concluded that lma is the only entity that manages the prefix. sri: let's take this to the mailing list. the advantage I see is that LMA can deal with routing only, and prefix management is left to some other entity. vijay: we had the conclusion that home address only comes from the home agent on the mip6 mailing list. suresh: resolution of 156 does not work. ---------------------------------------------------------------- Topic: IPv4 Support for Proxy Mobile IPv6 Presenter: Ryuji Wakikawa Time: 20 mins Draft: draft-ietf-netlmm-pmip6-ipv4-support - there could be the old issue of changing DHCP address when MAG changes. New MAG should discard the unicast DHCP request and thus force the MN to DHCP REBINDING state instead of DHCP RENEWING state. - George: DHCP server must know the LMA it is associated with. How this is done? - Vijay: there are issues with having separated DHCP server from LMA. Better have only the one solution where LMA provides the address - vijay: bootstrapping integrated scenario has this documented. we can use something similar to that. - Sri: we are not defining these. They are up to the deployments; also, dhcp is not only for address allocation. - kuntal: dhcp relay in the mag is not a normal dhcp relay. dhcp relay shall also gate the dhcp responses from the dhcp server. we shall document such stuff. we shall assign the same IP address to the DHCP servers. whereever the MN goes, it sees the same IP address. - Kuntal: about separate DHCP server case ? if PBU fails then MAG needs to have a way to signal DHCP server that the address is not used. - ryuji: not a reasonable idea. it sounds like anycast. - Kuntal: WiMAX forum solved the changing DHCP server address by giving all DHCP servers/relays the same IP address. - Sri: - Kuntal: this separate DHCP server case a lot of undocumented issues. Those need to be documented - sri: the link is a p2p link. mag can intercept the messages with any IP address. - Vijay: what about other DHCP conf params. - Kent: there is PBU & DHCP sequencing details that need to be more clear. There should be an interface between LMA and DHCP server - Vogt: DHCp requests crossing admin domains.. this resembles the case of changing MAGs.. wy not just saying these are similar and put some text there. - Support all features specified in DSMIP. No changes required in DSMIP ---------------------------------------------------------------- Topic: MN-AR Interface Update Presenter: Julien Laganier Time: 10 mins Draft: draft-ietf-netlmm-mn-ar-if sri: on a p2p link,at what point do you see address collision? Sri: what other p2p links are you thinking than PPP ? It is not an issue in PPP. for other types, collision is a possibility. we have not resolved this yet. global domain-wide LL address is feasible. Jonne: there are multiple like GPRS, 802.16 etc Sri: we need to resolve possible AR link local collision issue.. as it is possible julien: what about storing the LL address in the MN profile? Sri: it's fine. Julien: then put it in your i-d. sri: what are the thing we need to specify for supporting send? julien: prefix belongs to home domain. sri: this is out-of band. is mag allowed to advertise this prefix.. julien: you can say it is provisioning. it's a deployment issue. vidya: we could pick a reserved IID. or specify a preferred algorithm for IID. sri: there is no reserved IIDs. Jari: we are assuming unmodified hosts Kuntal: this should not happen in real deployments PPP and GTP don't have this problem. In WiMAX, MAC address is a constant. Hesham: you cannot always use the MAC address.this is very rare case Jari: from witch EAP field you plan to extract the MN-ID? Is there any? julien: how you do it does not matter. jari: detials matter. it has to be possible. as an eap expert, I was not sure how it is possible. vidya: in eap, if you use a method with id privacy, id changes everytime. relying on eap does not work. we cannot apply pmip to open wifi. christian: you are changing the policy store from static to dynamic. I'm not saying it is a bad thing. but you need a signaling to update the store. julien: true. ---------------------------------------------------------------- Topic: PMIP6-MIP6 Interactions Presenter: Vijay Devarapalli Time: 30 mins Draft: draft-giaretta-netlmm-mip-interactions Three different deployment scenarios. - Alper: how to select different mobiity modes? it may be a protocol issue for radius and diameter. - george: how two mobiles using different protocols communicate with each other under the same mag. - Jouni: we have in Dime a way to signal what mobility modes are supported - raj: why does the ar need to know? it can advertise both. - vijay: then the MN needs to understand a new extension. - Daley: why does HA/LMA needs to be in home domain? It could be in the local voisited domain aswell - Vijay: they don?t have to be. - ---------------------------------------------------------------- ADDITIONAL DISCUSSIONS Topic: GRE for PMIP Presenter: Ahmad Muhanna Time: 10 mins Draft: draft-muhanna-netlmm-grekey-option - use cases: o overlapping private IPv4 addresses jonne: this is not in our charter. I'd like to postpone this to next meeting when we'll discuss rechartering. ---------------------------------------------------------------- Topic: Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6 Presenter: Behcet Sarikaya Time: 10 mins Draft: draft-xia-netlmm-fmip-mnagno - mobile node agnostic fast handover - temp tunel between pMAG and nMAG - context transfer - abstracted l2 dependency? - HI/ACKs & FBUs are used to transfer context between MAGs - Yokota: why not use separate messages for contexts transfer? - Xia: reuse of messages - Yokota: is should be possible to use HI/ACK in reactive mode aswell - jonne: waiting for rechartering. we are not going to ask that question (adopt as a WG item?) - ---------------------------------------------------------------- Topic: Route Optimization for PMIPv6 Presenter: Sangjin Jeong Time: 10 mins General Discussion - objective to gauge interest iof WG to PMIP6 RO - four different scenarios o MNs under same MAG are handled by the base doc o Different MAGS Under same LMA o MAGs under different LMAs o CN not under PMIP6 domain - Form a design team? Publish a doc as an individual before rechartering - Jonne; no official DT will be formed - jonne: we are not taking new WG items. if people are interested, they should contact the author. - Behcet: We have similar draft which was presented already in Prague.. scenarios are even same. This draft should at least mention it - ---------------------------------------------------------------- Topic: RO and Context Transfer for PMIPv6 Presenter: Marco Liebsch Time: 10 mins Draft: draft-abeille-netlmm-proxymip6ro - give LMAs some control for RO - select one LMA as a active RO controller - reuse PMIP control messages - different modes for RO setup o Direct: MAGs share a SA o Proxy: MAGs share a SA with the same LMA - More extensions.. reordering issues solved by the jaehwoon-netlmm-flush-00 - Behcet: two topics.. two drafts? - ---------------------------------------------------------------- NEXT STEPS (10 minutes) chairs, next steps jonne: get the authors submit next revisions hopefully the enxt revisions will be ready for WG LCs. we have a tight schedule put little extra effort into work. we'll go to rechartering.