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

[Kerry Lynn <[e-mail]>]

Hi Robert,

My responses bracketed by <kel2/>...


On Wed, Oct 16, 2013 at 4:37 AM, Robert Cragie
<[e-mail]>wrote:

>  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.
>
> <kel2> See below </kel2>


> 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]> 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
>
> <kel2>
I think Ralph's approach is the correct one.  His
draft-droms-6man-multicast-scopes belongs in
6man as it re-defines a reserved code point in the IPv6 addressing
architecture.  It nominally
updates RFC 4291 but should probably also update RFC 4007 as these RFCs are
in conflict
regarding the automatic definition of scope 0x03.

Ralph's draft says that scope 0x03 is defined on a network technology basis
and should be
published in an RFC.  Since 6LoWPAN is trying to close down, I think a
(short)  update to RFC
4944 could be done in 6lo.

Other 6lo drafts should define scope 0x03 (or not) for their particular
technology.  I think
scope 0x03 is unnecessary for any technology that doesn't have a hidden
node issue and
probably not necessary for all wireless data links.

MPL should be clear of technology discussion and just define forwarding
behavior on a
scope-by-scope basis.  For example, *if* it is possible to create a MPL
"Super-Domain"
from scope 2 domains, I expect the behavior would be to retransmit (or not,
as determined
by the Trickle Algorithm) on all active MPL interfaces but use a new source
address at
each hop.  You then have a set of connected one-hop tunnels and the seed
and sequence
data is preserved in the inner header.

For scope > 2 I expect the MPL Data packet would be re-transmitted
(forwarded) using
the original (received) source address.  Is it sufficient to just reference
Ralph's draft when
scope 0x03 is discussed in MPL and thus decouple the two discussions?
</kel2>

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>
>
> <kel2> Ralph's draft makes this clear. </kel2>

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

<kel2>
I think it would have been better to use the term "MPL zone", especially
since an MPL Domain is
currently defined to be an RFC 4007 scope zone.  Since scope zones cannot
overlap, the same
must be true for MPL Domains.  However, I see you point when considering
MPL Forwarders
that only have a single 802.15.4 interface.  It seems they must function
like a router-on-a-stick
that forwards between VLANs on an ethernet link.
</kel2>

>
>    </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>
>
> <snip>

>
>>   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?
>
> <kel2>
In the case of scope 0x02, a zone is defined by physical connectivity and
the nodes need
not have anything in common w.r.t. routing.  I assume it is possible to
have multiple DODAGs
in the same PAN (please correct me if that is not the case) and that the BR
can route between
them.  When extending our scope 0x02 intuition to scope 0x03 it seems the
only dependence
on routing behavior is in enabling a response to reach a requester.  Put
another way, I don't
think that source address should be considered in the MPL Forwarder's
decision to re-transmit
a packet.
</kel2>

>        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>
>
> <kel2>
I think you are saying that "same PAN ID" is sufficient to automatically
define a
scope 0x03 zone and I agree with your reasoning.

Regards, -K-
</kel2>

<snip>