Simplified Multicast Forwarding
RFC 6621

[Ballot comment]
- In 6.1.3 and 6.2.2 it says SHA-1 is used to produce a 128 bit
value.  Which of the 160 output bits are used? (Not sure if that's
in 4302 or not - short of time, sorry:-)

- Even though you're not depending much on SHA-1 collision
resistance, if you could, using SHA-256 would be a better choice
today.

- 54 pages is a lot for something with "Simplified" in the title.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Simplified Multicast Forwarding) to Experimental RFC

The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Simplified Multicast Forwarding'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document describes a Simplified Multicast Forwarding (SMF)
  mechanism that provides basic Internet Protocol (IP) multicast
  forwarding suitable for limited wireless mesh and mobile ad hoc
  network (MANET) use.  It is mainly applicable in situations where
  efficient flooding represents an acceptable engineering design trade-
  off.  It defines techniques for multicast duplicate packet detection
  (DPD), to be applied in the forwarding process, for both IPv4 and
  IPv6 protocol use.  This document also specifies optional mechanisms
  for using reduced relay sets to achieve more efficient multicast data
  distribution within a mesh topology as compared to classic flooding.
  Interactions with other protocols, such as use of information
  provided by concurrently running unicast routing protocols, or
  interaction with other multicast protocols, as well as multiple
  deployment approaches are also described.  Distributed algorithms for
  selecting reduced relay sets and related discussion are provided in
  the appendices.  Basic issues relating to the operation of multicast
  MANET border routers are discussed, but ongoing work remains in this
  area, and is beyond the scope of this document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-smf/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-smf/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::External Party.
AD review

Hi,

I have dome my usual AD review prior to starting IETF last call. The
purpose of the review is to find any issues that might pop up during
last call or IESG review and (hopefully) smooth the passage of the
draft through the approval process.

This is a solid and well-written document. Thanks!

I had a concern about the IANA section, but this has been resolved in
discussions with the authors, chairs, and IANA. That leaves me with
just one concern (below). We can handle this through discussion and
possibly a revised version, depending on the outcome.

The document is in "AD Review :: Point Raised - writeup needed" state
while we sort this out.

Thanks,
Adrian

---

I am confused by the requirements for DPD.

In section 4 you hae:
  Interoperable SMF implementations MUST use a common DPD approach

In section 6 you also have:
  For IPv4 and IPv6, both, this document describes two basic multicast
  duplicate packet detection mechanisms: header content identification-
  based (I-DPD) and hash-based (H-DPD) duplicate detection.

And you go on to say:
  Because of the potential addition of a hop-by-hop option header with
  IPv6, all SMF routers in the same SMF deployments MUST be configured
  so as to use a common mechanism and DPD algorithm.

So, for a given IP family you have defined more than one DPD mechanism,
yet you require that all deployed routers in a network use the same DPD
mechanism.

Although one might hope that all nodes participating in an experiment
are set up the same way, your experimental networks are quite large and
I think you need to provide:
- a default DPD mechanism
- a way of detecting (and so alarming) a DPD mismatch.

State changed to AD Evaluation::External Party from AD is watching::AD Followup.
Hi,

A question for IANA and for the authors of the draft.

Can I have your advice about https://datatracker.ietf.org/doc/draft-ietf-manet-smf/
This document is shortly to go to IETF last call, but reading the IANA section I have a concern.

draft-ietf-manet-smf is flagged as Experimental

In Section 11.1, the document calls for an allocation from the "Destination Options and Hop-by-Hop Options" registry at http://www.iana.org/assignments/ipv6-parameters

The registration procedures for the registry are shown as "IESG Approval, IETF Consensus or Standards Action" but the registry also includes a number of code points reserved for experimentation (per 3692 as reserved by 4727). This leaves a choice...

1. Allocate a specific code point for this document since there will be an IETF last call and IESG review.

2. Utilise one of the code points reserved for experimentation, in which case no IANA action is needed.

Thoughts?

Thanks,
Adrian

State changed to AD is watching::Revised ID Needed from AD Evaluation::AD Followup.
A number of comments were raised in the the WG after publication was requested. I am therefore moving the document back to the WG for those comments to be addressed.

There was a review posted at

http://www.ietf.org/mail-archive/web/manet/current/msg11871.html

Please will the editors evaluate and address these comments, and then I will take a final read though and process.

1. Have the chairs personally reviewed this version of the Internet Draft (I-D), and in particular, do they believe this I-D is ready to forward to the IESG for publication?

YES.

2. 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 the ID has been adequately reviewed.

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

NO we do not have any particular concerns.

4. 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.

At numerous times there have been discussions about use of the IP ID field in non-fragmented IPv4 packets. The WG has indicated that inspite of this concern the specification should be published as an experimental RFC.

5. 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?

Although there has been some small disagreement on a few details, the document overall has significant support.

6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director.

NO.

7. Have the chairs verified that the document adheres to all of the ID Checklist items ?

The current document contains an obsolete reference, and the editor will update it in the next revision. This change does not affect the technical content of the document.

8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.)

YES the references are split into normative and informative references.

9. What is the intended status of the document? (e.g., Proposed Standard, Informational?)

Experimental.

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

* Technical Summary

This document specifies some simple mechanisms to distribute multicast data packets within a Mobile Ad-hoc Network (MANET).

* Working Group Summary

This document provides basic and simple multicast forwarding that can complement the on-going unicast routing protocol efforts. Additionally, this document describes several different reduced relay set algorithms that can be used to make multicast dissemination more efficient.

* Protocol Quality

Several interoperable implementations of SMF exist; although I am aware of only one being publicly available. Note: that several of the methods laid out in SMF have been included in many MANET protocols and their implementations.