Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

[Robert Cragie <[e-mail]>]

Hi Kerry,

Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address 
with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental 
identifier that groups nodes in a PAN and therefore forms a clear zone 
for multicast dissemination. Anything else is going to be an unclear 
superset or subset.

The language can get a bit circular so I think the statement for an 
802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Address of 
ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone 
within which the set of 802.15.4 MPL Interfaces subscribing to that MPL 
Domain Address all have the same PAN ID."

Compare with a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Address with a scope value 
of 4 (Admin-Local) is a scope zone within which the set of MPL 
Interfaces subscribing to that MPL Domain Address is administratively 
configured."

Robert

On 15/10/2013 18:17, Kerry Lynn wrote:
> On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Michael,
>
>     We should leave in scope 4 for use in administratively scoped domains.
>     This would allow applications to define specific multicast
>     addresses using
>     scope 4 without having to go through the trouble to "un-reserve"
>     adminstrative scope.
>
>     Also, I am in favor of Ralph's proposal on using PAN ID for MPL
>     scope 3.
>     I don't see how any automatic configuration could take place if we
>     can't
>     identify a concrete identifier for the scope.  The other
>     alternative (and
>     to be honest the one I thought we were going to use) is DODAG ID.
>       This
>     would allow your scenario where a subnet of different link
>     technologies
>     could support MPL domain 3.
>
> If a host can be present simultaneously in more than one DODAG then
> we run afoul of normative RFC 4007 behavior:
>
>   Zones of the same scope cannot overlap; i.e., they can have no links
>   or interfaces in common.
>
> Link-local scope is essentially defined by a combination of link layer
> connectivity and routing behavior.
<RCC>Link-local scope is defined by link layer connectivity only, 
surely? Where does routing behavior come into it?<.RCC>

> I believe we need something similar
> in order to automatically define scope 0x03.  To the extent that we need
> scope 0x03 at all, I think it's to emulate classic link-local behavior 
> in a
> mesh.
<RCC>I agree with this, however it is not always clear what constitutes 
"the mesh". There has to be one thing in common with all the interfaces 
which participate in the mesh; PAN ID is an obvious choice and clearly 
sets the zone of scope 3 in this case. DODAG ID is another possibility 
but MPL propagation through MPL forwarders is not rooted at a single 
node so it is more like RPL-P2P in some respects.</RCC>
> There are only so many ways that meshes can be distinguished:
> either by location, frequency, or code diversity (assuming any two of
> three overlap).  In Ralph's example, he assumes location and frequency
> overlap.  In Michael's example, I suspect he assumes location and PAN
> ID overlap.
>
> Finally, we may need to constrain Ralph's definition a bit further and
> define an 802.15.4  scope 0x03 zone as a set of interfaces that share
> a common PAN coordinator and PAN ID.
<RCC>I think that statement is tautological as the PAN coordinator 
dictates the PAN ID therefore must share the PAN ID. Therefore this 
reduces to sharing a PAN ID.</RCC>
>
> -K-
>
>
>     Don
>
>
>     On 10/15/13 8:59 AM, "Michael Richardson" <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     >
>     >
>     >Don Sturek <[e-mail] <mailto:[e-mail]>> wrote:
>     >    > At some point, I think it would be interesting to see multicast
>     >    > forwarding rules in a mesh network where flooding is not
>     used.  I
>     >would
>     >    > see that case as the example of where scope 4 would be used.
>     >
>     >okay, so when we write a new protocol, we can specify this.
>     >Why have the code there to support scope-4 when there is no other
>     >behaviour?
>     >
>     >    > I know that a lot of work is needed in defining the rules for
>     >    > forwarding when flooding is not used but in a large mesh
>     network,
>     >there
>     >    > would be a lot of benefit to such a feature.
>     >
>     >Do you agree with me about PANID vs Subnet or not?
>     >
>     >--
>     >Michael Richardson <[e-mail]
>     <mailto:[e-mail]>>, Sandelman Software Works
>     >
>     >
>     >_______________________________________________
>     >Roll mailing list
>     >[e-mail] <mailto:[e-mail]>
>     >https://www.ietf.org/mailman/listinfo/roll
>
>
>     _______________________________________________
>     Roll mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll