Subject: D.C. IETF Minutes

From: Bill Fenner <[email-masked]>
Date: Mon, 10 Jan 2000 11:33:14 -0800 (PST)

Internet-Draft Multicast Remnants met in a single session at the DC
IETF.  The minutes were taken by Bill Fenner.

Bill Fenner gave a summary of the documents in the Working Group
and their status.  The DVMRPv3 spec and MIB had finished a Working
Group Last Call immediately before the meeting, however a comment
on the DVMRPv3 spec was brought up at the meeting so it will have
to go through another revision.  The DVMRP applicability statement
had been sent to the IDMR mailing list before the meeting; comments
were solicited at the meeting but none arose.

IGMPv2 needs a revision before being progressed to Draft.  The IGMP
MIB is ready for IETF Last Call; David Oran (Routing co-AD) promised
to find out its status.  IGMPv3 is just about ready for WG last
call; another revision is expected in January.  The IGMP Proxying
document finished a WG Last Call without comments, and the IGMP
router discovery spec is close to finished.

The multicast routing and PIM MIBs are also ready for IETF Last Call.

Domain-Wide Reports finished a WG Last Call with no comments.

Multicast Interoperability Rules was published as RFC2715.

Multicast Traceroute needs to be updated to discuss asynchronous
counters - routers that update packet counters in the forwarding
engine but only make that information available to the CPU periodically
and not on demand.

Brad Cain gave a summary of the updates to IGMPv3 in draft -02.
Major changes include cleanup of the document, especially the state
tables, and the ability to split group information across reports
if a host has too many sources in an INCLUDE.  Splitting doesn't
really work in EXCLUDE mode.  Updates still to be done include
adding the Query Interval and Robustness Variable to Query messages
so that Non-Queriers may set their timers based upon the values in
the message (instead of having to synchronize configuration across
all routers), explicitly state that the first message sent when
joining a group should be a State Change, and updates to the
compatibility and security sections.  This update is expected in
January.

There is an opaque field in the IGMPv3 spec to allow hosts to supply
authentication information related to joining a group; the question
was raised of whether or not people are thinking about how to use
that field.  The answer was that when someone comes up with a way
to use it, the API will be defined at that point.

Brad also talked about IGMP Router Discovery.  An extension to IPv6
neighbor discovery was added to allow Multicast Router Discovery
to occur in the normal IPv6 Neighbor Discovery process, while in
IPv4 it remains separate from IPv4 ICMP Router Discovery.  The
issue of using ICMP vs. IGMP in IPv4 was brought up, as well as
whether to extend IPv4 Router Discovery or create a new protocol
with the same state machine.

Ajit Thyagarahan talked about some limitations in the DVMRPv3
spec.  These are:
- It needs to talk about what happens when a neighbor's capabilities
field changes.
- It needs to explicitly say what happens when an interface goes
down.
- Generation ID's need to be per-interface, since the GenID MUST
change when an interface goes up or down, but changing it on all
interfaces when only one has changed state will generate instability.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 10 Dec 1999 18:14:16 -0800 (PST)

> with the same state machine.

Brad,
Have you defined a new Neighbor Discovery option?
Is it described in an I-D somewhere?

I always thought that all IPv6 routers would be multicast routers.
Is the purpose to handle the case when this is not true?

  Erik

---

From: [email-masked] (Jeremy Hall)
Date: Mon, 13 Dec 1999 12:09:55 -0500 (EST)

yes, let us not assume that all V6 routers will be multicast capable.

If the new router scene from V4 is anything to go by, the vendors want to
implement as little as possible, and the ISPs want to turn on as little as
possible.

It concerns me that the requirements for building a router are becoming
more complex and the router designers may choose to cut corners.  The
simpler we need it, the easier it is to implement, the faster it goes out
in the field, and the faster the bugs get found and resolved.

_J

Brian Haberman said:
> Erik Nordmark wrote:
> Erik,
>      The IPv6 support is defined in the I-D.  There is not a new option.
> We took two bits in the Router Advertisement so that L-2 hardware
> would not have to parse an option, it can look at a set offset to see if
> an IPv6 router is an active multicast router.
> 
>      Even though we would like to think that all IPv6 routers will be
> multicast routers, that may not be the case.  One reason would be
> that a customer configured the router to not forward multicast for
> some reason.  The other reason is that an L-2 device supporting
> this protocol for IPv6 may be attached to an IPv6 router that does
> not support this protocol.  So there had to be handling for those
> scenarios.
> 
> Brian
> 
> --
> Brian Haberman
> Advanced Network Research
> Nortel Networks
> [email-masked]
> 
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Dec 1999 09:09:52 -0500

Erik,

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Dec 1999 12:19:40 -0800 (PST)

> an IPv6 router is an active multicast router.

I assume the I-D is idmr-igmp-mrdisc.
The problem is lack of coordination.
The mobileip-ipv6 draft has picked one bit in the router advertisement
to carry the info that the router is a home agent.
The mobileip draft is on IESGs plate for proposed standard.
Thus the idmr draft needs to pick different bits.

> not support this protocol.  So there had to be handling for those

Ack.

   Erik