12/3/07 - Session 1 Notes takers: Suresh Krishnan, Basavaraj Patil 1. Agenda and status update of Mobopts IRTF documents (Rajeev) 2. Location Privacy solution update (Fan Zhao) Suresh: Procedural issue because by putting in a bit you are updating RFC3775. Hence the bit does not work. Bill Atwood says a Mobility option is a better choice and can be assigned by IANA. Rajeev: Reverse tunnelling is already one way of providing location privacy. The two problems that have been identified are in RFC4882. Clarified what is the focus and primary goal of this work item in Mobopts. Rajeev: Two good reviews (Vijay D. and Heejin) has helped. Request others to review and provide feedback. 3. MPA draft (Yoshihiro Ohba) Rajeev: Are you sending sending a BU before the MN moves to the nAR? Yoshi: Yes. R: What happens if the MN does not move to the nAR? How do you recover from that? Y: MN should keep the old context and recover with that info. R: Proactive HOs can fail. Hence you need to consider the scenario. What do you mean by any mobility protocol? Y: Refering to SIP mobility, MIP or even HIP. R: In case of SIP mobility, why do you need a tunnel? Y: To send the Reinvite with the new CoA via the tunnel. Suresh: Comment about RtrAdvt - Does not thing that tunnelling the RA does not work. Rajeev: The tunnel is to the MN and not to the pAR. Rajeev: How does the MN know since the link-local can be the same. Suresh: Is not sure how ND messages over the tunnel will work. Rajeev: Need to discuss the ND aspects better. 4. Skitter Vs Dimes (Simulation study) - Look at slides. 5. MIP6 optimization and multihoming (Chan-wah Ng) - New proposal Suresh: How do you trust that the CN has multiple addresses? Chan: Shown in the slides. Gerardo: You cannot assume that the addresses are not bogus. Trust model is questionable. Rajeev: At the MIP layer the address to which we are moving has to be trusted. Chan: But the goal is to reduce signaling. Rajeevl: Some signaling may be justifiable Suresh: 1. You could override a valid address in the binding cache. 2. The 2nd address may not have a direct path to the MN and hence the address not usable. Ahmad: RO depends on the reachability of that address. Hence the trust model is broken if other addresses can be specified as reachable at other addresses as well. 6. Draft MMcastv6-ps Behcet: Is there any draft or work on the PMIP6 aspect? A: This is a potential area but a candidate for future work. Rajeev: Is MLD not a problem if we have context transfer? MLD signaling can be used to retrieve context ======================================= Discussion of Multimob - Suresh's slides giving an introduction to Multimob There was a bar bof in Chicago. - What are the problems that need IETF work w.r.t multicast? - Hui Deng (China Mobile) presenting the problem from MBS perspective Rajeev: All multicast traffic sent to the HA is sent as unicast to the MNs. So what extensions can we have on the HA to avoid multiple unicast tunnels to the ARs. The other aspect is the multicast join at the access router itself. Subir: Why unicast from the HA to the AR? A: Because that is how RFC3775 works. Suresh: If there is native multicast between the HA and the AR, how can we leverage that. Colin: Have you looked at AMT from moboneD? Rajeev: The current focus is on just understanding the problem. Hitoshi - IGMP and MLD for mobility support - Slides mention the I-Ds related to this discussion Bill Atwood: Get rid of MLD on wireless links. It is a PtP link and functions as a PtP link and hence use AMT. Colin: But AMT is going to send similar messages.... Bill: Something like AMT. Yoshi: Security aspects are missing and should be considered. Rajeev: Security is a general topic and hence we need to consider what security Yoshi is mentioning. Bill: If the target is IPTV you are not talking about a weak processor Alex: Is the assumption that MLD is expensive Thomas Schmidt: Multicast mobility PS Q: Layer 2 mobility and routing convergence at L3. Discussion. Behcet: Standardization of solutions Rajeev summarized the problem space discussion (See slides). - Queries how many people are interested in working on this domain - About 20 people - How many people would work on this even if no IETF WG is created - Fewer than 20 people ...................................................................................................................................................................................... Rajeev Koodli (RK) talks about the rg status L2 abstractions draft needs to clear irtf review and after that it needs to clear iesg review The boilerplate verification has been done by the IESG Most rg drats are almost done and new ideas are welcome The RG has been asked for its opinion on multimob work by Jari Arkko (INT AD) - specifically to enumerate problem space and highligt things that need ietf consideration - please keep this in mind for the discussions location privacy - Fan Zhao presenting ================ Fan wants feeback from the wg on whether we should use just a p bit or define a new mobility option. Suresh Krishnan (SK) wants to use an option since defining a bit needs to update RFC3775 and it is unclear how an RG RFC can do that Bill Atwood wants an option as well so that there are more possibilities open RK wants the problem solved here to be limited to those specified in RFC4882 RK thinks the draft is almost ready and he is willing to send it to IRSG review but he would appreciate more review/feedback Pre-authentication draft - Yoshihiro Ohba (YO) presenting ======================== This draft just became a rg item New version of draft addresses comments from expert review RK wants to know what happens if the bu is sent before the handover and the mn then decides to not handover. YO wants the mn to keep the old context (coA, keys etc.) RK thinks that this will not work the traffic will still go to the new address YO will work on a solution for this RK wants to understand what the phrase "works with any mobility management protocol" means? YO thinks the pro-active handover tunnels work with sip mobility, hip mobility etc. e.g. for sending a sip reinvite RK thinks it might take too long for a pro-active ho to complete YO thinks mobility patterns and geo information can be used to initiate pro-active handover even before the signal starts fading SK wants YO to consider how neighbor discovery works over tunnels Topology-based simulations of mobility-related protocol metrics - Mathias Waehlisch presenting =============================================================== Mw presented an overview of 2 large scale measurement projects: Skitter and DIMES how to use the data from these meas projects to simulate mobility protocols - pre process data - filter data to fetch relevant data - export data to simulator formats (BRITE in this case) skitter data is incomplete as compared to dimes since the monitor points are closer to each other and see similar paths (so the distribution is not that even) the goal is to figure out how internet graph characteristics affect mobility protocol metrics RK wants to know if they have measured inter-ar metrics Thomas Schmidt (TS) mentions that there is a shortage of measurement points close to the access and hence the metrics may not be accurate Mip6 optimization and multihoming - Chan Wah Ng (CWN) presenting ================================- This draft focuses on the performance of mip6 when mn,map or cn are multihomed extend rfc4651 SK wants to know how cn will prove ownership of addresses cWN will talk about this later There are two basic appraoaches - inter layer APIs (SCTP/shim6 informs mip6 of the addresses), MIP6 extensions cwn does not think this is an issue this may be an additional feature instead of an optimization Multicast mobility problem statement - TS presenting ==================================== Minor updates since chicago TS thinks there is really no need to change mld TS wants the rg to decide if this draft should cover transport layer issues. RK does not think so. colin Perkins (not sure of name) thinks the review audience is different, so separate document TS wants to consider issues related to multicast and multihoming ? Hitoshi Asaeda (HA) thinks tis is a tough problem and must be a separe document HA and SK tak about interface selection on join in a multihomed node Too involved to take notes. Raj was taking care of this.