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

[Robert Cragie <[e-mail]>]

Hi Kerry,

More comments inline, bracketed by <RCC2></RCC2>. In summary - I 
generally agree with what you say. There needs to be a decision on where 
to write the IP-over-foo scope 3 definition, especially for 
IP-over-802.15.4.

Robert

On 16/10/2013 02:23, Kerry Lynn wrote:
> Hi Robert,
>
> Comments inline...
>
>
> On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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."
>
> <kel>
> I feel that MPL should be defined strictly in terms of how it handles 
> different scopes and that the
> definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or 
> an update to same.
<RCC2>
In principle, I agree. Practically, what is the best way to achieve this?

 1. A 6lo-led RFC for all IP-over-foo
 2. Updates to all the existing IP-over-foo RFCs
 3. Lots of short RFCs for each IP-over-foo
 4. Start with 802.15.4 example in MPL


I think all are reasonable and there are bound to be other approaches 
which are reasonable as well. I think as already discussed it comes down 
to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly 
as possible.
</RCC2>

> There's always the outside possibility that another (non 15.4) mesh 
> data link may emerge in
> the future.
<RCC2>In this case, it should be clear that a statement regarding scope 
3 is included in the corresponding IP-over-foo RFC</RCC2>
> Also, as I suggested in an earlier email, the PAN ID based definition 
> should make
> it clear we're talking about a set of interfaces that share physical 
> connectivity as well as PAN ID.
<RCC2>See below</RCC2>
>
> It should be possible to create an MPL Domain from traditional links 
> (e.g. ethernet) that only uses
> scope 0x02 messages.
<RCC2>It is now, however the MPL Domain will only reach one hop. We did 
discuss at length some time ago in the ZigBee IP community the merits of 
using scope 2 vs. scope 3 for propagating multicasts. The outcome was 
that both are feasible solutions but using scope 2 conceptually means 
multiple overlapping one-hop MPL domains in some arbitrary zone. To 
propagate multicasts in this arbitrary zone would mean administratively 
configuring MPL forwarder behaviour to ensure propagation. In practice, 
the difference is minimal but architecturally it is quite different</RCC2>
> </kel>
>
>     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."
>
> <kel>
> With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone 
> to fully encompass any
> scope 0x03 zones that fall within its boundaries.  It seems the best 
> use of Admin-Local scope by
> MPL may be to aggregate mesh and traditional links into larger MPL 
> Domains.
> </kel>
<RCC2>I agree</RCC>
>
>     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>
>
> <kel>
> To be more accurate, the boundary of a link-local zone is defined by 
> the lack of
> forwarding.  RFC 4291 states:
>
>   Routers must not forward any packets with Link-Local source or
>   destination addresses to other links.
>
> Thus, Link-Local scope zones may exist on adjacent links but they will 
> be disjoint.
> </kel>
<RCC2>Exactly - see earlier description of link-local MPL Domain based 
on scope 2</RCC2>
>
>
>>     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>
>
> <kel>
> My concern here is the case of overlapping DODAGs. We cannot have 
> overlapping
> zones of the same scope.
>
> In practice, I think the definition of scope 0x03 using PAN ID for 
> 802.15.4 networks
> is transparent at layer 3.  It's a requirement that the node must 
> filter by PAN ID at
> layer 2 and again this definition should be part of the IP-over-foo 
> specification.
> </kel>
<RCC2>It's a tricky one this. I can sort of see the sense in wanting to 
limit propagation of a multicast to those nodes which have something in 
common with regard to routing. So in this sense, a DODAG ID would make 
sense. In that case, we have to rethink the idea of a MPL Domain being a 
scope zone and I'm not sure we want to go down that road again? So I do 
agree that if we are using scope zones, it has to be transparent at 
layer 3.</RCC2?
>
>>     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>
>
> <kel>
> OK, I was trying to prevent the interpretation that two PANs on 
> opposite sides
> of the earth with the same PAN ID will be in the same scope zone.  
> There's no
> doubt a better way to state it.
>
> BTW, I hope there's a method for two PAN coordinators on opposite sides of
> a wall to ensure that they pick different PAN IDs?
> </kel>
<RCC2>OK, I see where you are coming from and I have no problem with the 
extra text for clarity purposes. However, the definition of PAN and thus 
PAN ID should preclude this. It is not allowed for overlapping PANs to 
have the same PAN ID and 802.15.4 has mechanisms to prevent and fix 
this. Given the definition of a zone is a connected region of topology, 
this means that two PANs on opposite sides of the earth with the same 
PAN ID cannot be in the same scope zone as they are not connected.  </RCC2>
>
>>
>>     -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]  <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
>
>