WG status Re-charter done. * New charter deliverables WG Document Status -Base protocol will be published as RFC soon. -IPv4 support needs more work. -MN-AR interface needs more review. Slow progress on this. Is WG still interested in this doc or not. (will ask same question later) Other - Binding Revocation is ongoing in MEXT. - Some PMIP HO optimization work is taking place in MIPSHOP. * Agenda Bashing Raj: presenting a proposal of modification to RS/RA in 6MAN. We should discuss this in NETLMM, too. It is relevant to PMIP-MIP interaction. I would like to get WG inputs to this work. Vidya: We have already rejected some presentation requests and a discussion on this is not feasible today. It's open to ask a question to the ML whether WG is interested in this or not. If not, this will be offline. * IPv4 Support for PMIP Raj: A question regarding why we need multiple IPv4 addresses assignment? What is the possible scenario? Sri: We just don't want to reject assigning multiple IPv4 HoAs. The use case is 3GPP. Vijay: 3GPP is not considering assigning multiple IPv4 HoAs. Even for IPv6 prefix, only a single IP address assignment case is being considered. Julien: Only one IPv4 address per host. Why do we need this multiple addresses assignment? Sri: for giving a binding, we allow multiple v6 prefixes. We should try to keep consistent between v4 support and the base spec. Raj: There is good reason to assigning multiple addresses. Rajeev: I did support multiple HoAs. Assigning multiple IPv4 HoA to MN is perfectly fine. Raj: Each PDN connection requires 1 HoA. Ahmad: we care only about 3GPP? every BC has only single HoA. If there are multiple HoAs, we will have multiple BCs. Rajeev: Do we need to prohibit this? Sri: Should the document say LMA cannot assign multiple HoAs with a BC. I want to keep it consistent with the base spec Jari: There seem to be no specific scenarios of having multiple HoAs. I don't think we need this. If not, it's better to take it out. Ahmad: the case of MAG behind NAT, what is the use case for MAG behind NAT. Sri: We cannot have assumption how a network is designed. Sri: This was discussed in the WG ML and previous meetings. MAG could be potentially behind NAT. MAG behind NAT should be kept. Suresh: can LMA and MAG locate in different domains? Ahmad: Can we move this MAG behind NAT parts to the appendix or somewhere-else? sri: we cannot have long appendix, only security consideration and small sections. Sri: Julien asked to define local flag to disable this option. We have already defined it. Ahmad: If this is not core requirements, why keep it in the main body of ID? Move it to appendix. Raj:Clarification: Proxy CoA could be private address. Sri: Yes. *MN- AR IF Sri: essentially trigger should be always generated at MN. How about trigger coming from network. I want to see changes about that. In the current documentation, the trigger is always from MN so far.? Pete: Let's take it into account. Not sure we can design that without modifications. Vidya: 6 people read the doc. Need more reviews. Is WG still interested in this document? how many people think this is useful doc? less than 10. Julien: In the beginning, there are many stuff included in the document such as shared link, DHCP and PPP-link. We took out many stuff and merged to the other documents. The left part is not such useful anymore. Vidya: FMIP work has similar issue how L2 trigger work with. Another question: How many people object to take down? Sri: We might require some interface specification. Vidya: If WG don't work on this document, can we drop it from charter. Jari: It is fine. No problem. Vidya: Take this discussion on the list and will make decision. * PMIP-MIP (Vijay) Alper: LMA and HA are in the same box, you cannot have access to different links. George: The box lookup HA rules first. then LMA rules. Hesham: BC is separately managed. Whether same box or not is not relevant here. Why do we need to mandate a single BC? Why this is requirements? Why are we working on such race condition. Raj: race condition is just corner case. George: multihoming cannot be achieved with single BC. Hesham: What you suggest is what George is proposing. ???: why do you gain to have two binding caches? If two people modify single entry, there is race condition. That's why it's better to keep them conceptually separated. Vijay: We do have a use case. 3GPP specify that scenarios. Hesham: The scenario is fine, but why single BC? Vijay: MN does not create two BCs at the same time. This is the most case. Hesham We cannot design protocol for the most cases. Vijay: that's why we have a solution for the race condition. George: your race conditioning does not support multihoming. Do you agree? Vijay: MCoA handle multihoming. HA has two separate bindings. We work multihoming from that MCoA document. Vidya: Please clarify the need for a single BC more clearly Vijay: This is implementation reason. Double the state per MN is costly. For a single radio handover, there is only one interface up and down. It's important to combine HA and LMA and to handle BC/PBC insert and removable promptly. As soon as either HA or LMA overwrites the entry, the packet can be continued transmitting. Marco: if we have multiple binding entries, are we going to have multiple forwarding entries? George: yes. Suresh: if this is implementation issue, this draft is not valid. Rajeev: We don't mandate anything in the doc for implementation. The race condition is corner case. Hesham: what is the probability number of the race condition? Vijay: intention is not doing multihoming. don't want to mandate logical separation for the implementation. Vidya: 3775-bis should spec say MN MUST or SHOULD to de-register binding from the HA. Currently there is SHOULD. The case of MN missing de-registration can be one issue. Jari: If there are implementation strategy, we do not support those. This looks fairly complicated. implementation things should be dropped. We should discuss why we have to support 1 BC (Scenario C). Ahmad: what happens if the MN does not send a de-registration? George: Nothing; the MIP binding still overrides the PMIP binding Vidya: several people coming to MIC write a email to summarize the comments. Vidya: logically separate BC is important about 15 single BC 5 don’t care: about 10 Take this to the list and continue discussion. Making conclusion based on discussion. * GRE key option for PMIP Vijay: there is case when LMA require GRE enpcasulation. Setup default behavior to handle all session instead of just drop and raise alarm. Ahmad: ask ext from Vijay. Julien: use case only to IPv4? Ahmad: We don't want to limit only to IPv4. We will clarify this. Sarikaya: alternative approach about MPLS.. What do you think about our document?! Ahmad: let's discuss on the list. Ahmad: asking WG doc adaptation. how may people adapting this as WG ID. many how many people object to this? Clear consensus in the room to adopt the document. To be verified on the list. * Radius jean-michel (jm): why does mag update address and not lma? jouni: mag knows the mn's address JM: mag and lma might not be in same administrative domain. jouni: there are several problems, e.g. DNS has deployment issues (?) julien: you use mip6 ha attribute to store address. why not pick a pmip6-lma attribute? Jouni: we will discuss * LMA discovery New MAG should get a new LMA. If you have use DNS, you can always get the same address. Jonne: AAA document already defined one way of LMA discovery. Rajeev: Scenarios can be for fully different scenarios. better to clarify what is needed for which scenarios. * MIB Vidya: what kind of information do you want to get? Which information do you want to retrieve? SOMEBODY: There are no requirements to mandate ASN.1 to write MIB. Glenn: Syntax is last part of MIB; that will be taken care of. * Vidya (WrapUp) Consensus call for GREKEY MIP6-PMIP6 interaction. everyone encourage to work on the list.