Welcome to Etherpad Lite! This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents. 1) Administrativia Behcet - Went over agenda - We have 3 WG drafts and will discuss them - Will also discuss possible future work (3 or 4 items) - We now have 2 RFCs (6224 and 6636) from Multimob 2) Thomas presents Source Mobility update Thomas for introduction: - Objective: Define multicast source mobility for PMIP - 3 basic multicast scenarios - Current version tries to address many comments from Paris Behcet: Do you assume co-located functions (PMIP and MRIB)? Thomas: No Stig: Need to mention in I-D that operators can have multicast domains independent of each other Thomas: Yes, agrees that needs to be clarified Behcet: You assume no multicast listeners? Thomas: No Behcet: You assume no LMA? Thomas: No Thomas: Optimized source mobility option still needs more development and thought Juan Carlos: Do you need to send upstream to one single link (for multiple upstream proxy)? Thomas: Yes, only one upstream Juan Carlos: This is the similiar problem that we work on in our draft Seil: Do you mean extension of original MLD proxy? Thomas: Yes Seil: Then not appropriate here as it extends original RFC Thomas: Why? Seil: We need to agree to extend MLD proxy and then setup a design team Behcet: Are you saying we need another document? Seil: Yes Thomas: No, because that was the whole purpose of this document Seil: This seems outside scope of Multimob Stig: Charter says we cannot extend protocols. Then the question is whether MLD Proxy is a protocol or not? Behcet: Is this work going to be a separate draft? Thomas: No, it is part of this draft but still needs more work but will be in this draft Stig: Make sure this and the Juan Carlos draft are coordinated if there are extensions Thomas: I don't see extensions to PMIP structure for optimized multicast routing Juan Carlos: I definitely think that we have to look at problem at whole. And now we are bouncing between source and receiver mobility. Maybe we can hold this question until we present Thomas: Agree Seil: Not just not extending MLD Proxy. By using just multicast routing protocols we can still optimize Thomas: We just discussed this. If we deploy PIM-SM and have rapidly moving many sources then this is a disaster for PIM-SM. It is very inefficient and is not advisable. Stig: If we want to do proxy on the MAG, then have a PIM-SM router. Thomas: Yes, it is what was described in 2.1 Stig: There is a mistake in 3.2 for ASM vs SSM Thomas: Ok we will correct. 3) Juan Carlos (JC) presents Multicast Routing Optimization JC - draft has not been updated yet because we are still discussing some technical issues between the authors Thomas - What is the objective? This is supposed to be an informational document. What you are describing for SIPTO is not within scope Behcet - This will be decided by IESG Juan Carlos - This has been what we have had since beginning Thomas - Does your proposed document structure fit within the content of an I-D? You have some either/or options and I don't see how you do this in one document JC - It is an either/or decision in the MAG and we can describe it Thomas - I need to see some more details to be able to see what you want to do Marco - Is there a dependency on I-D gundavelli? JC - No Stig - You want to do policy per LMA or proxy instance? Not per user? Per user is much harder JC - The SIPTO is per user Stig - It has to be more like LMA and apply to a group JC - The issue is when we have multiple operators Stig - We should do policy per LMA (or proxy instance) and not per user Thomas - Similiar to Stig, proxy instance per LMA is different then your picture. And second is complexity. Stig - The picture that I had in mind, is that we have a single policy for a single proxy instance. Stig - It depends on who decides the policies Thomas - The MTMA cannot offer policies. Is that right? JC - We are still discussing this 4) Carlos presents Fast Handover updates Carols - All comments have been addressed. Request for final round of reviews and start WGLC Behcet - What about performance comparison? Will it be through simulations. Carlos - In next version Thomas - This solution corresponds to unicast transient binding solution from Marco. Why doesn't it reference it? Carlos - We can take a look at Marco's solution but we have been following WG consensus Carlos - Can chairs look for volunteers for reivews? Behcet - Good comment. - Thomas, Akbar, Costas volunteers to review I-D 5) Mike presents IGMP/MLD optimizations Mike - This may be more of a charter discussions then I-D details. It is out of scope according to charter. Stig - Might make sense to do it here rather than PIM WG as it is more mobility centric which is the expertise here Stig - Is unicast through L2 or L3 address? Mike - Good question. Could be either Thomas - Interesting work. Have you considered including MLD listener hold? Mike - May need to consider Behcet - Agree Stig - Right now this does not inlcude hosts. Adding Thomas idea would include hosts Mike - Yes, there is already some host impacts Brian - Time based solutions were previously an alternative. Now that PIM WG is active, can we take it there? Mike - Mobility expertise is here Brian - Still prefer that PIM WG does it and this group reviews Stig - This WG has more motivation. So suggest we do it here and review in PIM WG Brian - It can be done either way but maybe we can avoid re-chartering here and do it in PIM WG with reviews here Stig - We had some previous discussions here (that were considered out of scope because of protocol changes) that we may want to revive and include in this I-D 6) Juan Liu presents Route Optimization for Multicast Thomas - You have PIM signalling here. Do you require PIM to be deployed in MAGs? Juan - Yes Thomas - If you are at MAG1 and are Mobile 1, how do you know Mobile 2 is in MAG1? Juan - Message queries Seil - Can two mobiles be registered in same or different LMA? Juan - If in different LMAs then may require inter-LMA signalling. Using hop by hop IPv6 extensions. Stig - Can do this with PIM-SM and normal routing (BGP, etc) Thomas - In regular PIM there is no dynaic routing in the edge. But this is not regular PIM deployment. But is possible Brian - You may get pushback on hop by hop options for security reasons. Keep that in mind Juan - Okay. Behcet - Is this related to Thomas' draft? Thomas - Yes. Juan - Need some Route Optimization in your draft. Thomas - No Stig - It does seem similar to Thomas' draft but different topology Thomas - We haven't looked at pushing PIM at route optimizations. We assume fairly static MRIB with enough information Stig - So this draft has extended signalling compared to Thomas' draft Behcet - Thomas please review and see if you can work with Juan. 7) Seil presents DMM Multicast Seil - This was partially introduced previously by Dirk Hugo but this I-D takes it further JC - If you take base solution, there is a single upstream per proxy. What do you show here? Thomas - So you are describing a forwarding solution between MAGs? JC - Why would you get traffic directly through MAR2 as well as through tunnel? Seil - This is the problem definition and not the solution Carlos - What is the goal of the draft? Distributed approach to multicast? Behcet - Take this question to the list. 8) Thomas presents PFMIP handover Thomas - This is from before Multimob WG started and came from Mobopts WG. Asking chairs to adopt this. Joe - Draft is useful. Some comments already given on list. I support this. Carlos - We raised some comments several IETF's ago. But it is more a charter discussion regarding MN impacts. If this is allowed by the charter then it is okay with me. Stig - Ignoring charter, is this a useful I-D Stig - Asks for raise of hands for support or not. 4 or 5 people support. Stig - Need to talk to ADs further as there is interest. Brian - Why is there a concern for charter? Stig - Requires some changes to the MN and is that part of charter? Brian - MN nodes will raise complaints Thomas - Impacts to MN is not beyond PFMIP protocol Carlos - There were some changes beyond PFMIP for multicast subscription signalling Thomas - No this is not correct Behcet - Will discuss further on list