Multicast Mobility WG ====================================== Thursday, November 12 2009, 1300-1500, Room : Cattleya West IGMP/MLD for Mobility Hitoshi presents his ideas on how optimization can take place w/o protocol modification. Timers. Hitoshi proposes to come up with some cases and make value proposals for these. Hitoshi: various values ok, but one distinct value difficult. Thomas Schmidt: The number of retransmits is also important in wireless scenarios. Hitoshi: We should define characteristic values with respect to technologies. Suresh Krishnan: It would also be useful to explain how the modified values affect the protocol operations. Thomas: Slowing down the timers preserve WLAN resources but may affect protocol behaviour (cf. discussions on the mailing list). One has to discuss this part, as well. Hitoshi: I don't want to introduce very, very short intervals to cover mobility, it's harm. Light Weight IGMP/MLD. Jari thinks that profiling (e.g. as would be a pointing to LW protocols) is ok, guidelines should be given ... if this is not possible then state so. Marshall thinks that LW changes protocol - same situation is with unicast general query ... it may take decades for real deployment. (?) Jari: separate things - if LW changes the protocol, we should say so. But that is not task of this WG. Characteristics in wireless environment should be considered where and when affecting the protocol. Thomas: You say there are no cons to use MLD light, but there are advantages to use exclude mode in mobility regimes (cf. discussions on mailing list). Hitoshi: Why a mobile node needs exclude? Stig: In VoIP for example, you might want to exclude sources to preserve bandwidth, I guess. Unicast MLD Queries. Stig: Unicast MLD Queries might be supported but who has implemented this? I suppose there are no routers that have implemented the query part based on unicast. It would be Interesting to check existing implementations. Next Steps. No formal adoption of this draft for the charter item yet. It was agreed that the basic part of the draft would be a good basis. More people agreed to contribute. PMIPv6 solution documents. Each draft was presented shortly followed by heated debates on various issues. Multihoming. If MN is multi-homed (different MAGs), it has several interfaces, which may distribute traffic. That's something the MN has to do. It will get traffic twice, this optimization is out-of-scope and a normal multi-homing 'issue'. LMA-M. Q: Is each LMA an LMA-M? A: Not duplicate at each LMA but concentrated. Thomas: rerouting to other LMA-M or switch to one LMA-M! does this solve scaling problem? Suresh: split according to groups? Thomas: split according to MAGs because of uplink Suresh: no but then it's not standard MAG and LMA. Direct routing. Direct routing option is not in the charter. IPv4 support. IPv4 support is agreed to be in the charter. Context transfer. Hitoshi: You cannot do context transfer without protocol modifications. Stig: Context transfer is out of the charter. Handover Issue. Is it or not standard behavior that MLD Query is sent out after link change? Thomas: We have talked with Brian Haberman and he confirmed that MLD Query will be sent after link change. Kent: For IGMP it is not standard behaviour that Query is sent when link comes up. Consensus call: Multicast not locally available (no MLD Proxy at the MAG) forward IGMP/MLD to LMA, decap multicast data from LMA? None. IGMP/MLD Proxy at the MAG? 16 votes. Chairs. There is a consensus on proxy approaches. We have decided on a (technical) direction to go, not on a particular draft. ================================================================================================ Note-taker: Dirk von Hugo Chairs: Stig Venaas, and Behcet Sarikaya Thursday, November 12 2009, 1300-1500, Room : Cattleya West After administrativia Behcet welcomes all to the first Multimob meeting. Overview on agenda - last topics on future work only if time permits - priority is basic solution. Stig: because of charter limitations on basic solution Work will focus on basics but maybe in parallel on extensions ... Jari: Do the basics quick and well, so you can start enhancements Stig emphasizes that protocol modifications are out of scope. After Hitoshis MLD presentation we will see how this fits. Hitoshi presents his ideas how optimization can take place w/o protocol modification. Amount of traffic and receivers will change - how to cope with it via static parameter values? on pros and cons of standard membership tracking (RFC3376/3810). In IGMP/MLD query only active nodes should respond. Both unicast and multicast timer modification? explicit processing for mobility exclude join can enable security threat - LW-IGMP/MLD has finished WGLC explicit membership notification is nearly new function - will extend query intervals and thus is beneficial to save resources. Summary: only 3 of 5 proposals kept He concludes that draft is beyond tuning and could be changed to requirement draft. Question by Stig individually: draft is interesting and covers some details of charter. Specific question on timers - he proposes to come up with some cases and make value proposals for these. Hitoshi: variuous values ok, but one distinct value difficult. Stig will help Thomas also mentions retransmit timers - we need guidelines on characteristic values per technology. Suresh agrees with Stig and T.C. and proposes ...?? Thomas: Slowing down timers may affect operation (seamlessness) Hitoshi argues that too short timer for few real mobile nodes can be adverse. Thomas says that he didn't propose very small timers (15 ms) - but one should keep in mind that not all nodes use this. Stig asks whether implementations follow RFC that multicast nodes must respect unicast timers. Requirements for multicast nodes ? Thomas on con for exclude mode: use case where MN requests service that exhausts resources Stig on applications as videoconferences - chairs decide to continue discussion offline. CHARTER ITEM: How relates Hitoshis draft to charter demanding on value choice? Unicast general queries - Stigs personal opinion is yes. Hitoshi asks whether draft should be changed to requirements or he should change optimization to tuning. Chairs recommend to change title - stick to charter Suresh asks to include also mobile routers Thomas suggests to add section what to do if network supports general queries Stig thinks to simplify MN would be great Jari thinks that profiling (e.g. as would be a pointing to LW protocols) is ok, guidelines should be given ... if this is not possible then state so. Stig agrees that we currently are not sure. Marshal thinks that LW changes protocol - same situation is with unicast general query ... it may take decades for real deployment. (?) Jari: seperate things - if LW changes the protocol, we should say so. But that is not task of this WG. Characteristics in wireless environment should be considered where and when affecting the protocol. Stig asks whether the basic part of the draft would be a good basis? Not formal adoption, but seems to be a reasonable strategy. At the moment it is too early to decide - so we need more people contributing! No Objections?! PMIPv6 solution documents are presented: Please quick w/o detailed items (6 min!) Thomas starts presenting his slides. While sticking to a lightweight solution it performs as much as possible aggregation! MAG sends aggregated Join, answers on RSol with MLD query not always optimal, but may include direct routing option Questions and comments later after all presentations. Suresh next - LMA is responsible for multicast control. Answer on Marshals Q: no convergence/aggregation within this solution Seil: direct routing scenario needs H´FHO mechanisms Stig asks whether Seil agrees to potential merge with TC's proposal - yes he does. Guang presents: dedicated multicast LMA-M (tunnel not removed after HO because of other MNs) Marshal has Q: has each LMA location also LMA-M? Juan Carlos: not duplicate at each LMA but concentrated Thomas: rerouting to other LMA-M or switch to one LMA-M! does tis solve scaling problem? Suresh: split according to groups? Thomas: split according to MAGs because of uplink Suresh: no but then its not standard MAG and LMA ... Carlos J. proposes combined both MAG as MLD proxy and MC router - pMAG assists HO Now questions on all proposals: Carlos J. on Thomas' draft: performance cons of MLD query by nMAG, multihomed MN problem Thomas: signalling - yes for point to point, reply on new MLD query depends on interface definition - needs not if it doesn't want to Carlos Jesus: PMIP already supports several Interfaces Thomas: Mobility optimization regarding multihoming is out of charter Stig: MLD query Hitoshi: Context transfer is modification Stig: Context transfer is out of charter Carlos Jesus: clarifying question on charter whether MAG can be MC router (remote subscription) Stig: main focus is Remote Subscription Kent: only Downlink Multicast? Chair: Uplink (sender mobility) is out of charter! Juan Carlos: what to optimize: traffic on MAG or LMA? Optimize mobility or MC service establishment? Stig: 2 basíc solutions: 1) MLD proxy or Multicast Router on MAG - 2) LMA keeps MC status (too much traffic !) Kent: why? Stig: because MLD is replicated at LMA Kent: MIP focus on unicast, no customers for Multicast Guang: pros and cons of different solutions, convergence - no viable solution at the moment - we need evaluation Thomas: don't move problem to operators - if they deploy Multicast to MAGs, but can use it as option ... if there is an Operator already ... Marshal: When use one or other solution scenarios? Chair: charter to come to base solution Stig: whatever you decide on, this needs not exclude other solutions completely Chair: IPv4 support? Thomas: sees no problem except if Multicast streams are sent to Group address in IPv4 and IPv6 twice Stig also sees no problem chairs: Come to a WG draft? shows evaluation slides on each draft (here: Thomas'): tunnel convergence for different LMAs Stig: Is it standard behaviour that MLD query sent when link comes up? Hito: not standard Stig: we should propose this Kent: we can implement it Stig: should be sent immediately ASAP Carlos Jesus: other approaches to solve this are no extensions Juan Carlos: trigger can't come from MN chair: proxy MLD issue Kent: need to have L2 indication Thomas: PMIP needs to be aware of MN attachment Kent: WiFi? Chair stops this discussion MLD proxy or not - then: how to identify MNs MLD Link Local source addresses and TTL issues Carlos Jesus: other drafts? Stig asks for one of both (types) as basic solution Jouni: problem with double tunneling! Stig asks: Krishnan solution type as basic approach? none IGMP proxy at MAG: 16 who is uncertain/undecided: 2 Chairs: We have kind of decided on the direction - still have to find consensus on mailing list Juan Carlos: asks to upload chairs' (more personal) evaluation on the server Chairs promise to do so. Jouni: why in such a hurry? Stig: come to agree on a solution Jari: if basic stuff is complicated - do not sacrifice anything Stig: We continue active discussion on the ML session completed ========================================================================================= Multimob (Multicast Mobility BoF) IETF-76 Chairs: Stig Venaas and Behcet Sarikaya Note-taker: Matthias Waehlisch Behcet: Presented the agenda and the IETF Note-Well. Stig: Clarified the charter. First, we have to work on basic stuff, but keep working on optimization extensions in the background. Jari: Some motivation for the basic stuff: Do it fast and well, then you can work on optimizations. Stig: What do we mean with basics: Multicast support without changes to PMIP and other protocols. Hitoshi Asaeda: Presented "IGMP/MLD Optimization for Mobility Draft". Stig (as individual): Draft interesting, it covers different ways to solve some problems, which are part of the charter. However, charter is fairly strict. Split the draft. Regarding the timers, it is hard to find values that cover all scenarios. Hitoshi: Agree, it is really hard to find specific timer values. Maybe, we can introduce some correlations and describe situations. But it is really hard to define dedicated timer settings. We should clarify this discussion. Stig: ... Thomas Schmidt: The number of retransmits is also important in wireless scenarios. I agree with Stig and Hitoshi: We should define characteristic values with respect to technologies. Suresh Krishnan: I agree. It would also be useful to explain how the modified values affect the protocol operations. Thomas: Slowing down the timers preserve WLAN resources but may affect protocol behaviour (cf. discussions on the mailing list). One has to discuss this part, as well. Hitoshi: I don't want to introduce very, very short intervals to cover mobility, it's harm. Thomas: You cannot assume that MNs use this in the future. Stig (individual): Unicast MLD Queries might be supported but who has implemented this? I suppose there are no routers that have implemented the query part based on unicast. It would be Interesting to check existing implementations. Thomas: You say there are no cons to use MLD light, but there are advantages to use exclude mode in mobility regimes (cf. discussions on mailing list). Hitoshi: Why a mobile node needs exclude? Stig: In VCoIP for example, you might want to exclude sources to preserve bandwidth, I guess. Stig: Discussed the meaning of tuning IGMP/MLD. My personal opinion is, that it would be fine to support unicast-based MLD Queries if vendors have implemented this. Marshall: Are unicast MLD Qeueries part of the MLD light version? Hitoshi: The MLD light version does not change this aspect. Should we change the name of the draft to consider the described optimizations? Stig: Change the title. We cannot change protocols and nodes (s. charter). Suresh: You have to think about routers, as well. Thomas: A BCP contains advisory. You can add a section what to do if unicast general Query is supported. Stig (individual): It seems that lightweight MLD is orthogonal to mobility scenarios. Jari: There are multiple things: Specify exact timer values, may mean guidance; including the MLD light protocol is profiling. Stig (as individual): I am not sure if this could work or not work. Marshall: It seems that lightweight MLD really changes the protocol. Similar to the MLD unicast-based Query, this may introduce problems if there are nodes that do not support this. It takes decades to deploy updated MLD protocol versions. Jari: One have to separate: If MLD light changes protocol, we should state this. Consider wireless specifics when affecting the protocol. Stig: I suggest that Hitoshi separates basic parts of the document. A revised version of the document may be a basis. Additionally, more people should contribute to this MLD draft. Thomas: Presented "Minimal Deployment Option Solution Overview" Suresh: Presented "PMIPv6 Multicast Support Solution Overview". It does not very well comply with the charter. Marshall: Is there any aggregation? Suresh: No. Seil Jeon: Presented "Mobile Multicasting Support Solution Overview" Stig: Thomas suggested to merge these protocols. Is this your opinion, as well? Seil: Yes. Guang Lu: Presented "Multicast Services Solution Overview". Marshall: Would the multicast LMA be co-located with the unicast LMA? Guang: It doesn't have to be physical boxes, but the functionality is duplicated. Marshall: Does each location of the LMA have to deploy a multicast LMA, or is there a central one? Juan Carlos: No, you can concentrate multicast traffic. Thomas: You would be bound to one LMA. Otherwise severe handover problems may occur. It is not correct to say it solves the scaling problem as you add the avalanche problem to the LMA. Suresh: There can be multiple LMAs, but you need some way to split. Thus, I agree mostly to Thomas. Guang: We do not need one-to-one mapping between unicast and multicast. Thomas: I don't think the picture is right: You cannot split per group, you can only split per MAG. Carlos J. Bernardos: Presented "Multicast Service Delivery Solution Overview" Carlos: I have a question to Thomas' presentation. Your solution requires that each MAG sends an MLD Query. What are the cons in terms of signaling and battery? (2) What will happen if MN is multi-homed (different MAGs), what happens in the case of handover? Thomas: (1) Yes, there is MLD signaling, as well as router signaling (regular PMIP). That's of the same quality (w.r.t. point-to-point links). (2) If the MN is multi-homed, it has several interfaces, which may distribute traffic. That's something the MN has to do. It will get traffic twice, this optimization is out-of-scope and a normal multi-homing 'issue'. Actually, it depends on the interface selection by the MN. It is not really related to mobility. Behcet: Multiple interface selection is out of charter. Carlos: Agree with Thomas' reply, but not to Behcet comment. Stig (as individual): There are two options: (1) Context-transfer or (2) MLD Query. Hitoshi: You cannot do context transfer without protocol modifications. Stig: Context transfer is out of the charter. But MLD Query is standard behaviour of MLD routers. Carlos: Can we have multicast traffic between MAG and LMA? Stig: The charter says remote subscription. The question is if basic document leave it optionally. Kent Leung: Are multicast sources within the scope of the charter? Behcet: No. Juan: We have two choices: Avoid convergence on LMA or MAG. Which way we want to go? Should we optimize service continuity? Stig (as individual): We got two basic solutions: (1) MLD proxy at MAG (and multicast router if available), (2) Send MLD messages up to the LMA based on tunneling. The states have to be at LMA or MAG. I prefer the MLD proxy solution (personal opinion). Kent: I Agree with Stig, but when you are doing multicast router scheme ... you have states at MAG and LMA. Stig: ... Guang: Direct router solution: It doesn't fit into the charter. (2) Agree with similarities of the solutions. We probably don't have a one fit all solution. Probably, we should evaluate use cases and solutions before we go ahead? Thomas: I agree, the direct routing option is not in the charter. But if there is an operator that has deployed multicast, why not use it? Guang: But it requires to modify the charter. Thomas: Probably not if it is an option. Marshall: ... Stig (as individual): ... Behcet: Draft presented does not support IPv4. Thomas: There are no issues with IGMP proxying. Actually, there is a section on IPv4 support within the draft. Stig (as individual): All the proposals can easily be extended to IPv4. There is no problem. Behcet: It is not standard behavior that MLD Query is sent out after link change. This is an assumption in the draft presented by Thomas. Stig (as individual): I think if a link comes up, a router will send an MLD Query. Thomas: We have talked with Brian Haberman and he confirmed that MLD Query will be sent after link change. Kent: For IGMP it is not standard behaviour that Query is sent when link comes up. Stig: We can conclude: The node would sent on its own. The question is, how fast the query will be triggered. But that's not a problem. Carlos: There are other approaches that prevent this timer gap problem. Juan: That's what we tried to prevent. Behcet: If we go for the proxy approach, there is the timer gap. Just to highlight this problem. Kent: We need layer two indication. Thomas: This relates to PMIP. It is defined only for point-to-point links. PMIP needs to be aware of link changes. Behcet: We should decide between drafts presented by Suresh and Thomas. Carlos: Are we only decide on this two drafts? Stig: No, no, we decide on the technologies not on the specific drafts. The basic solution relies on one of these two alternatives (MLD proxy or non MLD proxy): Jouni Korhonen: The non MLD proxy solutions have the problem of double encapsulation! Should we consider the techniques described in Krishnan draft? none Should we consider MLD proxy? 16 How many people are uncertain? 2 Behcet: There is a consensus on proxy approaches. Stig: We have decided on a (technical) direction to go, not on a particular draft. Jouni: Why we hurry up? Stig: We have to agree on a solution with respect to milestones. Jari: Basic stuff has to be done to move to the interesting problems. However, we have not to sacrifice anything if solution space needs further investigation. Stig: We continue discussion on the mailing list. Thanks for coming and the good session. ============================================================================================ Note taker: Stig Thursday, November 12 2009, 1300-1500, Room : Cattleya West Behcet: Presented the agenda and the IETF Note-Well. Stig: Clarified the charter. First, we have to work on basic stuff, but keep working on optimization extensions in the background. Jari: Some motivation for the basic stuff: Do it fast and well, then you can work on optimizations. Stig: What do we mean with basics: Multicast support without changes to PMIP and other protocols. IGMP/MLD for Mobility Hitoshi presents his ideas how optimization can take place w/o protocol modification. Stig: Draft interesting, it covers different ways to solve some problems, which are part of the charter. However, charter is fairly strict. Split the draft. Regarding the timers, it is hard to find values that cover all scenarios. Hitoshi: Agree, it is really hard to find specific timer values. Maybe, we can introduce some correlations and describe situations. But it is really hard to define dedicated timer settings. We should clarify this discussion. Thomas Schmidt: The number of retransmits is also important in wireless scenarios. I agree with Stig and Hitoshi: We should define characteristic values with respect to technologies. Suresh Krishnan: I agree. It would also be useful to explain how the modified values affect the protocol operations. Thomas: Slowing down the timers preserve WLAN resources but may affect protocol behaviour (cf. discussions on the mailing list). One has to discuss this part, as well. Hitoshi: I don't want to introduce very, very short intervals to cover mobility, it's harm. Thomas: You cannot assume that MNs use this in the future. Light Weight IGMP/MLD. Jari thinks that profiling (e.g. as would be a pointing to LW protocols) is ok, guidelines should be given ... if this is not possible then state so. Marshall thinks that LW changes protocol - same situation is with unicast general query ... it may take decades for real deployment. (?) Jari: separate things - if LW changes the protocol, we should say so. But that is not task of this WG. Characteristics in wireless environment should be considered where and when affecting the protocol. Thomas: You say there are no cons to use MLD light, but there are advantages to use exclude mode in mobility regimes (cf. discussions on mailing list). Hitoshi: Why a mobile node needs exclude? Stig: In video conferencing for example, you might want to exclude sources to preserve bandwidth, I guess. Unicast MLD Queries. Stig: Unicast MLD Queries might be supported but who has implemented this? I suppose there are no routers that have implemented the query part based on unicast. It would be Interesting to check existing implementations. Stig: Discussed the meaning of tuning IGMP/MLD. My personal opinion is, that it would be fine to support unicast-based MLD Queries if vendors have implemented this. Marshall: Are unicast MLD Qeueries part of the MLD light version? Hitoshi: The MLD light version does not change this aspect. Should we change the name of the draft to consider the described optimizations? Stig: Change the title. We cannot change protocols and nodes (s. charter). Suresh: You have to think about routers, as well. Thomas: A BCP contains advisory. You can add a section what to do if unicast general Query is supported. Stig: It seems that lightweight MLD is orthogonal to mobility scenarios. Jari: There are multiple things: Specify exact timer values, may mean guidance; including the MLD light protocol is profiling. Stig: I am not sure if this could work or not work. Marshall: It seems that lightweight MLD really changes the protocol. Similar to the MLD unicast-based Query, this may introduce problems if there are nodes that do not support this. It takes decades to deploy updated MLD protocol versions. Jari: One have to separate: If MLD light changes protocol, we should state this. Consider wireless specifics when affecting the protocol. Stig: I suggest that Hitoshi separates basic parts of the document. A revised version of the document may be a basis. Additionally, more people should contribute to this MLD draft. Next Steps. No formal adoption of this draft for the charter item yet. It was agreed that the basic part of the draft would be a good basis. More people agreed to contribute. PMIPv6 solution documents. Thomas: Presented "Minimal Deployment Option Solution Overview" Suresh: Presented "PMIPv6 Multicast Support Solution Overview". Marshall: Is there any aggregation? Suresh: No. Seil Jeon: Presented "Mobile Multicasting Support Solution Overview" Stig: Thomas suggested to merge these protocols. Is this your opinion, as well? Seil: Yes. Guang Lu: Presented "Multicast Services Solution Overview". Marshall: Would the multicast LMA be co-located with the unicast LMA? Guang: It doesn't have to be physical boxes, but the functionality is duplicated. Marshall: Does each location of the LMA have to deploy a multicast LMA, or is there a central one? Juan Carlos: No, you can concentrate multicast traffic. Thomas: You would be bound to one LMA. Otherwise severe handover problems may occur. It is not correct to say it solves the scaling problem as you add the avalanche problem to the LMA. Suresh: There can be multiple LMAs, but you need some way to split. Thus, I agree mostly to Thomas. Guang: We do not need one-to-one mapping between unicast and multicast. Thomas: I don't think the picture is right: You cannot split per group, you can only split per MAG. Carlos J. Bernardos: Presented "Multicast Service Delivery Solution Overview" Carlos: I have a question to Thomas' presentation. Your solution requires that each MAG sends an MLD Query. What are the cons in terms of signaling and battery? (2) What will happen if MN is multi-homed (different MAGs), what happens in the case of handover? Thomas: (1) Yes, there is MLD signaling, as well as router signaling (regular PMIP). That's of the same quality (w.r.t. point-to-point links). (2) If the MN is multi-homed, it has several interfaces, which may distribute traffic. That's something the MN has to do. It will get traffic twice, this optimization is out-of-scope and a normal multi-homing 'issue'. Actually, it depends on the interface selection by the MN. It is not really related to mobility. Behcet: Multiple interface selection is out of charter. Carlos: Agree with Thomas' reply, but not to Behcet comment. Stig: There are two options: (1) Context-transfer or (2) MLD Query. Hitoshi: You cannot do context transfer without protocol modifications. Stig: Context transfer is out of the charter. But MLD Query is standard behaviour of MLD routers. Carlos: Can we have multicast traffic between MAG and LMA? Stig: The charter says remote subscription. The question is if basic document leave it optionally. Kent Leung: Are multicast sources within the scope of the charter? Behcet: No. Juan: We have two choices: Avoid convergence on LMA or MAG. Which way we want to go? Should we optimize service continuity? Stig : We got two basic solutions: (1) MLD proxy at MAG (and multicast router if available), (2) Send MLD messages up to the LMA based on tunneling. The states have to be at LMA or MAG. I prefer the MLD proxy solution (personal opinion). Kent: I Agree with Stig, but when you are doing multicast router scheme ... you have states at MAG and LMA. Guang: Direct router solution: It doesn't fit into the charter. (2) Agree with similarities of the solutions. We probably don't have a one fit all solution. Probably, we should evaluate use cases and solutions before we go ahead? Thomas: I agree, the direct routing option is not in the charter. But if there is an operator that has deployed multicast, why not use it? Guang: But it requires to modify the charter. Thomas: Probably not if it is an option. Marshal: When use one or other solution scenarios? Behcet: charter to come to base solution Stig: whatever we decide on, this needs not exclude other solutions completely Behcet: Draft presented does not support IPv4. Thomas: There are no issues with IGMP proxying. Actually, there is a section on IPv4 support within the draft. Stig: All the proposals can easily be extended to IPv4. There is no problem. Behcet: It is not standard behavior that MLD Query is sent out after link change. This is an assumption in the draft presented by Thomas. Stig: I think if a link comes up, a router will send an MLD Query. Thomas: We have talked with Brian Haberman and he confirmed that MLD Query will be sent after link change. Kent: For IGMP it is not standard behaviour that Query is sent when link comes up. Stig: We can conclude: The node would not send report on its own. The question is, how fast the query will be triggered. But that's not a problem. Carlos: There are other approaches that prevent this timer gap problem. Juan: That's what we tried to prevent. Behcet: If we go for the proxy approach, there is the timer gap. Just to highlight this problem. Kent: We need layer two indication. Thomas: This relates to PMIP. It is defined only for point-to-point links. PMIP needs to be aware of link changes. Behcet: We should decide between drafts presented by Suresh and Thomas. Carlos: Are we only decide on this two drafts? Stig: No, no, we decide on the technologies not on the specific drafts. The basic solution relies on one of these two alternatives (MLD proxy or non MLD proxy): Jouni Korhonen: The non MLD proxy solutions have the problem of double encapsulation! Should we consider the techniques described in Krishnan draft? none Should we consider MLD proxy? 16 How many people are uncertain? 2 Behcet: There is a consensus on proxy approaches. Stig: We have decided on a (technical) direction to go, not on a particular draft. Jouni: Why we hurry up? Stig: We have to agree on a solution with respect to milestones. Jari: Basic stuff has to be done to move to the interesting problems. However, we have not to sacrifice anything if solution space needs further investigation. Stig: We continue discussion on the mailing list. Thanks for coming and the good session.