[MBONED] Anaheim MBONED drafts minutes

[Leonard Giuliano <[e-mail]>]

The following are the draft meeting minutes from the MBONED meeting on 
Mon.  Special thanks to Gorry for being the scribe, as this was not an 
easy meeting to take notes.

Please take a look and let us know if anythying needs to be 
added/modified.

-Lenny


*******
IETF 77 Anaheim
MBONE Deployment WG (mboned) Agenda
Mon, March 22, 2010 1520-1720 PST

CHAIRS: Marshall Eubanks <[e-mail]>
        Lenny Giuliano <[e-mail]>
        Greg Shepherd <[e-mail]>          
         
Mailing list: [e-mail]

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 WGLC on both of those documents.
          
draft-atwood-mcast-user-auth-01
Bill Atwood
         
- Author would like feedback.

The meeting closed at 17:34.