Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

["Jonathan Hui (johui)" <[e-mail]>]

Ulrich,

Thanks for your detailed review.  Responses below.

On Oct 26, 2012, at 8:33 PM, Ulrich Herberg <[e-mail]> wrote:

[snip]

> 1.  Introduction
> 
>   Low power and Lossy Networks typically operate with strict resource
>   constraints in communication, computation, memory, and energy.  Such
>   resource constraints may preclude the use of existing IPv6 multicast
>   topology and forwarding mechanisms.  Traditional IP multicast
>   forwarding typically relies on topology maintenance mechanisms to
>   forward multicast messages to all subscribers of a multicast group.
>   However, maintaining such topologies in LLNs is costly and may not be
>   feasible given the available resources.
> 
>   Memory constraints may limit devices to maintaining links/routes to
>   one or a few neighbors.  For this reason, the Routing Protocol for
>   LLNs (RPL)
> 
> UH> The correct title is "RPL: IPv6 Routing Protocol for Low-Power and
> Lossy Networks"

Ack.

>    specifies both storing and non-storing modes [RFC6550].
>   The latter allows RPL routers to maintain only one or a few default
>   routes towards a LLN Border Router (LBR)
> 
> UH> I did not find LBR in the terminology section.

Ack.

>   and use source routing to
>   forward packets away from the LBR.  For the same reasons, a LLN
>   device may not be able to maintain a multicast forwarding topology
>   when operating with limited memory.
> 
>   Furthermore, the dynamic properties of wireless networks can make the
>   cost of maintaining a multicast forwarding topology prohibitively
>   expensive.  In wireless environments, topology maintenance may
>   involve selecting a connected dominating set used to forward
>   multicast messages to all nodes in an administrative domain.
>   However, existing mechanisms often require two-hop topology
>   information and the cost of maintaining such information grows
>   polynomially with network density.
> 
>   This document specifies the Multicast Protocol for Low power and
>   Lossy Networks (MPL), which provides IPv6 multicast forwarding in
>   constrained networks.  MPL avoids the need to construct or maintain
>   any multicast forwarding topology, disseminating multicast messages
>   to all MPL forwarders in an MPL domain.  By using the Trickle
>   algorithm [RFC6206], MPL requires only small, constant state for each
>   MPL device that initiates disseminations.  The Trickle algorithm also
>   allows MPL to be density-aware, allowing the communication rate to
>   scale logarithmically with density.
> 
> UH> I am not sure I understand the last sentence. What does it mean?
> How is that achieved?

This is borrowing the wording out of RFC 6206.  I can reference the RFC here (again) and reference the academic papers (NSDI'04, CACM'08) that present this result.

> UH> By the way, since this is a standards track document, is there any
> deployment experience? Implementations?

As Don mentioned, there are a number of implementations on different platforms.  Peter van der Stok has also presented his implementation to the WG.  Cisco also has an implementation.

The use of Trickle to disseminate messages has been implemented, deployed, and published numerous times in the past.  These implementations include small message, medium message, and large message dissemination.  Including NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10.

> 2.  Terminology
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> UH> "NOT RECOMMENDED" is missing as per the errata of RFC2119

Ack.

>   The following terms are used throughout this document:
> 
>   MPL forwarder       An IPv6 router that subscribes to the MPL
>                       multicast group and participates in disseminating
>                       MPL multicast packets.
> 
>   MPL multicast scope The multicast scope that MPL uses when forwarding
>                       MPL multicast packets.  In other words, the
>                       multicast scope of the IPv6 Destination Address
>                       of an MPL multicast packet.
> 
> UH> An RFC reference to "scope" could be helpful.

I assume you mean RFC 4007.

>   MPL domain          A connected set of MPL forwarders that define the
>                       extent of the MPL dissemination process.
> 
> UH> What does connected mean? What if a the network is split in two parts?

"MPL forwarding domain    A MPL forwarding domain is a collection of forwarders that operate MPL and are under the control of a single administration."

>                       As a
>                       form of flood, all MPL forwarders in an MPL
>                       domain will receive MPL multicast packets.
> 
> UH> Probably not *all* forwards will receive it (assuming packets can
> be lost)

How about:

"As a form of flood, MPL strives to deliver MPL multicast packets to all MPL forwarders."

> 
> 
>                       The
>                       MPL domain MUST be composed of at least one MPL
>                       multicast scope and MAY be composed of multiple
>                       MPL multicast scopes.
> 
> UH> Why is that? Anyway, I am unsure whether one can say that a
> routing domain "consists" of multicast scopes. If I understand that
> correctly, the multicast scope just determines how far a message
> propagates.

I think it would help to define "MPL multicast scope zone" in addition to "MPL multicast scope".  Then the correct wording for the text above is "MAY be composed of multiple MPL multicast scope zones."  Does that help?

>   MPL seed            A MPL forwarder that begins the dissemination
>                       process for an MPL multicast packet.  The MPL
>                       seed may be different than the source of the
>                       original multicast packet.
> 
>   MPL seed identifier An identifier that uniquely identifies an MPL
>                       forwarder within its MPL domain.
> 
> UH> How is the uniqueness guaranteed? What kind of identifier is that?
> An IP address? I see it's defined later, but maybe it would be helpful
> to mention it here, too.

Ack.

> 
> 
>   original multicast packet  An IPv6 multicast packet that is
>                       disseminated using MPL.
> 
> UH> That terminology sounds a bit confusing; I would have imagined
> that the above description matches the following term "MPL multicast
> packet". What's the difference between an "original multicast packet"
> and an "MPL multicast packet"? I assume the one is the inner packet
> when using IPv6-in-IPv6 tunnels, the other one is the outer packet
> with the options header.

The one subtlety here is that the original multicast packet does not necessarily have to be encapsulated using IPv6-in-IPv6.  How about:

"An IPv6 multicast packet that is transported by MPL.  In other words, it is an MPL multicast packet with the MPL Hop-by-Hop Option removed.  When the MPL multicast packet uses IPv6-in-IPv6 encapsulation to include the MPL Hop-by-Hop Option, the original multicast packet is the inner packet."

>   MPL multicast packet  An IPv6 multicast packet that contains an MPL
>                       Hop-by-Hop Option.  When either source or
>                       destinations are beyond the MPL multicast scope,
> 
> UH> Above it was said there may be multiple scopes in a domain. Here
> you talk about "the" scope. Which one?

Having "MPL multicast scope zones", as addressed above, should help here too.

>                       the MPL multicast packet is an IPv6-in-IPv6
>                       packet that contains an MPL Hop-by-Hop Option in
>                       the outer IPv6 header and encapsulates an
>                       original multicast packet.  When both source and
>                       destinations are within the MPL multicast scope,
>                       the MPL Hop-by-Hop Option may be included
>                       directly within the original multicast packet.
> 
> 
> 
> 
> 
> Hui & Kelsey             Expires April 22, 2013                 [Page 4]
> Internet-Draft                     MPL                      October 2012
> 
> 
> 3.  Overview
> 
>   MPL delivers IPv6 multicast packets by disseminating them to all MPL
>   forwarders within an MPL domain.  MPL dissemination is a form of
>   flood.  An MPL forwarder may broadcast/multicast an MPL multicast
>   packet out of the same physical interface on which it was received.
>   Using link-layer broadcast/multicast allows MPL to forward multicast
>   packets without explicitly identifying next-hop destinations.  An MPL
>   forwarder may also broadcast/multicast MPL multicast packets out
>   other interfaces to disseminate the message across different links.
>   MPL does not build or maintain a multicast forwarding topology to
>   forward multicast packets.
> 
>   Any MPL forwarder may initiate the dissemination process by serving
>   as an MPL seed for an original multicast packet.  The MPL seed may or
>   may not be the same device as the source of the original multicast
>   packet.  When the original multicast packet's source is outside the
>   LLN,
> 
> UH> LLN or MPL domain? How can a router determine if an incoming
> packet is inside our outside the MPL domain?

MPL forwarding domain.  Generally, the packet is outside when received on an interface not used for MPL forwarding or when the original multicast packet does not contain an MPL Option.

>   the MPL seed may be the ingress router.  Even if an original
>   multicast packet source is within the LLN, the source may first
>   forward the multicast packet to the MPL seed using IPv6-in-IPv6
>   tunneling.
> 
> UH> The IPv6-in-IPv6 tunnelling is somewhat hidden in a section with a
> title not related to "IPv6 tunneling". I suggest to make an own
> section.

Ack.

>   Because MPL state requirements grows with the number of
>   active MPL seeds,
> 
> UH> In section 1 it was written that the state is constant. Here you
> say it grows. Which one is it?

Section 1 states: "MPL requires only small, constant state for each MPL device that initiates disseminations."  That is consistent with the wording above.  I can make the text the same in both locations.

>    limiting the number of MPL seeds reduces the amount
>   of state that MPL forwarders must maintain.
> 
>   Because MPL typically broadcasts/multicasts MPL packets out of the
>   same interface on which they were received,
> 
> UH> Why typically? Doesn't that depend on the scenario that this
> specification is used in?
> 
>   MPL forwarders are likely
>   to receive an MPL multicast packet more than once.
> 
> UH> I am not sure if that is the only reason. Isn't the reason that it
> may be received from multiple neighbors?

How about:

"As a form of flood, MPL forwarders are likely to receive an MPL multicast packet more than once."

>   The MPL seed tags
>   each original multicast packet with an MPL seed identifier and a
>   sequence number.  The sequence number provides a total ordering of
>   MPL multicast packets disseminated by the MPL seed.
> 
>   MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include
>   MPL-specific information along with the original multicast packet.
>   Each IPv6 multicast packet that MPL disseminates includes the MPL
>   Option.  Because the original multicast packet's source and the MPL
>   seed may not be the same device, the MPL Option may be added to the
>   original multicast packet en-route.  To allow Path MTU discovery to
>   work properly, MPL encapsulates the original multicast packet in
>   another IPv6 header that includes the MPL Option.
> 
>   Upon receiving a new MPL multicast packet for forwarding, the MPL
>   forwarder may proactively transmit the MPL multicast packet packet a
>   limited number of times and then falls back into an optional reactive
>   mode.  In maintenance mode, an MPL forwarder buffers recently
>   received MPL multicast packets and advertises a summary of recently
>   received MPL multicast packets from time to time, allowing
>   neighboring MPL forwarders to determine if they have any new
>   multicast packets to offer or receive.
> 
> 
> 
> Hui & Kelsey             Expires April 22, 2013                 [Page 5]
> Internet-Draft                     MPL                      October 2012
> 
> 
>   MPL forwarders schedule their packet (control and data) transmissions
>   using the Trickle algorithm [RFC6206].  Trickle's adaptive
>   transmission interval allows MPL to quickly disseminate messages when
>   there are new MPL multicast packets, but reduces transmission
>   overhead as the dissemination process completes.  Trickle's
>   suppression mechanism and transmission time selection allow MPL's
>   communication rate to scale logarithmically with density.
> 
> UH> I think the whole introduction is not very easy to read. There is
> a lot of text about some details (IPv6-in-IPv6 tunnels, multiple
> interfaces), but the essential mechanism is hard to identify from the
> text. Also, there is nothing mentioned about what kind of state is
> required to be stored on each router (which information sets etc).

A lot of this is combined with text in Section 5.  Would you prefer to see that pulled up here?

> Hui & Kelsey             Expires April 22, 2013                 [Page 6]
> Internet-Draft                     MPL                      October 2012
> 
> 
> 4.  Message Formats
> 
> 4.1.  MPL Option
> 
>   The MPL Option is carried in an IPv6 Hop-by-Hop Options header,
> 
> UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options header"

I was following the text of RFC 2675.

> UH> More importantly,  RFC6564 specifies:
> 
>      New options for the existing Hop-by-Hop Header SHOULD NOT be
>      created or specified unless no alternative solution is feasible.
>      Any proposal to create a new option for the existing Hop-by-Hop
>      Header MUST include a detailed explanation of why the hop-by-hop
>      behavior is absolutely essential in the document proposing the new
>      option with hop-by-hop behavior.
> 
> UH> I did not see such an explanation.

How about:

"The MPL option is needed because the IPv6 header does not provide unique identification of IPv6 packets from the source."

>   immediately following the IPv6 header.  The MPL Option has the
>   following format:
> 
>      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
>                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                     |  Option Type  |  Opt Data Len |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | S |M|   rsv   |   sequence    |      seed-id (optional)       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> UH> It could help to mention that this is formatted in network byte order
> 
>   Option Type         XX (to be confirmed by IANA).
> 
>   Opt Data Len        Length of the Option Data field in octets.  MUST
>                       be set to either 2 or 4.
> 
> UH> 2 or 4 depending on what?

Depending on the size of seed-id.

>   S                   2-bit unsigned integer.  Identifies the length of
>                       seed-id. 0 indicates that the seed-id is 0 and
>                       not included in the MPL Option. 1 indicates that
>                       the seed-id is a 16-bit unsigned integer. 2
>                       indicates that the seed-id is a 64-bit unsigned
>                       integer. 3 indicates that the seed-id is a 128-
>                       bit unsigned integer.
> 
>   M                   1-bit flag. 0 indicates that the value in
>                       sequence is not the greatest sequence number that
>                       was received from the MPL seed.
> 
>   rsv                 5-bit reserved field.  MUST be set to zero and
>                       incoming MPL multicast packets in which they are
>                       not zero MUST be dropped.
> 
>   sequence            8-bit unsigned integer.  Identifies relative
>                       ordering of MPL multicast packets from the source
>                       identified by seed-id.
> 
>   seed-id             Uniquely identifies the MPL seed that initiated
>                       dissemination of the MPL multicast packet.  The
>                       size of seed-id is indicated by the S field.
> 

[snip]

> 4.2.1.  MPL Window
> 
>   An MPL Window encodes the sliding window state (described in
>   Section 5.2 that the MPL forwarder maintains for an MPL seed.
> 
> UH> missing ")"

Ack.

[snip]

> 5.  MPL Forwarder Behavior
> 
>   An MPL forwarder implementation needs to manage sliding windows for
>   each active MPL seed.  The sliding window allows the MPL forwarder to
>   determine what multicast packets to accept and what multicast packets
>   are buffered.  An MPL forwarder must also manage MPL packet
>   transmissions.
> 
> 5.1.  Multicast Packet Dissemination
> 
>   MPL uses the Trickle algorithm to control packet transmissions when
>   disseminating MPL multicast packets [RFC6206].  MPL provides two
>   propagation mechanisms for disseminating MPL multicast packets.
> 
>   1.  With proactive propagation, an MPL forwarder transmits buffered
>       MPL multicast packets using the Trickle algorithm.  This method
>       is called proactive propagation since an MPL forwarder actively
>       transmits MPL multicast packets without discovering that a
>       neighboring MPL forwarder has yet to receive the message.
> 
>   2.  With reactive propagation, an MPL forwarder transmits ICMPv6 MPL
>       messages using the Trickle algorithm.  An MPL forwarder only
>       transmits buffered MPL multicast packets upon discovering that
>       neighboring devices have not yet to receive the corresponding MPL
>       multicast packets.
> 
>   When receiving a new multicast packet, an MPL forwarder first
>   utilizes proactive propagation to forward the MPL multicast packet.
>   Proactive propagation reduces dissemination latency since it does not
>   require discovering that neighboring devices have not yet received
>   the MPL multicast packet.  MPL forwarders utilize proactive
>   propagation for newly received MPL multicast packets since they can
>   assume that some neighboring MPL forwarders have yet to receive the
>   MPL multicast packet.  After a limited number of MPL multicast packet
>   transmissions, the MPL forwarder may terminate proactive propagation
>   for the MPL multicast packet.
> 
>   An MPL forwarder may optionally use reactive propagation to continue
>   the dissemination process with lower communication overhead.  With
>   reactive propagation, neighboring MPL forwarders use ICMPv6 MPL
>   messages to discover new MPL multicast messages that have not yet
>   been received.  When discovering that a neighboring MPL forwarder has
>   not yet received a new MPL multicast packet, the MPL forwarder
>   enables proactive propagation again.
> 
> UH> There is not a lot of RFC2119 language in the above. Or is that
> defined later? Is this above section more like an introduction?

This is more like an intro.  Would you prefer to see this moved to the overview section?

> Hui & Kelsey             Expires April 22, 2013                [Page 11]
> Internet-Draft                     MPL                      October 2012
> 
> 
> 5.1.1.  Trickle Parameters and Variables
> 
>   As specified in RFC 6206 [RFC6206], a Trickle timer runs for a
>   defined interval and has three configuration parameters: the minimum
>   interval size Imin, the maximum interval size Imax, and a redundancy
>   constant k.
> 
>   MPL defines a fourth configuration parameter, TimerExpirations, which
>   indicates the number of Trickle timer expiration events that occur
>   before terminating the Trickle algorithm.
> 
>   Each MPL forwarder maintains a separate Trickle parameter set for the
>   proactive and reactive propagation methods.  TimerExpirations MUST be
>   greater than 0 for proactive propagation.  TimerExpirations MAY be
>   set to 0 for reactive propagation, which effectively disables
>   reactive propagation.
> 
>   As specified in RFC 6206 [RFC6206], a Trickle timer has three
>   variables: the current interval size I, a time within the current
>   interval t, and a counter c.
> 
> UH> This sentence starts confusing, as it looks very similar to the
> first paragraph in this section. "a Trickle timer has three variables"
> How about using the same language as in RFC6206:
> "In addition to these three parameters, Trickle maintains three
>   variables:
>   o  I, the current interval size,
>   o  t, a time within the current interval, and
>   o  c, a counter."

Ack.

>   MPL defines a fourth variable, e, which counts the number of Trickle
>   timer expiration events since the Trickle timer was last reset.
> 
> 5.1.2.  Proactive Propagation
> 
>   With proactive propagation, the MPL forwarder transmits buffered MPL
>   multicast packets using the Trickle algorithm.  Each buffered MPL
>   multicast packet that is proactively being disseminated with
>   proactive propagation has an associated Trickle timer.
> 
> UH> I think that somewhere the state requirements need to be
> mentioned. How does that affect scalability of the algorithm etc.
> Density is mentioned somewhere in the beginning, but not explained how
> that would affect scalability and state requirements.

Ack.

>    Adhering to
>   Section 5 of RFC 6206 [RFC6206], this document defines the following:
> 
>   o  This document defines a "consistent" transmission for proactive
>      propagation as receiving an MPL multicast packet that has the same
>      MPL seed identifier and sequence number as a buffered MPL packet.
> 
>   o  This document defines an "inconsistent" transmission for proactive
>      propagation as receiving an MPL multicast packet that has the same
>      MPL seed identifier, the M flag set, and has a sequence number
>      less than the buffered MPL multicast packet's sequence number.
> 
>   o  This document does not define any external "events".
> 
>   o  This document defines both MPL multicast packets and ICMPv6 MPL
>      multicast packets as Trickle messages.  These messages are defined
>      in the sections below.
> 
> UH> I don't see the term Trickle message used anywhere else.

Used in RFC 6206.

> Hui & Kelsey             Expires April 22, 2013                [Page 12]
> Internet-Draft                     MPL                      October 2012
> 
> 
>   o  The actions outside the Trickle algorithm that the protocol takes
>      involve managing sliding window state, and is specified in
>      Section 5.2.
> 
> 5.1.3.  Reactive Propagation
> 
>   With reactive propagation, the MPL forwarder transmits ICMPv6 MPL
>   messages using the Trickle algorithm.  A MPL forwarder maintains a
>   single Trickle timer for reactive propagation with each MPL domain.
>   When REACTIVE_TIMER_EXPIRATIONS is 0, the MPL forwarder does not
>   execute the Trickle algorithm for reactive propagation and reactive
>   propagation is disabled.  Adhering to Section 5 of RFC 6206
>   [RFC6206], this document defines the following:
> 
>   o  This document defines a "consistent" transmission for reactive
>      propagation as receiving an ICMPv6 MPL message that indicates
>      neither the receiving nor transmitting node has new MPL multicast
>      packets to offer.
> 
>   o  This document defines an "inconsistent" transmission for reactive
>      propagation as receiving an ICMPv6 MPL message that indicates
>      either the receiving or transmitting node has at least one new MPL
>      multicast packet to offer.
> 
>   o  This document defines an "event" for reactive propagation as
>      updating any sliding window (i.e. changing the value of WindowMin,
>      WindowMax, or the set of buffered MPL multicast packets) in
>      response to receiving an MPL multicast packet.
> 
>   o  This document defines both MPL multicast packets and ICMPv6 MPL
>      multicast packets as Trickle messages.  These messages are defined
>      in the sections below.
> 
> UH> I don't see the term "Trickle message" anywhere else  (other than
> in 5.1.2)

Used in RFC 6206.

[snip]

> 5.3.  Transmission of MPL Multicast Packets
> 
>   The MPL forwarder manages buffered MPL multicast packet transmissions
>   using the Trickle algorithm.  When adding a packet to
>   BufferedPackets, the MPL forwarder MUST create a Trickle timer for
>   the packet and start execution of the Trickle algorithm.
> 
>   After PROACTIVE_TIMER_EXPIRATIONS Trickle timer events, the MPL
>   forwarder MUST stop executing the Trickle algorithm.  When a buffered
>   MPL multicast packet does not have an active Trickle timer, the MPL
>   forwarder MAY free the buffered packet by advancing WindowMin to 1
>   greater than the packet's sequence number.
> 
>   Each interface that supports MPL is configured with exactly one MPL
>   multicast scope.  The MPL multicast scope MUST be site-local or
>   smaller and defaults to link-local.  A scope larger than link-local
>   MAY be used only when that scope corresponds exactly to the MPL
>   domain.
> 
> UH> Why is this written in a section called "Transmission of MPL
> Multicast Packets"? Seems more like an initial configuration. Same for
> the below IPv6.. I would have expected that in a dedicated section
> about IPv6 tunneling

Ack.

> UH> How would the router now that the scope corresponds exactly to the
> MPL domain?

The intent is to have this configured, not dynamically determined.  Will make this clearer in the next revision.

> Hui & Kelsey             Expires April 22, 2013                [Page 15]
> Internet-Draft                     MPL                      October 2012
> 
> 
>   An MPL domain may therefore be composed of one or more MPL multicast
>   scopes.  For example, the MPL domain may be composed of a single MPL
>   multicast scope when using a site-local scope.  Alternatively, the
>   MPL domain may be composed of multiple MPL multicast scopes when
>   using a link-local scope.
> 
> UH> I am not quite sure how the scope works in this specification. Is
> that used somewhere when deciding whether to forward packets?

Should be "multiple MPL multicast scope zones".

>   IPv6-in-IPv6 encapsulation MUST be used when using MPL to forward an
>   original multicast packet whose source or destination address is
>   outside the MPL multicast scope.
> 
> UH> The source address is a unicast address, right? How can that be
> outside a multicast scope? How would you know?

Source address should not be included in the text above.  Instead, there should be text requiring a border router to encapsulate using IPv6-in-IPv6 when forwarding into an MPL forwarding domain.

>    IPv6-in-IPv6 encapsulation is
>   necessary to support Path MTU discovery when the MPL forwarder is not
>   the source of the original multicast packet.  IPv6-in-IPv6
>   encapsulation also allows an MPL forwarder to remove the MPL Option
>   when forwarding the original multicast packet over a link that does
>   not support MPL.
> 
> UH> That should be specified more clearly. What does "remove" mean? I
> suppose you mean decapsulate the inner IPv6 packet.

How about:

"Decapsulating the original multicast packet also serves to remove the MPL Option contained in the outer header."

>    The destination address scope for the outer IPv6
>   header MUST be the MPL multicast scope.
> 
> UH> Again, which one? I thought there can be several scopes?

Again, only a single scope, but multiple scope zones.

> 
>   When an MPL domain is composed of multiple MPL multicast scopes (e.g.
>   when the MPL multicast scope is link-local), an MPL forwarder MUST
>   decapsulate and encapsulate the original multicast packet when
>   crossing between different MPL multicast scopes.
> 
> UH> When would you know when to cross a multicast scope? Do you mean
> routing domain?

Crossing between different MPL multicast scope zones.  An MPL forwarder should know by virtue of attempting to forward the packet beyond the current zone.  When the MPL multicast scope is link-local, then the MPL forwarder must decapsulate and encapsulate when forwarding each packet.

>    In doing so, the
>   MPL forwarder MUST duplicate the MPL Option, unmodified, in the new
>   outer IPv6 header.
> 
>   The IPv6 destination address of the MPL multicast packet is the all-
>   MPL-forwarders multicast address (TBD).
> 
> UH> The TBD will be hard to spot by the RFC editor / IANA. I suggest
> to define the variable and use the value only in the IANA section.

Ack.

>    The scope of the IPv6
>   destination address is set to the MPL multicast scope.
> 
> UH> which one?

Only one MPL multicast scope - multiple MPL multicast scope zones.

> 
> 5.4.  Reception of MPL Multicast Packets
> 
>   Upon receiving an MPL multicast packet, the MPL forwarder first
>   determines whether or not to accept and buffer the MPL multicast
>   packet based on its MPL seed and sequence value, as specified in
>   Section 5.2.
> 
>   If the MPL forwarder accepts the MPL multicast packet, the MPL
>   forwarder determines whether or not to deliver the original multicast
>   packet to the next higher layer.
> 
> UH> How would it determine that?

That text doesn't seem quite right.  How about:

"If the MPL forwarder accepts the MPL multicast packet, the MPL forwarder processes the original multicast packet."

>    For example, if the MPL multicast
>   packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the
>   outer IPv6 header, which also removes MPL Option.
> 
> UH> For example? What exactly needs to be done?

This sentence is no longer required with the proposed text above.

> 
> 5.5.  Transmission of ICMPv6 MPL Messages
> 
>   The MPL forwarder generates and transmits a new ICMPv6 MPL message
>   whenever Trickle requests a transmission.
> 
> UH> So for each data packet there would be a new ICMPv6 message?
> Wouldn't that create a lot of overhead?

Nope.  The ICMPv6 message is a list of sliding windows.

> UH> To which address is the ICMP message sent? On which interface?

Destination Address is specified in Section 4.2.  Sent on all interfaces that are used for forwarding MPL multicast packets.

>   The MPL forwarder includes
>   an encoding of each sliding window in the ICMPv6 MPL message.

[snip]

>   When an MPL forwarder determines that it has at least one buffered
>   MPL multicast packet that has not yet been received by a neighbor,
>   the MPL forwarder resets the Trickle timer associated with reactive
>   propagation.  Additionally, for each buffered MPL multicast packet
>   that should be transferred, the MPL forwarder MUST reset the Trickle
>   timer and reset e to 0 for proactive propagation.  If the Trickle
>   timer for proactive propagation has already stopped execution,
> 
> UH> Which timer? I thought there is one timer per packet in the
> proactive mode?

How about:

"the Trickle timer(s) associated with the buffered packet(s) and reset e associated with the buffered packet(s) to 0 for proactive propagation".

>   the
>   MPL forwarder MUST initialize a new Trickle timer and start execution
>   of the Trickle algorithm.

[snip]

> 6.  MPL Parameters
> 
>   An MPL forwarder maintains two sets of Trickle parameters for the
>   proactive and reactive methods.  The Trickle parameters are listed
>   below:
> 
>   PROACTIVE_IMIN  The minimum Trickle timer interval, as defined in
>      [RFC6206] for proactive propagation.
> 
>   PROACTIVE_IMAX  The maximum Trickle timer interval, as defined in
>      [RFC6206] for proactive propagation.
> 
>   PROACTIVE_K  The redundancy constant, as defined in [RFC6206] for
>      proactive propagation.
> 
>   PROACTIVE_TIMER_EXPIRATIONS  The number of Trickle timer expirations
>      that occur before terminating the Trickle algorithm.  MUST be set
>      to a value greater than 0.
> 
>   REACTIVE_IMIN  The minimum Trickle timer interval, as defined in
>      [RFC6206] for reactive propagation.
> 
>   REACTIVE_IMAX  The maximum Trickle timer interval, as defined in
>      [RFC6206] for reactive propagation.
> 
>   REACTIVE_K  The redundancy constant, as defined in [RFC6206] for
>      reactive propagation.
> 
>   REACTIVE_TIMER_EXPIRATIONS  The number of Trickle timer expirations
>      that occur before terminating the Trickle algorithm.  MAY be set
>      to 0, which disables reactive propagation.
> 
>   WINDOW_HOLD_TIME  The minimum lifetime for sliding window state.
> 
> 
> UH> I don't see any recommendations for these values. That is
> typically requested in the IESG evaluation for standards track
> documents (either default values and/or guideslines on the values).

Ack.

[snip]

> 8.  IANA Considerations
> 
>   The Trickle Multicast option requires an IPv6 Option Number.
> 
> 
> 
>   HEX         act  chg  rest
>   ---         ---  ---  -----
>     C          01    0  TBD
> 
> 
> 
>   The first two bits indicate that the IPv6 node MUST discard the
>   packet if it doesn't recognize the option type, and the third bit
>   indicates that the Option Data MUST NOT change en-route.
> 
> 
> UH> That does not look like a valid IANA section. RFC 5226 give some
> good guidelines.

Ack.

--
Jonathan Hui