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

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 4 Dec 2012 14:32:37 +0000

Just to check our current understanding of scope:

> How does a node determine what the scope of the MPL domain?
>From the I-D -02, it is "multicast scope of the IPv6 Destination Address of an MPL multicast packet". So it can be derived from the mcast address(es) that MPL uses which are defined in application code or in a config file or so.

> Is this an intrinsic (provisioned) property of a node?
- if encapsulation is used, I expect the outer IP address is configured in the node (e.g. FF05::MPL)
- if encapsulation is not used, the IP address where to send to or to receive on would be set by the application code i.e. it's also configured on the node (e.g. FF05::1234)

>From the IP address(es) the MPL scope follows.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday 20 November 2012 18:43
To: [email-masked]
Cc: [email-masked]; Dijk, Esko
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

okay, so we have the example of 6 offices with a single 6LBR.
They form a single PAN (PAN-ID is irrelevant).  There is a need to multicast within each of the offices.

How does a node determine what the scope of the MPL domain?
Is this an intrinsic (provisioned) property of a node?
Do we support non-convex MPL domains?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 19 Dec 2012 11:27:57 +0000

> I asked a question, how does a node know if it should forward/rebroadcast a packet in an identified MPL domain.

Ah, ok. Maybe both question and answer become easier once we have an update of the I-D text? My simple view is:
For 'node' being an MPL forwarder, there's no decision to make: it will anyway forward packets (with the MPL Option) on the same interface at which it was received, following the MPL protocol. Only a single MPL domain is assigned to any one network interface (assumption).

If an MPL forwarder wants to send/forward to other interfaces and/or into other MPL domains it knows, that's possible - but needs to be explicitly configured/implemented on the forwarder. MPL states a forwarder MAY do this.

> ...how, when the MPL domain is less than the LLN, the packets are pruned to just the MPL domain.
The pruning happens automatically if there is only one MPL domain configured within an LLN.
Specifically, the non-MPL-forwarders that are inside the LLN but outside the MPL domain won't forward the packets by definition.

For other cases (i.e. 2 or more MPL domains within the subnet) I have the same question as you - it seems impossible to do the 'pruning' correctly based on the current MPL -02 text, for unencapsulated multicast packets at least.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Friday 14 December 2012 3:36
To: [email-masked]
Cc: Dijk, Esko; [email-masked]
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

Dijk, I do not feel that you understood the question.

>>>>> "Dijk," == Dijk, Esko <[email-masked]> writes:

    >> How does a node determine what the scope of the MPL domain?

    Dijk> From the I-D -02, it is "multicast scope of the IPv6
    Dijk> Destination Address of an MPL multicast packet". So it can be
    Dijk> derived from the mcast address(es) that MPL uses which are
    Dijk> defined in application code or in a config file or so.

You answered the question:
    "how does a node determine the MPL domain of a multicast packet"

I asked a question, how does a node know if it should forward/rebroadcast a packet in an identified MPL domain.

    >> Is this an intrinsic (provisioned) property of a node?

    Dijk> - if encapsulation is used, I expect the outer IP address is
    Dijk> configured in the node (e.g. FF05::MPL)

    Dijk> - if encapsulation is not used, the IP address where to send
    Dijk> to or to receive on would be set by the application code
    Dijk> i.e. it's also configured on the node (e.g. FF05::1234)

I do not feel that I have a good understanding of how, when the MPL domain is less than the LLN, how the packets are pruned to just the MPL domain.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Dec 2012 14:54:44 -0500

(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?