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

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Jan 2013 08:15:20 +0000

Hi Michael,

There isn't really a need for both #3 (subnet-local mc address) and #4 
(link-local mc address) as they are both mechanisms for encapsulating a 
mc message originating from or destined for outside the MPL Domain. I 
think the original aim was to keep the specification flexible for 
implementation choice. The latest draft will only specify #3.

Robert

On 21/12/2012 7:54 PM, Michael Richardson wrote:
> (It has come to my attention that additional spam filtering @ietf.org
> was dropping many of my emails, this is a resend)
>
>>>>>> "Robert" == Robert Cragie <[email-masked]> writes:
>      Robert> <RCC> Almost there. In the case of forwarding using MPL
>      Robert> domain (subnet-local) mc address, the inner packet is
>      Robert> strictly tunnelled, i.e. there will be no hop count
>      Robert> decrementing per hop. I discussed this offline with Jonathan
>
> okay, and this is because the packet is in a tunnel, which is not
> addressed to the "link", so in effect, it is not a local packet.
>
> I can buy this, and so #3 does not decrement, while #4 does.
>
> What is the use case for #3 and what is the use case for #4?
> What I'm trying to get at here is: what is the argument to have both?
>
> Who is going to need each one?
>
> 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?
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 24 Jan 2013 10:34:02 -0000

#105: trickle-mcast: how to determine scope of MPL domain

Comment (by [email-masked]):

 Based on latest message in the thread
 http://www.ietf.org/mail-archive/web/roll/current/msg07624.html
 the proposal is that (3) above will be specified in the draft, and the
 alternative (4) not.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-roll-trickle-
  [email-masked]       |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  trickle-     |     Version:
  mcast                  |  Resolution:
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/105#comment:3>
roll <http://tools.ietf.org/wg/roll/>