Minutes for IETF 57 MAGMA Working Group meeting - Brian Haberman
<brian@innovationslab.net> and Isidor Kouvelas
<kouvelas@cisco.com> presiding.
Reported by Marshall Eubanks
<tme@multicasttech.com>.
There is a new version of the MLDv2 draft. The revised draft (-07) is
awating AD followup. There are also implementations available for Linux.
Rolland Vida - The revised draft reflects all the comments received from the
ADs.
Toerless Eckert - On the router side we (Cisco) have it too. Isidor -
Cisco also has a full host side implementation. Venkata Jagana from IBM - We
also have an implementation and would like to do
interoperability testing.
Rolland Vida - A full host and router side implementation is available
since September 2001 for FreeBSD. It was developed at LIP6-Paris
(actually, in collaboration with LSIIT-Strasbourg).
Brian - As a work item for myself I will talk to the IPv6 Node
Requirements author about including MLDv2 in the Node
Requirements.
The IGMP/MLD Proxy draft has been resubmitted following AD comments.
The SSM option for Multicast Router Discover has gone to last call but may be
affected by more general issues, such as whether or not there should be an
admin-scoped SSM address range and whether it (the SSM range) should be
variable.
The MSF API draft has passed working group last call.
Dave Thaler - To my knowledge, everything that has been brought up has been
addressed.
Brian - So we should be able to go to the IESG ?
Dave - Yes
The IGMPv3.MLDv2 draft is awaiting revisions to go to last call.
Isidor Kouvelas - MSNIP Update
The big issue is the support for ad hoc networks - i.e., networks which
have no routers.
Ad-hoc support requirement is that there is no modificiation in code in
existing receivers. Source control can only happen withing 232/8
Toerless Eckert - Why can't you configure a different range?
Isidor - Well you can, and that's one of the things that we have to
address.
In regard to the state issue (state being kept by source hosts as a
result of explicit tracking of (local) recevers) there was some
discussion on the mailing list and the consensus seemed to be that this was
not a big deal.
For robustness purposes there has to be a dummy querier, and the dummy
querier has to implement pretty much the full router side IGMPv3
protocol. Full router side requierment is because if a real router shows up,
they could loose the Querier election and then things will break.
Dave Thaler - I think that it would be OK to run without keeping any state
except for state on your own broadcasts.
Dave Thaler - As far as I know, this protocal is as scalable as the
underlying IGMPv3 protocols.
Toerless - IGMP is prone to attacks anyway
Dave Thaler - The WG messed up by not documenting the requirements in the
first place, when they were originally discussed.
Isidore. A new dummy bit is needed to distinguish dummy from real
queriers. Senders have to detect that they are on an ad-hoc link and join
the ALL_IGMPv3_Routers group. Potential senders need to directly process
these reports.
Pekka - I think it is interesting the huge amount of complexity that is
being added to account for this special case. I think that the working
group needs to consider carefully the need for this.
Isadore - The complexity is significant.
Dave Thaler - But then you need to know whether you are on an ad hoc
network.
This should have been part of the requirements document, but this
document was never completed.
Brian Haberman - The basic question for the Group is where do we want to go
with this? I will have Isidor send a note to the mailing list.
IGMPv3 - MLDv2 MIB - now has separate tables for host and router. Is this
what people want?
Dave Thaler - Yes, Except that the source list table also needs to be
split, and there is some useless information, such as for MLDv1 hosts.
I saw that it allows you to disable MLD snooping, which should not be
allowed.
Also, right now it only allows you to manage a MLDv1 or IGMPv2 host. That
should be changed.
|
