Skip to main content

Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-12

Revision differences

Document history

Date Rev. By Action
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for David Ward
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Ross Callon
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-11-07
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-11-07
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-11-07
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-11-06
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-11-06
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-11-06
12 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-11-05
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-11-05
12 Amy Vezza IESG state changed to Approved-announcement sent
2007-11-05
12 Amy Vezza IESG has approved the document
2007-11-05
12 Amy Vezza Closed "Approve" ballot
2007-11-05
12 Amy Vezza Intended Status has been changed to Informational from BCP
2007-11-05
12 (System) IANA Action state changed to In Progress
2007-11-02
12 Ron Bonica State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ron Bonica
2007-11-02
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2007-11-02
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2007-10-25
12 David Ward [Ballot Position Update] Position for David Ward has been changed to No Objection from Discuss by David Ward
2007-10-17
12 Ross Callon [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon
2007-10-17
12 (System) New version available: draft-ietf-mboned-routingarch-12.txt
2007-10-15
12 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2007-10-14
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-10-13
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-10-13
11 (System) New version available: draft-ietf-mboned-routingarch-11.txt
2007-10-05
12 (System) Removed from agenda for telechat - 2007-10-04
2007-10-04
12 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-10-04
12 Cullen Jennings [Ballot comment]
The text in the document was very different than the abstract and title had me expecting.
2007-10-04
12 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-10-04
12 David Ward [Ballot discuss]
Since this is a tutorial, why isn't this informational? There is no discussion of "practices."
2007-10-04
12 David Ward [Ballot discuss]
Since this is a tutorial, why isn't this BCP?
2007-10-04
12 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2007-10-04
12 Ross Callon [Ballot discuss]
Hopefully this is a minor issue. I think that this document means to move 3913,2189,2201,1584,1585 to Historic, rather than obsoleting them.
2007-10-04
12 Ross Callon [Ballot Position Update] New position, Discuss, has been recorded by Ross Callon
2007-10-04
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-10-04
12 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2007-10-04
12 Jari Arkko
[Ballot comment]
> Cisco's proprietary CGMP [CGMP] provides a solution where the routers
> notify the switches, but also allows the switches to snoop IGMP …
[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.
2007-10-04
12 Chris Newman
[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 …
[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.
2007-10-04
12 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2007-10-03
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-10-03
12 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-10-03
12 Tim Polk
[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 …
[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.
2007-10-03
12 Tim Polk
[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 …
[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...
2007-10-03
12 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-10-02
12 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2007-10-02
12 Russ Housley
[Ballot discuss]
I do not understand the reason to obsolete or make historic RFC 1585.
  Based on the title, it provides analysis and …
[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.
2007-10-02
12 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-10-02
12 Sam Hartman
[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 …
[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.
2007-10-02
12 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2007-10-02
12 Magnus Westerlund
[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 …
[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.
2007-10-02
12 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-10-01
12 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded by Lisa Dusseault
2007-09-25
12 Amanda Baber IANA Evaluation comments:

New IANA Considerations section has addressed IANA's Last Call questions.
2007-09-25
12 Ron Bonica State Changes to IESG Evaluation from Waiting for Writeup by Ron Bonica
2007-09-25
12 Ron Bonica Placed on agenda for telechat - 2007-10-04 by Ron Bonica
2007-09-25
12 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2007-09-25
12 Ron Bonica Ballot has been issued by Ron Bonica
2007-09-25
12 Ron Bonica Created "Approve" ballot
2007-09-25
10 (System) New version available: draft-ietf-mboned-routingarch-10.txt
2007-09-24
12 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-09-20
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell.
2007-09-19
12 Amanda Baber
IANA Last Call question:

While the document does not appear to request any IANA Actions,
it would obsolete RFC 1584, which defines three values …
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?
2007-09-10
12 Amy Vezza Last call sent
2007-09-10
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-09-10
12 Ron Bonica Last Call was requested by Ron Bonica
2007-09-10
12 Ron Bonica State Changes to Last Call Requested from In Last Call by Ron Bonica
2007-09-06
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2007-09-06
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Farrell
2007-09-05
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-09-05
12 Ron Bonica Last Call was requested by Ron Bonica
2007-09-05
12 Ron Bonica State Changes to Last Call Requested from In Last Call by Ron Bonica
2007-09-05
12 Ron Bonica State Changes to In Last Call from Last Call Requested by Ron Bonica
2007-09-05
12 Ron Bonica Last Call was requested by Ron Bonica
2007-09-05
12 Ron Bonica State Changes to Last Call Requested from Waiting for Writeup by Ron Bonica
2007-09-05
12 (System) Ballot writeup text was added
2007-09-05
12 (System) Last call text was added
2007-09-05
12 (System) Ballot approval text was added
2007-08-03
12 Ron Bonica State Changes to Waiting for Writeup from AD is watching by Ron Bonica
2007-08-03
09 (System) New version available: draft-ietf-mboned-routingarch-09.txt
2007-06-15
12 (System) State Changes to AD is watching from Dead by system
2007-06-14
08 (System) New version available: draft-ietf-mboned-routingarch-08.txt
2007-05-30
12 (System) State Changes to Dead from AD is watching by system
2007-05-30
12 (System) Document has expired
2007-05-23
12 Ron Bonica Responsible AD has been changed to Ron Bonica from David Kessens
2007-02-28
12 David Kessens State Changes to AD is watching from Publication Requested by David Kessens
2007-02-28
12 David Kessens
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 …
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.
2006-12-20
12 Dinara Suleymanova
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 …
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 -----------------------
2006-12-20
12 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-11-26
07 (System) New version available: draft-ietf-mboned-routingarch-07.txt
2006-08-15
06 (System) New version available: draft-ietf-mboned-routingarch-06.txt
2006-07-12
05 (System) New version available: draft-ietf-mboned-routingarch-05.txt
2006-06-28
04 (System) New version available: draft-ietf-mboned-routingarch-04.txt
2006-03-03
03 (System) New version available: draft-ietf-mboned-routingarch-03.txt
2005-10-13
02 (System) New version available: draft-ietf-mboned-routingarch-02.txt
2005-07-12
01 (System) New version available: draft-ietf-mboned-routingarch-01.txt
2005-04-26
00 (System) New version available: draft-ietf-mboned-routingarch-00.txt