Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

[Robert Cragie <[e-mail]>]

On 14/11/2012 9:13 PM, Michael Richardson wrote:
> Robert, has written 3 rules about when to encapsulate, and how to
> recognize the MPL domain.  With two options #3 and #4.
>
> the difference is  (#3):
>
>>     2. Outer header will have subnet-local mc address (e.g.
>>        FF03-based). This can be used to control propagation in
>>        conjunction with the MPL option.
> vs (#4)
>
> <    2. Outer header will have link-local mc address (e.g. FF02-based).
> <       This cannot be used to control propagation as it only goes one
> <       hop; the MPL option is used alone
>
> and as far as I can understand in both cases MPL forwarders will
> decapsulate and re-encapsulate, thus decrementing the inner TTL each
> time.   Or did I misunderstand here?
<RCC>
Almost there. In the case of forwarding using MPL domain (subnet-local) 
mc address, the inner packet is strictly tunnelled, i.e. there will be 
no hop count decrementing per hop. I discussed this offline with 
Jonathan Hui and he thought that was acceptable. In the case of 
link-local mc address, the inner packet would have its hop count 
decremented.

Why the difference? Consider the two cases more closely:

  * In the MPL domain multicast case, the encapsulated packet traverses
    throughout the scope dictated by the MPL domain multicast address.
    On receipt, the inner packet is decapsulated for processing. Once it
    has been processed it is effectively discarded. The outer packet,
    complete with MPL option is then passed to the MPL forwarder, which,
    if it decides to forward, manipulates the MPL option only and sends
    the outer packet as it came in
  * In the link-local case, the encapsulated packet only goes one hop.
    On receipt, the inner packer is decapsulated for processing. The
    outer header is discarded and the MPL option retained. As the inner
    packet is no longer encapsulated, it can be manipulated. The MPL
    forwarder is then passed the MPL option and the inner packet, which,
    if it decides to forward, manipulates the MPL option and
    recapsulates the inner packet

See attached diagrams for pictorial explanation.
</RCC>
>
> I think that we are very closing to closing issue #105, and I think that
> issue #106 would be resolved as "no" by this choice.
>