Subject: [magma] MAGMA Minutes for IETF 56

From: Brian Haberman <[email-masked]>
Date: Mon, 31 Mar 2003 13:57:38 -0500

All,
      Here are the raw minutes from the meeting.  Please
submit clarifications, comments, or corrections to me by
Friday (4/4).

      Kudos to Marshall for taking the minutes.

Thanks,
Brian

-------- Original Message --------
Subject: MAGMA Minutes
Date: Mon, 31 Mar 2003 13:29:33 -0500
From: Marshall Eubanks <[email-masked]>
To: [email-masked]

Magma IETF 56

Agenda bashing

Bill Fenner has decided that with his AD work he cannot co-chair so
Isidor Kouvelas is the new co-chair.

Bill - So long and thanks for all the fish !

Julien Chesterfield - MIB update
IGMPv3 and MLDv2 MIBs

missed new draft deadline but is available on line

Name was changed to Multicast Group Membership Discovery (MGMD)

Time granularity changed to 10’s of seconds and milliseconds

New InetAddressType variable to sort between IPv4 and IPv6

Open issues

What variables should have read / write access ?

Discussion on this with Dave Thaler - variables that are adjustable
should have read write access.

Should statistics be per-port as well as per-interface or just
per-interface ?

Tom  Pusateri I would like to see a separate group table per interface.

Dave Thaler - Today the IGMP MIB sorts everything by group address. It
was thought to
be more interesting to say, “what interfaces does this group have ?”
rather than “What groups does this interface have?” This could be
changed, as this was settled about 8 years ago and conditions are
rather different today, but if you want the upgrade to be simple you
should keep this the same as the IGMP MIB

Bill Fenner - I very much like the source list, as an additional table.

Julian - I will add that to the next draft.

Tom  Pusateri - We have the concept of a local group join on a box, so
that the router  can join the group.

Bill Fenner - Could you represent this as a join on the loopback
interface ?

Brian Haberman - I have actually done this - if the router joins to the
group

Bill Fenner - I think that Tom is talking about the case where the
router does not generate any IGMP data and it is not really joined on
any interface

Tom  Pusateri - There is no interface.

Dave Thaler - It’s great to see so much discussion on a MIB in a
non-ops area.
In IGMP there is a mixture of information when you are a host or a
router, and if you split this into two tables things are much simpler.

Brian Haberman - Is there anyone here who would object to splitting
this into a router specific and a host specific part ?
<No complaints>
So, I ‘ll make a note to Julian to ask him to  make this change.

----
Brian Haberman - Document Status
3 documents are backed up at the IESG
Proxy draft
MRD SSM Option
IGMPv3 / MLDv2 Interactions

Other documents are at or just through working group last call.

Every document except the IGMPv3/MLDv2 MIB document is at working group
last call status or later.

----
Dave Thaler
Multicast Source Filter API
This document also missed the ID deadline.

Recap :
No open issues on the Basic (Delta-Based) API
API could be useful even if IGMPv3 / MLDv2 is not available

Mute and unMute is called Block and Unblock.

Some IPv4 specific socket options as the way you identify an interface
is different
IPv4 specific uses IP address
Advanced API is where the open issues are
Need to both get and set filter mode and source list

One open issue is whether the API should use getsockopt or even new
functions instead of ioctl

Austin Group (POSIX) discussion
3 principles

Lack of type safety is a bad thing which should be avoided
Name space pollution should be avoided
Existing practices should be standardized.

Neither getsockopt or ioctl is type safe.
The group seems to favor defining a new function
This allows you to put a wrapper over getsockopt or ioctl to implement
the new function

Therefore, for draft 04 want to
-take old ioctl api to Appendix as historical
- Define new type safe functions
- Added comments on implementation freedoms

A requirement
- Applications should be able to detect when the new source filter
API’s are not available and to
fail gracefully

Is this still a requirement ? Can it be done ? Should we restrict the
implementation freedom in any way ?

Bill Fenner - Are there still getsockopt calls ?
Dave Thaler - For the basic API there are still getsockopt calls, yes.
I believe that this requirement is atrun time, not compile time.

Pekka - The first part of the requirement is essential. The second is
not.

Dave Thaler - We expect that most people will use the basic API and
will not use the advanced API.

I am taking this discussion as tentative confirmation that new
functions are the way to go.

Bill Nickless - Why does this API include the interface ?
Dave Thaler - You can always pass a zero (?) if you do not know what
interface to use. It just supports the use of a specific interface if
you need to do that.

Bill Fenner. This is again one of these things where you cannot tell if
the buffer is completely filled when you do the call. If the buffer
gets completely filled you don’t know if it is exactly filled or if
there is more.
Dave Thaler - You could return an error and give the buffer as filled
as a special error case.
<groans from the audience>
Bill Fenner - You could return how many items are available total when
you do the call as an additional parameter

Dave Thaler - We should consider this and take it to the list.

(some discussion followed which revealed that the socket was missing
from the getipv4sourcefilter and the setipv4sourcefilter  parameter
list, whereupon it was duely added.)

Bill Fenner - since all of the other functions contain buffer lengths,
you need it here for the group as well.

We will add the socklent for the group list

Audience member - Question about interface index = 0
Dave Thaler - It is illegal for interface index to start with zero.
That is always the case and was intended to

Given that this has changed enough, I think that we should go for
another working group last call.

Brian Haberman - I think that we should put this to the list and

---
Dave Thaler
Operational Problems with IGMP snooping switches -
Good news - we are seeing IGMPv3 in operational use

Bad news - Since the start of 2003, at least three independent reports
of a problem

Problem - Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Router sends IGMPv3 query, which tells the host to use IGMPv3
Hosts send IGMPv3 reports

What then happens ?

Switch does one of these 3  :
1.) Doesn’t forward reports
2.) Forwards reports but does not forward data
3.) Forwards reports and data but no queries, data then times out

Result - Multicast breaks when you upgrade a router or host (whichever
is last) to IGMPv3.

Operational workarounds :

1.) Router is the authority. So only configure IGMPv3 on an interface
where there are _no_ IGMPv2 only switches.

- Problem is switch and router may be owned by different organizations
- If two customers share the same link, this means that the other
customer cannot run SSM ! (Without upgrading or changing the topology.)

2.) Customers have requested that hosts be configurable to force IGMPv2
use even though the RFC would use IGMPv3

- SSM would not work anyway
- This requries manual configuration on every node.

Isadore K. - If the IGMPv3 queries do not go through, then there is
still a problem

3.) Disable IGMP snooping entirely.

Does this affect the snooping draft ?

John Zwiebel - Let’s just fix this and not do kludgy work-arounds.
Dave Thaler - the problem is that there are not too many switches
Bill Nickless - there may be a hole in the spec if the host and the
router cannot tell what

Dave Thaler - The draft says that you
- flood any unrecognized IGMP
- flood the data to router ports (configurable to all ports) if there
are no reports for a group
- doesn’t cover the case where the report was received

This problem should be at least documented if not fixed if possible in
the snooping draft.

Brian Haberman - Another possible option
Joel Jaeggli - this is an existing problem not a potential problem, so
adding new features does not help much.

Dino F. There is no type variable in the query to tell the difference
between IGMPv2 and v3, the only clue is the length, and it may be a lot
to ask a snooping switch to look at that.

-----
Morten Jagd Christensen
IGMP and MLD snooping

Substantial comments
-Switch must not reject membership reports  because of source IP =
0.0.0.0

Dave Thaler - this is critical to have in there for the v6 section,
even more so than for the v4 section.

- Should be more systematic about topology changes
Don’t send a geneal query on all ports becuase a host is added to an
unused port.

We will take these changes and produce version 7
So, the real question is, what do we do next ?

Brian Haberman - The number of changes are enough that we should bring
this before the group
briefly before we take it to working group last call.

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma