Overview of the Internet Multicast Routing Architecture
RFC 5110

Received changes through RFC Editor sync (changed abstract to 'This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.

This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.')

[Ballot comment]
> Cisco's proprietary CGMP [CGMP] provides a solution where the routers
> notify the switches, but also allows the switches to snoop IGMP
> packets to enable faster notification of hosts no longer wishing to
> receive a group.  Fast leave behaviour support for IGMPv3 hasn't been
> implemented.  Due to IGMP report suppression in IGMPv1 and IGMPv2,
> multicast is still flooded to ports which were once members of a
> group as long as there is at least one receiver on the link.
> Flooding restrictions are done based on multicast MAC addresses.
> IPv6 is not supported.

It was unclear to me where the words "implemented" and
"supported" refer to in the above. Are these things
intrinsic to CGMP, or do they relate to Cisco's implementation.
Its not clear that you want to discussion individual
implementations in this RFC.

[Ballot discuss]
Although the last call text mentioned the RFCs that will be made historic,
the current Ballot Approval Announcement Text does not mention those RFCs.
I'll move to "no objection" after that is fixed.

[Ballot comment]
Please add RPF to section 1.1.

Section 2.1.1 PIM-SM

While this is arguably the most important of the multicast
protocols, there is very little information about the protocol
here.  In fact, I got most of my information about PIM-SM from
comparative statements in section 2.1.2 PIM-DM.  Given its
importance, consider expanding this section.

[Ballot discuss]
I found this document to be very useful, and expect to keep it close for when I need to
sort out the multicast protocols.  However, I had problems in understanding several
tables, and they are a very important feature of this document.

There are five different values in the "cells" of the table in section 2.2.4: Yes, No,
Recommended, Doesn't work, and Few implementations.  I am unsure about the
difference between Yes and Recommended, and about the difference bewteen No
and Doesn't work.  (I am assuming that Few implementations means that it would
work but isn't widely deployed?)  I believe text or a legend is needed.

Section 2.3 Learning (Active) Sources includes subsections on SSM, MSDP, and
Embedded-RP but the summary table includes bi-dir single domain and PIM-SM
single domain.  I could only  find a single sentence in the intro to 2.3 that seems
to apply:

  Learning active sources is a relatively straightforward process with
  a single PIM-SM domain and with a single RP, but having a single
  PIM-SM domain for the whole Internet is a completely unscalable model
  for many reasons.

The information in the table is consistent (Yes for IPv4 and IPv6, with a status of
"for intra-domain only"), but I have no idea what mechanisms are used to find
the sources in this case.  An extra sentence or two in section 2.3 could probably
remedy the situation.

In section 2.6.3, the technique "Host receiving SSM" indicates IGMPv3 should be
used in IPv4 environments and MLDv2 in IPv6.  The Note for this technique is
rather cryptic: "Also SSM-mapping".  After some re-reading, I concluded that
"Host receiving SSM" can also be implemented using IGMPv1 and IGMPv2 in
conjunction with SSM mapping in IPv4 environments and can be implemented
with MLDv1 and SSM mapping in IPv6 environments?  I don't know if that's
correct, but I think some clarification is in order...

Section 2.7.3, the table entry for IGMP/MLD snooping has the following note:
      "Common, IGMPv3 or MLD bad"

Is this a reference to "hosts may recieve unnecessary muticast traffic ... if IGMPv3
or MLDv2 source filters are used" as stated in section 2.7?  In that case, "bad"
means more effective techniques for flooding reduction are available, but deployment
wouldn't cause system failure, right?  Perhaps a note following the table would
clarify the issues cleanly...

[Ballot discuss]
I do not understand the reason to obsolete or make historic RFC 1585.
  Based on the title, it provides analysis and experience.  Letting it
  remain as an Information RFC seems approprate.

[Ballot discuss]
I'm generally fine with the content of this document and I found it
useful.  I'm wondering though why it is a BCP.  What normative
statements is it making?  I found it more of a survey of how things
are than any statement of best practices.
This is a fairly weak discuss; the thing I'm most concerned about is making sure that we did not intend to make recommendations that are not clearly made.

[Ballot comment]
Appendix A.1

First of all the RMT WG has now gone beyond specifying experimental standards. A number of the building blocks have already moved to proposed standard and the first protocol instantiations are close.

Secondly, I think that NORM (RFC 3940) and FLUTE (3926) also should be mentioned when PGM is mentioned.

IANA Last Call question:

While the document does not appear to request any IANA Actions,
it would obsolete RFC 1584, which defines three values in
http://www.iana.org/assignments/ospfv2-parameters and one
value in http://www.iana.org/assignments/ospfv3-parameters.
Upon approval, should IANA replace references to RFC 1584 with
references to this document?

Reviewed draft:

Overall, I have few problems with this draft. However, this draft has
a large number of normative dependencies that are still drafts.

Because of this, the document will end up hanging in the rfc editor
queue for a significant amount of time if we would approve it now. At
the same time the world will continue to work further on multicast,
which will cause this document to be outdated already by the time we
get close to publication and thus requiring significant edits in
48-hours which is quite undesirable.

I propose that you either find a way to reduce the number of normative
references, or wait until at least a significant number of them have
been resolved and then update the draft and send it to the IESG for
approval.

Also, is there any particular reason why this draft is BCP as opposed
to Informational ? One could argue that BCP is appropriate, but the draft
is much more written in a 'informal' style and it is not quite describing
a best current practise as it seems more a summary of what people do
without really telling how one should do something as an operator.

PROTO Write-up

When a draft is ready to be submitted for publication, it is the task
of the Shepherding WG Chair to do a document write-up for the draft.
There are two parts to this task. First, the Shepherding WG Chair
answers questions 1.a to 1.h below to give the Responsible Area
Director insight into the working group process as applied to this
draft. Note that while these questions may appear redundant in some
cases, they are written to elicit information that the AD must be
aware of (to this end, pointers to relevant entries in the WG archive
will be helpful). The goal here is to inform the AD about any issues
that may have come up in IETF meetings, on the mailing list, or in
private communication that they should be aware of prior to IESG
evaluation of the shepherded draft. Any significant issues mentioned
in the questionnaire will probably lead to a follow-up discussion
with the AD.

The second part of the task is to prepare the "Protocol Write-Up"
which is used both for the ballot write-up for the IESG telechat and
for the the IETF-wide protocol announcement. Item number 1.i
describes the elements of the write-up. Please see other protocol
announcements in the IETF Announce archive for examples of such
write-ups.

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes, I reviewed this document and I think it is ready to
forward to the IESG for publication. Hiroshi Ohta is the WG
Chair Shepherd for this document.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes, I believe so. We conducted WGLC with -06 version. -07
version reflects the comment resolution which happend during
the WGLC.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No, I do not have any concern. The initial version of this
document was submitted about two years ago and there was no
negative comments up to now.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No, I do not have any specific concern.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

I believe the consensus is acceptable level. There are not
many comments on the ML but none of the comments are negative.


1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes. This check found no nits.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

Yes, this document splits its references into normative and
informative. Normative references include five (5) IDs.
However, all of them are WG documents (i.e., draft-ietf-...)
and all of them are quite mature (at least -05).

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

The lack of up-to-date documentation on IP multicast routing
protocols and procedures has caused a great deal of confusion.
To clarify the situation, this memo describes the routing
protocols and techniques currently (as of this writing) in use.
This memo also obsoletes and reclassifies to Historic a number
of older multicast protocols.


* Working Group Summary

There was not any controversy about this document. There are
not many comments on the ML but none of the comments are negative.


* Protocol Quality

This document surveys the currently proposed/used protocols but
it does not propose any new protocol.


1.j) Please provide such a write-up. Recent examples can be found in
the "Action" announcements for approved documents.

1.k) Note:

* The relevant information for the technical summary can
frequently be found in the abstract and/or introduction of
the document. If not, this may be an indication that there
are deficiencies in the abstract or introduction.

* For the Working Group Summary: Was there anything in WG
process that is worth noting? For example, was there
controversy about particular points, decisions where
consensus was particularly rough, etc.

* For the protocol quality, useful information includes:

+ Are there existing implementations of the protocol?

+ Have a significant number of vendors indicated they
plan to implement the specification?

----------------------- end -----------------------