IETF 77 Anaheim MBONE Deployment WG (mboned) Agenda Mon, March 22, 2010 1520-1720 PST CHAIRS: Marshall Eubanks Lenny Giuliano Greg Shepherd Mailing list: mboned@ietf.org Greeting / Agenda bashing Review and status of work items draft-ietf-mboned-mtrace-v2 has passed WGLC. There were some issues brought up on the list, but the author appeared to address them. This draft and will be now submitted to IESG. draft-ietf-mboned-ipv4-uni-based-mcast will be submitted to IESG. Multimob WG Behcet Sarikaya - Review of WG status and future plans. He invites multicast experts to come to the meeting Thursday AM and participate. Marshall: Is the work focussed on mobile receivers? Behcet: Yes, this is the current charter. Source mobility is future work. AMT update: v6 checksum, sourcing, leave msgs Greg Shepherd/Tom Pusateri Greg discussed the v6 checksum issue. AMT has specified the use of zero checksums, but this requires an update to the IPv6 base specification. Ron: Is it at all possible to dance around this problem? Could we say AMT is supported in IPv4 only. Greg: AMT is a problem for IPv6 too, multicast tunnels will be needed in IPv6. Kurtis : I do not think that AMT is a transitional document. Tom: I think it is a bad idea to split the IPv6 support from the draft. Gorry: I'm speaking in 6man this IETF on a problem statement and transport recommendations on UDP checksums. I'd like to see 6man adopt this as a WG draft to clarify what the issues, pros, and cons are. Chairs: Do we maintain the position of requiring a change to IPv6 in the draft? Do we think we should remove the support for v6 in the draft? Greg: I think we will need translation mechanisms in the next Ron (AD): Can we make the IPv4 AMT go quickly? And leave the IPv6 part to move more slowly? Dino: We have built silicon to do it this way. The IETF needs to decide to follow the existing reality and change the IPv6 spec. Dino: We need to find a way to get IPv6 multicast started, and AMT is important for IPv6. Dave Thaler: IPv6 unicast is already provided. Toredo, etc do not support multicast. Stig: I would love to see the IPv4 draft progressed. Greg: We should proceed with fixing the current issues. If at that time, the IPv6 issues are not resolved, then let us then split-off the IPv6 parts to a separate document. Tom: These remaining issues will be resolved in the next few weeks. Brian: One of the issue here from 6man is also about who owns the IPv6 specification. 6man owned the base specification. This could be better handled in the transport area - this would get people with transport expertise. There was discussion about how best to progress this and liaise with the transport area, and it was decided to organise a meeting. Greg talked about possible removal of the source address from the draft. Dave Thaler: How is this different? Why do we need to leave out the source part? Greg: The source addresses are generated from the anycast address. If the two hosts are in different ASNs there is a problem. Tom: This is an Inter-domain problem? Greg: Yes. This is from implementors of gateways. Dino: The receiver part is stable, but the source part needs more thought. The draft needs a source mechanism. Do we need something that recognises a relay to provide sourcing services? Yes? Do we want to provide a mechanism, or leave it to other protocols? - This is like a tunnel-broker. Dave: I am trying to understand the problem. Looking at the figure in 5.2.2, this shows no relays. Greg: This does not work. Tom: This is not implemented. Greg: The current draft is not a scalable solution. Dave: If the scalability is a problem, you need to use a tunnel approach. Greg: No-one knows how many are needed to change the approach. I want a single connection upstream, not an interim small scale address solution. This is gateway to gateway problem. Dino: This seems OK. Greg: We can not RPF inter-domain. Dave: Take a case where you have a lot of native multicast receivers. My point is, every receiver will come from a relay. Greg: Why do they need a relay? Dave: Each sends to the nearest relay. For every receiver the join is coming for a different (native) relay. I am not against removing it, if we have a lack of consensus on how to do this. Greg: I want to remove the address allocation mechanism. Dave: I think you are arguing that we need an IPv4 equivalent for this. Another distinction is that AMT only supports sourcing of SSM. Greg: There have been DoS attacks on ASM, and this is not something that is of interest to me. Marshall: It would be good to see a summary of this written up to the list. Greg: I will wok with Dave to write this up. Thomas Morin: I sent a question to the list and would like feedback. Tom: Yes, we will send feedback to the list. The AMT tear-down message proposal was described by Tom Pusateri. The teardown message is a way of turning of a group of states. A NAPT can translate the addresses. STUN/ICE would be needed to find the actual source address. My preference to get this right. Dave: This does not need to be so complicated. Dino: This was a requirement to leave the groups and remove the tunnel state. Tom: i do not agree. If there is no membership, then there is no tunnel. Dino: There is a delay. Dave: Why is there a delay after the last leave? Dino: Because it is not said in the spec that this has to be removed straight away. there may be network management state. -: The spec is too silent on how to clean up state. Dave: Two relays do not need to do the same thing. Dino: The ATT people would like the gateway to control the state of the relay. Tom: The goal is to minimise the state in the relay. Dave: Do you compute on something independent of IP address, or on src and port. You need a lookup. Tom: If you put an independent value in the packet, then anyone can impersonate this. Dave: You can use a nonce that was independent of location. You need one of these two things. Rahul: What problem are we trying to solve. Tom: There is a time (equal to the Query Interval) which results in forwarding even after the receiver is disinterested, which cause down-stream capacity to continue to be used. Rahul: There seems to be confusion on the scenarios that cause this. There are many scenarios. Have we decided which we wish to change? Dino: We have to store various things that are kept with the tunnel. Tom: Why not teardown the state when the last group is left. Dino: This is hard state, once you have discovered the tunnel. When the gateway know you do not need it any more. Tom: It seems that you should get rid of state. Toerless: How do I get continuity of service? Why do we not use the MAC identifier? Dave: I think it is worth addressing the issue of data flowing to a gateway for 3 mins (the default). We could shorten the Query timer. Dino: The operators do not want to query too often. Greg: We cannot rely on a leave message when the receiver is not there. Tom: I do not see difference in a teardown or a leave all groups. Greg: You can't send a leave-all-groups when you are not there. We need to clean up the proposal. Tony Hansen: This is the problem. Greg: The main thing is being able to send an IGMP message from the new place that leaves all the groups. Tony Hansen: It is about leaving a group when you have a different address. Dave: Is this the same as in the mutimob case for mobility? Gorry: I think this may be similar, I see a need to send group membership reports from a new "tunnelled" to a new location. Behcet: This is not the same as multimob. Dino: Can we verify this using the MD5 hash? Dave: The previous protection was designed to protect this in combination with other fields. Dino: So even a request 64-bit nonce would be good. Dave: I do not know big we need, this is a security question. We will take further discussion to the list. draft-bipi-mboned-ip-multicast-pm-requirement-01 Vero Zheng Toerless: Is there any group that is looking at performance metrics for unicast. Vero: This is a multicast. Toerless: I think the design requirements are the same for unicast Ron: Please check the benchmarking working group. IPPM is also a group that looks at these questions about IP flows in a real network. Even if the work is done in say bmwg or ippm, this would be done in combination with this WG. Chairs: How many have read the draft? - About 15 people have read this draft. Chairs: Should this be done in another list? - split within the room. Stig: I think IPPM is a place with appropriate knowledge. Tom: I think the multicast expertise is here. Greg: We should co-ordinate between the groups and see where the expertise resides. draft-liu-mboned-multicast-realstream-monitor-01 Vero Zheng Chairs: How many have read the draft? - A fair number of people have read this. Toerless: This is just the same as unicast. I think this group does not really have a specific measurement expertise. I think we should only focus on things that are uniquely multicast in mboned. draft-cociglio-mboned-multicast-pm-00 Alberto Tempia Bonda Chairs: How many have read the draft? - Some have read the draft. -: Have you analysed how jitter impacts the packet loss monitoring. Alberto: Jitter does not result in packets crossing block boundaries. Toerless: Is this multicast-specific, there nay be other groups such as AVT that would be interested Alberto: This works with all traffic. -: How did you mark? Alberto: We used a set of DSCP values. -: Is there a way that does not interact with QoS engineering? Alberto: This was an experiment, we have not looked at this. draft-ietf-mboned-maccnt-req Hiroaki Sato draft-ietf-mboned-multiaaa-framework Hiroaki Sato - Authors would like advance both of those documents. draft-atwood-mcast-user-auth-01 Bill Atwood - Author would like feedback. The meeting closed at 17:34.