[manet] WGLC Review of draft-ietf-manet-smf-11.txt

[Thomas Heide Clausen <[e-mail]>]

All,

Below, my comments to the latest version of the SMF I-D.

> 
> 
> 
> Network Working Group                                  J. Macker, editor
> Internet-Draft                                                       NRL
> Intended status: Experimental                            SMF Design Team
> Expires: September 15, 2011                                IETF MANET WG
>                                                           March 14, 2011
> 
The RFC Editor did in a previous document (NHDP) request that design-team be listed in the contributors section, and not in the author's section. If I understood correctly, this was a strong request, so I suggest that this be reflected in also SMF.
> 
>                     Simplified Multicast Forwarding
>                         draft-ietf-manet-smf-11
> 
> Abstract
> 
>    This document describes a Simplified Multicast Forwarding (SMF)
>    mechanism that provides basic IP multicast forwarding suitable for
>    wireless mesh and mobile ad hoc network (MANET) use.  SMF defines
It may be worth noting in the abstract that the term "multicast" in this context relates to "manet-wide broadcast", and that no groups or group-driven broadcast tree pruning is in scope?
>    techniques for multicast duplicate packet detection (DPD) to be
>    applied in the forwarding process and includes maintenance and
>    checking operations for both IPv4 and IPv6 protocol use.
It is a bit unclear what "maintenance and checking operations" are or are for.
>   SMF also
>    specifies mechanisms for applying reduced relay sets to achieve more
>    efficient multicast data distribution within a mesh topology versus
>    simple flooding.  The document describes interactions with other
>    protocols and multiple deployment approaches. 
"Other protocols" - more specifically, which?
>  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 beyond the scope of this document.
> 
> 
<SNIP>
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 4]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
> 1.  Requirements Notation
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    [RFC2119].
> 
> 
> 2.  Introduction and Scope
> 
>    Unicast routing protocol designs for MANET and wireless mesh use
>    often apply distributed algorithms to flood routing control plane
>    messages within an interior wireless routing domain.  For example,
>    algorithms specified within [RFC3626] and [RFC3684] provide
>    distributed methods of dynamically electing reduced relay sets that
>    attempt to efficiently flood routing control messages while
>    maintaining a connected set under dynamic topological conditions.
> 
>    In one sense, Simplified Multicast Forwarding (SMF) extends the
"In one sense"? Suggest removing.
>    efficient flooding concept to the data forwarding plane.  Therefore,
Suggest removing "Therefore,"
>    SMF provides an appropriate multicast forwarding capability for use
>    cases where localized, efficient flooding is considered an effective
>    design approach.  The baseline design is intended to provide a basic,
>    best effort multicast forwarding capability that is constrained to
>    operate within an interior MANET or wireless mesh routing domain.  An
>    SMF routing domain is an instance of a SMF routing protocol with
>    common policies that is under a single network administration
>    authority.  The main design goals of this SMF specification are to
>    adapt efficient relay sets in MANET type environments [RFC2501] and
>    to define the needed IPv4 and IPv6 multicast duplicate packet
>    detection (DPD) mechanisms to support multi-hop, packet forwarding.
> 
> 2.1.  Terminology
> 
>    The following abbreviations are used throughout this document:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 5]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>             +--------------+---------------------------------+
>             | Abbreviation | Definition                      |
>             +--------------+---------------------------------+
>             | MANET        | Mobile Ad hoc Network           |
>             | SMF          | Simplified Multicast Forwarding |
>             | CF           | Classical Flooding              |
>             | CDS          | Connected Dominating Set        |
>             | MPR          | Multi-Point Relay               |
>             | S-MPR        | Source-based MPR                |
>             | MPR-CDS      | MPR-based CDS                   |
>             | E-CDS        | Essential CDS                   |
>             | NHDP         | Neighborhood Discovery Protocol |
>             | SMF-DPD      | SMF-Duplicate Packet Detection  |
>             | I-DPD        | Identification-based DPD        |
>             | H-DPD        | Hash-based DPD                  |
>             | HAV          | Hash-assist Value               |
>             | FIB          | Forwarding Information Base     |
>             | TLV          | type-length-value encoding      |
>             | DoS          | Denial of Service               |
>             +--------------+---------------------------------+
> 
It is a little untraditional to have terminology as a table, alas, that is not in itself a problem. However, the table simply "expands acronyms", but doesn't really explain what they mean. "MPR", "S-MPR", "MPR-CDS" and "E-CDS", for example, may be well understood within the narrow MANET community, a bit less elsewhere. Suggest either a somewhat more verbose description, or informative references cited (or both) ?
> 
> 3.  Design Overview
> 
>    Figure 1 provides an overview of the logical SMF node architecture,
>    consisting of "Neighborhood Discovery", "Relay Set Selection" and
>    "Forwarding Process" components.  Typically, relay set selection (or
>    self-election) occurs based on dynamic input from a neighborhood
>    discovery process.  SMF supports the case where neighborhood
>    discovery and/or relay set selection information is obtained from a
>    coexistent process (e.g., a lower layer mechanism or a unicast
>    routing protocol using relay sets).  In some algorithm designs, the
>    forwarding decision for a packet can also depend on previous hop or
>    incoming interface information.  The asterisks (*) in Figure 1 mark
>    the primitives and relationships needed by relay set algorithms
>    requiring previous-hop packet forwarding knowledge.
I do not think it quite clear what the "asterisk-notation" means, at least I had to do a double-read on it. Would it not be clearer to draw the figure without, and textually mentioning that not all algorithms necessarily needs all information - with reference to the algorithm descriptions?
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 6]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>                 ______________                _____________
>                |              |              |             |
>                | Neighborhood |              |  Relay Set  |
>                |  Discovery   |------------->|  Selection  |
>                |   Protocol   |   neighbor   |  Algorithm  |
>                |______________|     info     |_____________|
>                       \                              /
>                        \                            /
>                 neighbor\                          /forwarding
>                   info*  \      ____________      /  status
>                           \    |            |    /
>                            `-->| Forwarding |<--'
>                                |  Process   |
>              ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
>              incoming packet,                 forwarded packets
>              interface id*, and
>              previous hop*
> 
>                       Figure 1: SMF Node Architecture
> 
>    There are certain IP multicast packets, defined later in this
>    specification, that are "non-forwardable" and these multicast packets
>    will be ignored by the SMF forwarding engine. 
Suggest rephrasing/adding how these multicast packets are identified? Presumably by their addresses....?
>  The SMF forwarding
>    engine MAY also work with policies and management interfaces to allow
>    additional filtering control over which multicast packets are
>    considered for potential SMF forwarding.  This interface would allow
>    more refined dynamic forwarding control once such techniques are
>    matured for MANET operation.  At present further discussion of
>    dynamic control is left to future work.

>    Interoperable SMF implementations MUST use a common DPD approach and
>    be able to process the header options defined in this document for
>    IPv6 operation.  We define Classical Flooding (CF), as the simplest
>    case of SMF multicast forwarding.  With CF, each SMF router forwards
>    each received multicast packet exactly once.  In this case, the need
>    for any relay set selection or neighborhood topology information is
>    eliminated at the expense of additional network overhead.  In CF
>    mode, the SMF-DPD functionality is still required.  While SMF
>    supports a CF mode of operation the use of more efficient relay set
>    modes is RECOMMENDED to reduce contention and congestion caused by
>    unnecessary packet retransmissions [NTSC99].
> 
The above paragraph is confusing.

It starts by outlining a requirement for interoperability. It then discusses characteristics of a specific forwarding algorithm. It is not clear what the relationship between these two are.

I would actually suggest to have a top-level section "Requirements for Interoperability" somewhere in the document, assembling all the different such conditions for two implementations to have a chance at interoperating. That section would also be the place to discuss what happens if two "non-interoperable" SMF-implementations are present in the same routing domain.

I am, for the record, also somewhat stylistically against "We define....", and prefer "This document defines...." - although I recognize that to be probably a matter of taste  
>    An efficient, reduced relay set is realized by selecting and
realized -> constructed
>    maintaining a subset of all possible routers in a MANET routing
>    domain.  Known distributed relay set selection algorithms have
>    demonstrated the ability to provide and maintain a dynamic connected
>    set for forwarding multicast IP packets [MDC04].  A few such relay
>    set selection algorithms are described in the Appendices of this
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 7]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    document and the basic designs borrow directly from previously
>    documented IETF work.  SMF relay set configuration is extensible and
>    additional relay set algorithms beyond those specified here can be
>    accommodated in future work.
> 
>    Determining and maintaining an optimized set of forwarding nodes

Two things here, terminology-wise (also apply elsewhere in the I-D, but I haven't pointed them all out explicitly):

	o	"nodes" or "routers"? We have used "routers" pretty systematically in most of the 
		recent MANET RFCs, and after all we are in the RTG area

	o	"forwarding nodes" or "relay set" - seems to be the same thing (if so, use same 
		terminology).....otherwise, explain why the need for different terms.

>    generally requires dynamic neighborhood topology information.
>    Neighborhood topology discovery functions MAY be externally provided
>    by a MANET unicast routing protocol or by using the MANET
>    NeighborHood Discovery Protocol (NHDP) [RFC6130] running in
>    concurrence with SMF.  
Suggest removing "externally"

> Additionally, this specification allows
Suggest removing "Additionally,"
>    alternative lower layer interfaces (radio router interface) to
>    provide the necessary neighborhood information to aid in supporting
>    more effective relay set election.  Fundamentally, an SMF
>    implementation SHOULD provide the ability for multicast forwarding
>    state to be dynamically managed per operating network interface.
>    Some of the relay state maintenance options and interactions are
>    outlined later in Section 7. 
This phrase leaves me a little cold: "Some of the relay state maintenance options and interactions...." - but not all? Does this mean that I cannot rely solely on this specification to create an implementation of SMF?
>  This document states specific
>    requirements for neighborhood discovery with respect to the
>    forwarding process and the relay set selection algorithms described
>    herein.  For determining dynamic relay sets in the absence of other
>    control interfaces, SMF relies on the MANET NHDP specification to
>    assist in IP layer 2-hop neighborhood state discovery and maintenance
>    for relay set election.  "SMF_TYPE" and "SMF_NBR_TYPE" Message and
>    Address Block, respectfully, TLV structures (per [RFC5444]) are
>    defined for use with the NHDP protocol.  It is RECOMMENDED that all
>    nodes performing SMF operation in conjunction with NHDP, include
>    these TLV types in any NHDP HELLO messages generated.  This
>    capability allows for nodes participating in SMF to be explicitly
>    identified along with their respective dynamic relay set algorithm.
> 
> 
> 4.  SMF Applicability
> 
Suggest "SMF Applicability" -> "Applicability Statement" ?
>    Within dynamic wireless routing topologies, maintaining traditional
>    forwarding trees to support a multicast routing protocol is often not
>    as effective as in wired networks due to the reduced reliability and
>    increased dynamics of mesh topologies [MGL04] [GM99].  A basic packet
>    forwarding service reaching all connected routers running the SMF
>    protocol within a localized routing domain may provide a useful group
>    communication paradigm for various classes of applications.
>    Applications that could take advantage of a simple multicast
could -> can ?
>    forwarding service include multimedia streaming, interactive group-
>    based messaging and applications, peer-to-peer middleware
>    multicasting, and multi-hop mobile discovery or registration
>    services.  SMF is likely only appropriate for deployment in limited
>    dynamic wireless routing domains so that the flooding process can be
>    contained.  The limited SMF routing domains are further defined as
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 8]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    administratively scoped multicast forwarding domains in Section 9.2.
> 
>    Note again that Figure 1 provides a notional architecture for typical
>    SMF-capable nodes.  A goal is that simple leaf nodes may also
>    participate in multicast traffic transmission and reception with
Here, the use of "node" becomes critical. There apparently are two kinds "simple leaf nodes" and "other nodes". Are those what we call "hosts" and "routers", usually? If not, what's the difference? (And, suggest that it be described in terminology)
>    standard IP network layer semantics (e.g., special or unnecessary
>    encapsulation of IP packets should be avoided in this case).  It is
>    important that SMF deployments in localized edge network settings are
Sure, it is "important" - but is it supported by SMF? The applicability statement doesn't seem to be the appropriate place to list design requirements (that should probably be in the "Design Overview" section?
>    able to connect and interoperate with existing standard multicast
>    protocols operating within more conventional Internet
>    infrastructures.  A multicast border router or proxy mechanism MUST
2119-style MUST used in the applicability statement seems wrong to me. Would suggest stating in this section that "SMF can interoperate / interact with a fixed-infrastructre IP multicast routing", and then hive this more detailed discussion off to section 9?
>    be used when deployed alongside more fixed-infrastructure IP
>    multicast routing such Protocol Independent Multicast (PIM) variants
>    [RFC3973] and [RFC4601].  Present experimental SMF implementations
Suggest removing "Present"
>    have demonstrated gateway functionality at MANET border routers
>    operating with existing external IP multicast routing protocols
>    [CDHM07],[DHS08],and [DHG09].  SMF may be extended or combined with
>    other mechanisms to provide increased reliability and group specific
>    filtering, but the details for this are not discussed here.
> 
> 
> 5.  SMF Packet Processing and Forwarding
> 
>    The SMF Packet Processing and Forwarding actions are conducted with
>    the following packet handling activities:
> 
>    1.  Processing of outbound, locally-generated multicast packets.
>    2.  Reception and processing of inbound packets on specific network
>        interfaces.
> 
>    The purpose of intercepting outbound, locally-generated multicast
>    packets is to apply any added packet marking needed to satisfy the
>    DPD requirements so that proper forwarding may be conducted.  Note
>    that for some system configurations the interception of outbound
>    packets for this purpose is not necessary.
> 
>    Inbound multicast packets are received by the SMF implementation and
>    processed for possible forwarding.  This document does not presently
>    support forwarding of directed broadcast addresses [RFC2644]. 
To "Applicability Statement" ?
>  SMF
>    implementations MUST be capable of forwarding IP multicast packets
>    with destination addresses that are not node-local and link-local for
>    IPv6 as defined in [RFC4291] and that are not within the local
>    network control block as defined by [RFC5771]
> 

1) 	there's a period (".") missing after the final citation
2)	this is again a design requirement, not a description of protocol functioning, thus it probably should be moved to section 3? 
>    This will help support generic multi-hop multicast application needs
>    or to distribute designated multicast traffic ingressing the SMF
>    routing domain via border routers.  The multicast addresses to be
>    forwarded should be maintained by an a priori list or a dynamic
> 
Probably this would be better in a section called "Deployment considerations", as it does not specify as such the functioning of the protocol, but operational requirements?
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 9]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    forwarding information base (FIB) that MAY interact with future MANET
>    dynamic group membership extensions or management functions.  There
>    will also be a well-known multicast group for SMF.  This multicast
"will also be"? Suggest rephrasing to "The well-known SL-MANET-ROUTERS multicast group ...". Actually, suggest writing the document as-if the group has already been assigned (which it would be once published as RFC) and hive all requests-to-IANA off to "IANA Considerations"  
>    group is specified to contain all routers within an SMF routing
>    domain, so that packets transmitted to the multicast address
>    associated with the group will be delivered to all connected routers
>    running SMF.  Due the mobile nature of a MANET, routers running SMF
>    may not be topologically connected at particular times.  For IPv6,
>    the multicast address is specified to be "site-local".  

> The name of
>    the multicast group is "SL-MANET-ROUTERS". 
Suggest removing this phrase.
>  Minimally SMF MUST
>    forward, as instructed by the relay set selection algorithm, unique
>    (non-duplicate) packets received for this well-known group address
>    when the TTL or hop limit value in the IP header is greater than 1.
>    SMF MUST forward all additional global scope addresses specified
>    within the dynamic FIB or configured list as well.  In all cases, the
>    following rules MUST be observed for SMF multicast forwarding:
> 
>    1.  IP multicast packets with TTL <= 1 MUST NOT be forwarded.
>    2.  Link local IP multicast packets MUST NOT be forwarded.
>    3.  Incoming IP multicast packets with an IP source address matching
>        one of those of the local SMF router interface(s) MUST NOT be
>        forwarded.
>    4.  Received frames with the MAC source address matching any MAC
>        address of the routers interfaces MUST NOT be forwarded.
>    5.  Received packets for which SMF cannot reasonably ensure temporal
>        DPD uniqueness MUST NOT be forwarded.
Probably need an expansion or a reference to where this is expanded.
>    6.  When packets are forwarded, TTL or hop limit MUST be decremented
>        by one.
> 
>    Note that rule #3 is important because over some types of wireless
>    interfaces, the originating SMF router may receive re-transmissions
>    of its own packets when they are forwarded by adjacent routers.  This
>    rule avoids unnecessary retransmission of locally-generated packets
>    even when other forwarding decision rules would apply.
> 
>    An additional processing rule also needs to be considered based upon
>    a potential security threat.  As discussed further in Section 10,
>    there may be concern in some SMF deployments that malicious nodes may
"nodes" ....?
>    conduct a denial-of-service attack by remotely "previewing" (e.g.,
>    via a directional receive antenna) packets that an SMF node would be
>    forwarding and conduct a "pre-play" attack by transmitting the packet
>    before the SMF node would otherwise receive it but with a reduced TTL
>    (or Hop Limit) field value.  This form of attack could cause an SMF
>    node to create a DPD entry that would block the proper forwarding of
>    the valid packet (with correct TTL) through the SMF area.  A
>    RECOMMENDED approach to prevent this attack, when it is a concern,
>    would be to cache temporal packet TTL values along with the per-
>    packet DPD state (hash value(s) and/or identifier as described in
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 10]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    Section 6).  Then, if a subsequent matching (with respect to DPD)
>    packet arrives with a larger TTL value than the packet that was
>    previously forwarded, SMF should forward the new packet and update
>    the TTL value cached with corresponding DPD state to the new, larger
>    TTL value.  There may be temporal cases where SMF would unnecessarily
>    forward some duplicate packets using this approach, but those cases
>    are expected to be minimal and acceptable when compared with the
>    potential threat of denied service.
It is unclear what the "additional processing rule" then is. Is it possible to spell it out and add as rule #7 to the list above?

>    Once these criteria
Which criteria?

<SNIP>
> 
> 6.1.  IPv6 Duplicate Packet Detection
> 
>    This section describes the mechanisms and options for SMF IPv6 DPD.
>    The core IPv6 packet header does not provide any explicit
>    identification header field that can be exploited for I-DPD.  The
>    following areas are described to support IPv6 DPD and each is covered
>    in more detail in particular subsections:
>    1.  the hop-by-hop SMF-DPD option header,
>    2.  the use of IPv6 fragment header fields for I-DPD when they exist,
>    3.  the use of IPsec sequencing for I-DPD when a non-fragmented,
>        IPsec header is detected, and
>    4.  an H-DPD approach assisted, as needed, by the SMF-DPD option
>        header.
> 
Suggest actually adding <xref target= ..../> to each of these subsections here.
>    SMF MUST provide a DPD marking module that can insert the hop-by-hop
>    IPv6 header option defined in this section.  This process MUST come
>    after any source-based fragmentation that may occur with IPv6.  As
>    with IPv4, SMF IPv6 DPD is presently specified to allow either a
>    packet hash or header identification method for DPD.  An SMF
>    implementation MUST be configured to operate either in H-DPD or I-DPD
>    mode and perform the appropriate routines outlined in the following
>    sections.
> 
> 6.1.1.  IPv6 SMF-DPD Header Option
> 
>    The base IPv6 packet header does not contain a unique identifier
>    suitable for DPD.  This section defines an IPv6 Hop-by-Hop Option
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 12]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    [RFC2460] to serve this purpose for IPv6 I-DPD.  Additionally, the
>    header option provides a mechanism to guarantee non-collision of hash
>    values for different packets when H-DPD is used.
> 
>    If this is the only hop-by-hop option present, the optional
>    "TaggerId" field (see below) is not included, and the size of the DPD
>    packet identifier (sequence number) or hash token is 24 bits or less,
>    this will result in the addition of 8 bytes to the IPv6 packet header
>    including the "Next Header", "Header Extension Length", SMF-DPD
>    option fields, and padding.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                      ...              |0|0|0| OptType | Opt. Data Len |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |H|  DPD Identifier Option Fields or Hash Assist Value  ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                  Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option
> 
>    "Option Type" = (Lower 5 bits pending IANA assignment, highest order
>    MUST be 000).  By having these three bits be zero, this specification
>    requires that nodes not recognizing this option type should skip over
>    this option and continue processing the header and that the option
>    must not change en route [RFC2460].
> 
>    "Opt. Data Len" = Length of option content (I.e., 1 + (<IdType> ?
>    (<IdLen> + 1): 0) + Length(DPD ID)).
> 
>    "H-bit" = a hash indicator bit value identifying DPD marking type. 0
>    == sequence-based approach w/ optional taggerId and a tuple-based
>    sequence number. 1 == indicates a hash assist value (HAV) field
>    follows to aid in avoiding hash-based DPD collisions.
> 
>    When the "H-bit" is cleared (zero value), the SMF-DPD format to
>    support I-DPD operation is specified as shown in Figure 2 and defines
>    the extension header in accordance with [RFC2460].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 13]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                       ...              |0|0|0| OptType | Opt. Data Len |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |0|TidTyp|TidLen|             TaggerId (optional) ...           |
>        +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                               |            Identifier  ...
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>             Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode
> 
>    The "TidType" is a 3-bit field indicating the presence and type of
>    the optional "TaggerId" field.  The optional "TaggerId" is used to
>    differentiate multiple ingressing border gateways that may commonly
>    apply the SMF-DPD option header to packets from a particular source.

This probably merits at least a reference to section 9, and some discussion there detailing this operation a bit more?
>    This is provided for experimental purposes.  The following table
>    lists the valid TaggerId types:
> 
<SNIP>
> 6.1.2.  IPv6 Identification-based DPD
> 
>    The following table summarizes the IPv6 I-DPD processing and
>    forwarding decision approach.  Within the table '*' indicates an
>    ignore field condition.
> 
What is "an ignore field condition" ?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 15]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    +-------------+-----------+-----------+-----------------------------+
>    | IPv6        | IPv6      | IPv6      | SMF IPv6 I-DPD Mode Action  |
>    | Fragment    | IPsec     | I-DPD     |                             |
>    | Header      | Header    | Header    |                             |
>    +-------------+-----------+-----------+-----------------------------+
>    | Present     | *         | *         | Use Fragment Header I-DPD   |
>    |             |           |           | Check and Process for       |
>    |             |           |           | Forwarding                  |
>    | Not Present | Present   | *         | Use IPsec Header I-DPD      |
>    |             |           |           | Check and Process for       |
>    |             |           |           | Forwarding                  |
>    | Present     | *         | Present   | Invalid, do not Forward     |
>    | Not Present | Present   | Present   | Invalid, do not Forward     |
>    | Not Present | Not       | Not       | Add I-DPD Header,and        |
>    |             | Present   | Present   | Process for Forwarding      |
>    | Not Present | Not       | Present   | Use I-DPD Header Check and  |
>    |             | Present   |           | Process for Forwarding      |
>    +-------------+-----------+-----------+-----------------------------+
> 
>                    Table 2: IPv6 I-DPD Processing Rules
> 
> 
<SNIP>
> 6.1.3.  IPv6 Hash-based DPD
> 
>    A default hash-based DPD approach (H-DPD) for use by SMF is specified
>    as follows.  An MD5 [RFC1321] hash of the non-mutable header fields,
>    options fields, and data content of the IPv6 multicast packet is used
>    to produce a 128-bit digest.  The least significant 64 bits of this
1)	Someone is likely to say that MD5 is deprecated;

2)	Is the use of MD5 vs. any other hashing algorithm important? If not, suggest citing
	MD5 as an example (and reserve a field for indicating which hash algorithm is in use);
	Should be possible when inserting a header option in IPv6;

3)	Suggest discussion of the impact of hash collisions (security and performance)?
<SNIP>
> 
> 6.2.1.  IPv4 Identification-based DPD
> 
>    The following table summarizes the IPv4 I-DPD processing approach
>    once a packet has passed the basic forwardable criteria described in
>    Section 5.  Within the table '*' indicates an ignore field condition.
>    DF, MF, Fragment offset correspond to related fields and flags
>    defined in [RFC0791].
> 
"ignore field condition" is unclear - what does it mean?
<SNIP>
> 
> 6.2.2.  IPv4 Hash-based DPD
> 
>    To ensure consistent IPv4 H-DPD operation among SMF nodes, a default
>    hashing approach is specified.  This is similar to that specified for
>    IPv6, but the H-DPD header option with HAV is not considered.  SMF
>    MUST perform an MD5 [RFC1321] hash of the immutable header fields,
>    option fields and data content of the IPv4 multicast packet resulting
>    in a 128-bit digest.  The least significant 64 bits of this digest is
>    used for SMF packet identification.  The approach for calculating the
>    hash value SHOULD follow the same guidelines described for
>    calculating the Integrity Check Value (ICV) described in [RFC4302]
>    with respect to non-mutable fields.  A history of the packet hash
>    values SHOULD be maintained in the context of <protocol:srcAddr:
>    dstAddr>.  The context for IPv4 is more specific than that of IPv6
>    since the SMF-DPD HAV cannot be employed to mitigate hash collisions.
> 
>    The MD5 hash is specified at present for consistency and robustness.
>    Future approaches and experimentation may discover design tradeoffs
>    in hash robustness and efficiency worth considering for future
>    revisions of SMF.  This MAY include reducing the packet payload
>    length that is processed, determining shorter indexes, or applying a
>    more efficient hashing algorithm.
> 
Same comments as to MD5 as above;
> 
> 7.  Relay Set Selection
> 
> 7.1.  Non-Reduced Relay Set Forwarding
> 
>    SMF implementations MUST support CF as a basic forwarding mechanism
>    when reduced relay set information is not available or not selected
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 20]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    for operation.  In CF mode, each node transmits a locally generated
>    or newly received forwardable packet exactly once.  The DPD
>    techniques described in Section 6 are critical to proper operation
>    and prevent duplicate packet retransmissions by the same forwarding
>    node.
> 
> 7.2.  Reduced Relay Set Forwarding
> 
>    MANET reduced relay sets are often achieved by distributed algorithms
>    that can dynamically calculate a topological connected dominating set
>    (CDS).
> 
>    A goal of SMF is to apply reduced relay sets for more efficient
>    multicast dissemination within dynamic topologies.  To accomplish
>    this SMF MUST support the ability to modify its multicast packet
>    forwarding rules based upon relay set state received dynamically
>    during operation.  In this way, SMF forwarding operates effectively
>    as neighbor adjacencies or multicast forwarding policies within the
>    topology change.
> 
>    In early SMF experimental prototyping, the relay set information has
>    been derived from coexistent unicast routing control plane traffic
>    flooding processes [MDC04].  From this experience, extra pruning
>    considerations were sometimes required when utilizing a relay set
>    from a separate routing protocol process.  As an example, relay sets
>    formed for the unicast control plane flooding MAY include additional
>    redundancy that may not be desired for multicast forwarding use
>    (e.g., biconnected relay set).
> 
>    Here is a recommended criteria list for SMF relay set selection
>    algorithm candidates:
> 
>    1.  Robustness to topological dynamics and mobility
>    2.  Localized election or coordination of any relay sets
>    3.  Reasonable minimization of CDS relay set size given above
>        constraints
>    4.  Heuristic support for preference or election metrics
> 
>    Some relay set algorithms meeting these criteria are described in the
>    Appendices of this document.  Additional relay set selection
>    algorithms may be specified in separate specifications in the future.
>    Each Appendix subsection in this document can serve as a template for
>    specifying additional relay algorithms.
> 
>    Figure 4 depicts a information flow diagram of possible relay set
>    control options.  The SMF Relay Set State represents the information
>    base that is used by SMF in the forwarding decision process.  The
>    relay set control option diagram demonstrates that the SMF relay set
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 21]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    state may be determined by fundamentally three different methods:
>    independent operation with NHDP [RFC5444] input providing dynamic
>    network neighborhood adjacency information that is then used by a
>    particular relay set selection, slave operation with an existing
>    unicast MANET routing protocol that is capable of providing CDS
>    election information that can be used by SMF, and cross layer
>    operation that may involve lower layer neighbor or link information.
>    Other heuristics to influence and control election can come from
>    network management or other interfaces as shown on the right.  Of
>    course CF mode, simplifies the control and does not require other
>    input but relies solely on DPD.
> 
>                        Possible L2 Trigger/Information
>                                       |
>                                       |
>     ______________              ______v_____         __________________
>    |    MANET     |            |            |       |                  |
>    | Neighborhood |            | Relay Set  |       | Other Heuristics |
>    |  Discovery   |----------->| Selection  |<------| (Preference,etc) |
>    |   Protocol   | neighbor   | Algorithm  |       |  Net Management  |
>    |______________|   info     |____________|       |__________________|
>           \                              /
>            \                            /
>     neighbor\                          / Dynamic Relay
>       info*  \      ____________      /    Set Status
>               \    |    SMF     |    / (State, {neighbor info})
>                `-->| Relay Set  |<--'
>                    |   State    |
>                 -->|____________|
>                /
>               /
>     ______________
>    |  Coexistent  |
>    |    MANET     |
>    |   Unicast    |
>    |   Process    |
>    |______________|
> 
>              Figure 4: SMF Reduced Relay Set Information Flow
> 
What does the asterisk next to the left "neighbor info" mean?

<SNIP>
> 8.  SMF Neighborhood Discovery Requirements
> 
>    This section defines the requirements for use of the MANET
>    Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF
>    operation.  Note that basic CF forwarding requires no neighborhood
>    topology knowledge since in this configured mode every SMF node
>    relays all traffic.  Supporting more reduced SMF relay set operation
>    requires the discovery and maintenance of dynamic neighborhood
>    topology information.  The MANET NHDP protocol can be leveraged
leveraged -> used
>    provide this necessary information, however there are SMF-specific
>    requirements for related NHDP use.  This is the case for both
what does "related NHDP use" mean? Related to what?
>    "independent" SMF operation where NHDP is being used specifically to
>    support SMF or when one NHDP instance is used for both for SMF and a
>    coexistent MANET unicast routing protocol.
> 
>    NHDP HELLO messages and the resultant neighborhood information base
>    are described separately within the NHDP specification.  To
>    summarize, the NHDP protocol provides the following basic functions:
> 
NHDP = NeighborHood Discovery Protocol. Saying "the NHDP Protocol" is therefore redundant ("NeighborHood Discovery Protocol Protocol"). Suggest: "To summarize, NHDP provides the following ...."
>    1.  1-hop neighbor link sensing and bidirectionality checks of
>        neighbor links,
>    2.  2-hop neighborhood discovery including collection of 2-hop
>        neighbors and connectivity information,
>    3.  Collection and maintenance of the above information across
>        multiple interfaces, and
>    4.  A method for signaling SMF information throughout the 2-hop
>        neighborhood through the use of TLV extensions.
> 
>    Appendices (A-C) of this document describe CDS-based relay set
>    selection algorithms that can achieve efficient SMF operation, even
>    in dynamic, mobile networks and each of the algorithms has been
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 23]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    initially experimented within a working SMF prototype [MDDA07].  When
>    using these algorithms in conjunction with NHDP, a method verifying
>    neighbor SMF operation is required in order to insure correct relay
>    set selection.  NHDP along with SMF operation verification provides
>    the necessary information required by these algorithms to conduct
>    relay set selection.  Verification of SMF operation may be done
>    administratively or through the use of the SMF relay algorithms TLVs
>    defined in the following subsections.  Use of the SMF relay algorithm
>    TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.
> 
>    The following sub-sections 
Suggest "Sections X, Y and Z"
> specify some SMF-specific TLV types
"some" is vague? Does it mean "some, but not all" -- and, if so, where do I find the rest? Or, should "some" simply be removed?
>    supporting general SMF operation or supporting the algorithms
>    described in the Appendices.  The Appendices describing several relay
>    set algorithms also specify any additional requirements for use with
>    NHDP and reference the applicable TLV types as needed.
> 
> 8.1.  SMF Relay Algorithm TLV Types
> 
>    This section specifies TLV types to be used within NHDP messages to
>    identify the CDS relay set selection algorithm(s) in use.  Two TLV
>    types are defined, one message TLV type and one address TLV type.
> 
> 8.1.1.  SMF Message TLV Type
> 
>    The message TLV type denoted SMF_TYPE is used to identify the
>    existence of an SMF instance operating in conjunction with NHDP.
>    This message TLV type makes use of the extended type field as defined
>    by [RFC5444] to convey the CDS relay set selection algorithm
>    currently in use by the SMF message originator.  When NHDP is used to
>    support SMF operation, the SMF_TYPE TLV, containing the extended type
>    field with the appropriate value, SHOULD be included in NHDP_HELLO
>    messages (HELLO messages as defined in [RFC6130].  This allows SMF
>    nodes to learn when neighbors are configured to use NHDP for
>    information exchange including algorithm type and related algorithm
>    information.  This information can be used to take action, such as
>    ignoring neighbor information using incompatible algorithms.  It is
>    possible that SMF neighbors MAY be configured differently and still
>    operate cooperatively, but these cases will vary dependent upon the
>    algorithm types designated.
> 
>    This document defines the following Message TLV type

Which following TLV type? Do you mean "this documents defines one Message TLV type 'SMF_TYPE', specified in table 6" ?

>  as specified in
>    Table 6 conforming to [RFC5444].  The TLV extended type field is used
>    to contain the sender's "Relay Algorithm Type".  The interpretation
>    of the "value" content of these TLVs is defined per "Relay Algorithm
>    Type" and may contain algorithm specific information.
> 
> 
> 
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 24]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>           +---------------+----------------+--------------------+
>           |               | TLV syntax     | Field Values       |
>           +---------------+----------------+--------------------+
>           | type          | <tlv-type>     | SMF_TYPE           |
>           | extended type | <tlv-type-ext> | <relayAlgorithmId> |
>           | length        | <length>       | variable           |
>           | value         | <value>        | variable           |
>           +---------------+----------------+--------------------+
> 
>                        Table 6: SMF Type Message TLV
> 
>    In Table 6 <relayAlgorithmId> is an 8-bit field containing a number
>    0-255 representing the "Relay Algorithm Type" of the originator
>    address of the corresponding NHDP message.
> 
>    Possible values for the <relayAlgorithmId> are defined in Table 7.
>    The table provides value assignments, future IANA assignment spaces,
>    and an experimental space.  The experimental space use MUST NOT
>    assume uniqueness and thus should not be used for general
>    interoperable deployment prior to official IANA assignment.
> 
>    +-------------+--------------------+--------------------------------+
>    |  Type Value |    Extended Type   |            Algorithm           |
>    |             |        Value       |                                |
>    +-------------+--------------------+--------------------------------+
>    |   SMF_TYPE  |          0         |               CF               |
>    |   SMF_TYPE  |          1         |              S-MPR             |
>    |   SMF_TYPE  |          2         |              E-CDS             |
>    |   SMF_TYPE  |          3         |             MPR-CDS            |
>    |   SMF_TYPE  |        4-127       |  Future Assignment STD action  |
>    |   SMF_TYPE  |       128-239      |     No STD action required     |
>    |   SMF_TYPE  |       240-255      |       Experimental Space       |
>    +-------------+--------------------+--------------------------------+
> 
>                  Table 7: SMF Relay Algorithm Type Values
> 
I actually do not think that this belongs here. Table 7 details the initial assignment of Extended Type Values, which is an IANA action once the SMF_TYPE has been registered. Hence, I would suggest that this be moved to the IANA section.

Second, when a TLV Type is created, the Extended Type registry is also created by IANA, and needs assignment policies; there are fairly specific recommendations for how to select assignment policies for IANA governed registries, see rfc5226.

Third, I do not understand the difference between "No STD action required" and "Experimental space"? Is it such that the former is "first-come-first-served-free-for-all"? Or, does it mean "expert review, but not necessarily std. action"?

Fourth, the intended status of SMF is experimental, yes? If so, is std. action even possible (std. action means that a std.track RFC is published - which, likely, would not downref to an exp. RFC)? Recommend section 4.1 of 5226

>    Acceptable <length> and <value> fields of an SMF_TYPE TLV are
>    dependent on the extended type value (i.e. relay algorithm type).
>    The appropriate algorithm type, as conveyed in the <tlv-type-ext>
>    field, defines the meaning and format of its TLV <value> field.  For
>    the algorithms defined by this document, see the appropriate appendix
>    for the <value> field format.
> 
> 8.1.2.  SMF Address Block TLV Type
> 
>    An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor
>    relay algorithm) is specified in Table 8.  This TLV enables CDS relay
>    algorithm operation and configuration to be shared among 2-hop
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 25]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    neighborhoods.  Some relay algorithms require two hop neighbor
>    configuration in order to correctly select relay sets.  It is also
>    useful when mixed relay algorithm operation is possible, some
>    examples of mixed use is outlined in the appendices.
> 
>    The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types
>    share a common format.
> 
>           +---------------+----------------+--------------------+
>           |               | TLV syntax     | Field Values       |
>           +---------------+----------------+--------------------+
>           | type          | <tlv-type>     | SMF_NBR_TYPE       |
>           | extended type | <tlv-type-ext> | <relayAlgorithmId> |
>           | length        | <length>       | variable           |
>           | value         | <value>        | variable           |
>           +---------------+----------------+--------------------+
> 
>                     Table 8: SMF Type Address Block TLV
> 
>    <relayAlgorithmId> in Table 8 is an 8-bit unsigned integer field
>    containing a number 0-255 representing the "Relay Algorithm Type"
>    value that corresponds to any associated address in the address
>    block.  Note that "Relay Algorithm Type" values for 2-hop neighbors
>    can be conveyed in a single TLV or multiple value TLVs as described
>    in [RFC5444].  It is expected that SMF nodes using NHDP construct
>    address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm
>    Type" and to advertise neighbor algorithm values received in SMF_TYPE
>    TLVs from those neighbors.
> 
>    Again values for the <relayAlgorithmId> are defined in Table 8.

No, they're not. Table 8 simply describes the TLV structure, does not give values. Do you mean Table 7
> 
>    The interpretation of the "value" field of SMF_NBR_TYPE TLVs is
>    defined per "Relay Algorithm Type" and may contain algorithm specific
>    information.  See the appropriate appendix for definitions of value
>    fields for the algorithms defined by this document.
> 
> 
<SNIP>
> 9.4.  Multiple Border Routers
> 
>    An SMF domain might be deployed with multiple participating nodes
>    having connectivity to external, fixed-infrastructure networks.
>    Allowing multiple nodes to forward multicast traffic to/from the SMF
>    routing domain can be beneficial since it can increase reliability,
>    and provide better service.  For example, if the SMF routing domain
>    were to fragment with different SMF nodes maintaining connectivity to
>    different border routers, multicast service could still continue
>    successfully.  But, the case of multiple border routers connecting a
>    SMF routing domain to external networks presents several challenges
>    for SMF:
> 
>    1.  Handling duplicate unmarked IPv4 or IPv6 (without IPsec
>        encapsulation or DPD option) packets possibly injected by
>        multiple border routers.
> 
> 
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 29]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    2.  Source-based relay algorithms handling of duplicate traffic
>        injected by multiple border routers.
>    3.  Determination of which border router(s) will forward outbound
>        multicast traffic.
>    4.  Additional challenges with interfaces to exterior multicast
>        routing protocols.
> 
>    When multiple border routers are present they may be alternatively
>    (due to route changes) or simultaneously injecting common traffic
>    into the MANET routing region that has not been previously marked for
>    SMF-DPD.  Different border routers would not be able to implicitly
>    synchronize sequencing of injected traffic since they may not receive
>    exactly the same messages due to packet losses.  For IPv6 I-DPD
>    operation, the optional "TaggerId" field described for the SMF-DPD
>    header option can be used to mitigate this issue. 
As previously indicated, I would recommend adding some further description here as to how this "tagging" is done. Also, is this _only_ relevant when there are multiple border routers in the network?

<SNIP>
> 11.  IANA Considerations
> 
>    This document raises multiple IANA Considerations.  These include the
>    IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type-
>    Length-Value (TLV) constructs [RFC5444]) to be used with NHDP
>    [RFC6130]operation as needed to support different forms of SMF
>    operation.  There is one message TLV type and one address TLV type
>    needed to be assigned for SMF purposes as discussed in Section 8.1.
> 
>    The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be
>    assigned).
> 
>    The SL-MANET-ROUTERS multicast address will be registered for both
>    IPv4 and IPv6 multicast address spaces.
> 
> 11.1.  IPv6 SMF-DPD Header Extension
> 
>    This document requests IANA assignment of the "SMF_DPD" hop-by-hop
>    option type from the IANA "IPv6 Hop-by-Hop Options Option Type"
>    registry (see Section 5.5 of [RFC2780]).
> 
>    The format of this new option type is described in Section 6.1.1.  A
>    portion of the option data content is the taggger identifier type
>    "TidType" that provides a context for the "TaggerId" that is
>    optionally included to identify the node that added the SMF_DPD
>    option to the packet.  This document defines a namespace for IPv6
>    SMF_DPD Tagger Identifier Type values:
>                         ietf:manet:smf:taggerIdTypes
> 
>    The values that can be assigned within the "ietf:manet:smf:
>    taggerIdTypes" name-space are numeric indexes in the range [0, 7],
>    boundaries included.  All assignment requests are granted on an "IETF
>    Consensus" basis as defined in [RFC5226].
> 
>    This specification registers Tagger Identification Type values from
>    Table 9 in the registry "ietf:manet:smf:taggerIdTypes":
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 32]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>                    +----------+-------+---------------+
>                    | Mnemonic | Value | Reference     |
>                    +----------+-------+---------------+
>                    |   NULL   |   0   | This document |
>                    |  DEFAULT |   1   | This document |
>                    |   IPv4   |   2   | This document |
>                    |   IPv6   |   3   | This document |
>                    |   ExtId  |   7   | This document |
>                    +----------+-------+---------------+
> 
>                           Table 9: TaggerId Types
> 
> 11.2.  SMF Type-Length-Value
> 
>    This document requests IANA assignment of one message "SMF_TYPE" TLV
>    type and one address block "SMF_NBR_TYPE" TLV type from the [RFC6130]
>    specific registry space.
Specify which spaces those are from among those in 6130?
> 
>    The common format of these new TLV types is described in Table 6 and
>    Table 8.  Furthermore this document defines a namespace for algorithm
>    ID types using the extended type TLV value field defined by
>    [RFC5444].  Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace.
> 
>                ietf:manet:packetbb:nhdp:smf:relayAlgorithmID
> 
>    The values that can be assigned within the "ietf:manet:packetbb:nhdp:
>    smf:relayAlgorithmID" name-space are numeric indexes in the range [0,
>    239], boundaries included.  Assignment requests for the [0-127] are
>    granted on an "IETF Consensus" basis as defined in [RFC5226].
>    Standards action is not required for assignment requests of the range
>    [128-239].  Documents requesting relayAlgorithmId values SHOULD
>    define value field uses contained by the SMF_TYPE:<relayAlgorithmId>
>    and SMF_NBR_TYPE:<relayAlgorithmId> full type TLVs.
> 
>    This specification registers the following Relay Algorithm ID Type
>    values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp:
>    smf:relayAlgorithmID
> 
>                      +----------+-------+------------+
>                      | Mnemonic | Value | Reference  |
>                      +----------+-------+------------+
>                      | CF       | 0     |            |
>                      | S-MPR    | 1     | Appendix B |
>                      | E-CDS    | 2     | Appendix A |
>                      | MPR-CDS  | 3     | Appendix C |
>                      +----------+-------+------------+
> 
>                  Table 10: Relay Set Algorithm Type Values
> 
> 
Suggest moving the type-extension description to here, with proper assignment policies.
<SNIP>
> 
> Appendix A.  Essential Connecting Dominating Set (E-CDS) Algorithm
> 
>    The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS]
>    forms a single CDS mesh for the SMF operating region.  It allows
> 
> 
> 
> Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 36]
> 
> Internet-Draft                     SMF                        March 2011
> 
> 
>    nodes to use 2-hop neighborhood topology information to dynamically
>    perform relay self election to form a CDS.  Its packet forwarding
>    rules are not dependent upon previous hop knowledge.  Additionally,
>    E-CDS SMF forwarders can be easily mixed without problems with CF SMF
>    forwarders, even those not participating in NHDP.  Another benefit is
>    that packets opportunistically received from non-symmetric neighbors
>    may be forwarded without compromising flooding efficiency or
>    correctness.  Furthermore, multicast sources not participating in
>    NHDP may freely inject their traffic and any neighboring E-CDS relays
>    will properly forward the traffic.  The E-CDS based relay set
>    selection algorithm is based upon the summary within [E-CDS].  E-CDS
>    was originally discussed in the context of forming partial
>    adjacencies and efficient flooding for MANET OSPF extensions work and
>    the core algorithm is applied here for SMF.
> 
>    It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV be included in
>    NHDP_HELLO messages that are generated by nodes conducting E-CDS SMF
>    operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS
>    address block TLV be used to advertise neighbor nodes that are also
>    conducting E-CDS SMF operation.
> 
General comment to all appendices: I believe that it is inappropriate to use 2119-style language in appendices, as I believe that appendices default to informative, not normative?
> A.1.  E-CDS Relay Set Selection Overview
> 
>    The E-CDS relay set selection requires 2-hop neighborhood information
>    collected through NHDP or another process.  Relay nodes, in E-CDS SMF
>    selection, are "self-elected" using a router identifier (Router ID)

"Relay nodes ..... using a router identifier (Router ID) and an optional nodal metric"

So: node-router-router-node ?
>    and an optional nodal metric, referred to here as "Router Priority"
>    for all 1-hop and 2-hop neighbors.  To ensure proper relay set self-
>    election, the Router ID and Router Priority MUST be consistent among
>    participating nodes.  It is RECOMMENDED that NHDP be used to share
>    Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs
>    as described in this appendix..  The Router ID is a logical
Appendix followed by two periods.
<SNIP>
> 
>    It is RECOMMENDED that the SMF_TYPE:S-MPR message TLV be included in
>    NHDP_HELLO messages that are generated by nodes conducting S-MPR SMF
>    operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR
>    address block TLV be used to specify which neighbor nodes are
>    conducting S-MPR SMF operation.
> 
Just latching on to this here, but....

Isn't it a normative requirement (i.e., to be stipulated outside of appendices) that this TLV is included for SMF operation of NHDP?

In general, SHOULD (and, so, also RECOMMENDED) often should be a MUST - if not, then the consequences of disregarding the recommendation should be specified.

Thomas