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

["roll issue tracker" <[e-mail]>]

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


Comment (by [e-mail]):

 Previous comments on this topic

 Thread from [07/11/13-07/26/13]: http://www.ietf.org/mail-
 archive/web/roll/current/msg08020.html

 Thread from [09/13/13-09/24/13]: http://www.ietf.org/mail-
 archive/web/roll/current/msg08158.html

 On 10/15/13 Thread: http://www.ietf.org/mail-
 archive/web/roll/current/msg08225.html

 <mrichd>


 Why do we need/want scope value 4 at all?
 I don't agree with using the PAN ID as the automatically configured
 criteria.  I think that subnet is the right thing.  RPL and MPL
 is specifically designed to cross layer-2.</mrichd>



 <ralphd>


 There apparently was interest in an administratively defined MP domain.
 scop 4 is available for that kind of domain.  If there is no interest,
 scop 4 need not be added.
 What is your definition for "subnet" that is compatible with the
 definition from draft-ietf-6man-multicast-scopes:

   automatically
   configured, i.e., automatically derived from physical
   connectivity or other, non-multicast-related configuration.

 I chose PAN ID as a way of identifying a "subnet" within a distribution of
 MPL forwarders that might be within radio range of each other but should
 be in separate MPL domains.  For example, suppose I have MPL forwarders in
 my flat and you have MPL forwarders in your flat.  How do my forwarders
 know they belong to the MPL domain in my flat while your forwarders know
 they belong to the MPL domain in your flat.  PAN ID would be one way to
 make that differentation.</ralphd>





 <mrichd>


 PANID is too restrictive in my opinion.

 I may well have a radio networks on the first floor of my (penthouse)
 flat,
 and another radio network on the second floor of my flat, connected by any
 number of wired (ethernet) or higher-powered wireless (wifi) layer-2
 technologies.  There are good radio reasons to use different PANIDs,
 because the isolation might be inconsistent.  The devices which connect my
 two floors know they are supposed to do that at the RPL level, and so
 subnet is the right thing.

 This is where we need to be prescriptive.</mrichd>



 <rcragi>


 Yes, but your scenario is surely one where it cannot be automatically
 configured and therefore scope 4 is surely more applicable?</rcragi>



 <mrichd>


 If the RPL can discover/build the network, then the MPL should
 automatically
 use it.  Yes, I agree that I have to plug the cables in, and I probably
 have to apply power.</mrichd>



 <donstk>


 I don't see how scope 3 (automatically configured) fits with your example.
 There would need to be some administrative configuration to let these
 devices know that the two PANs you have should be linked in one
 domain.</donstk>



 <ralphd>


 If I'm understanding your example correctly, I would say that the MPL
 domain you describe would use scop 4, administratively defined to cover
 the various radio domains.

 I might also consider using scop 3 to simply forward across the mesh
 networks, with a broader scope and traditional multicast protocols to tie
 together the MPL domains with other links in the home network.

 Suppose an application uses multicast address FF08::DB8:0:1234 in a
 network with RTR1 connected to MESH1 and some other links, and RTR2
 connected to MESH2 and some other links.  RTR1 and RTR2 share at least on
 link.

 One architecture would be to use traditional multicast protocols to
 connect the various links to which RTR1 and RTR2 are connected.  RTR1 and
 RTR2 then act as MPL encapsulators for MESH1 and MESH2.  Traffic on MESH1
 looks like (hope the summarization is understandable)

    FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application
 payload </ralphd>



 <donstk>


 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.
 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. </donstk>



 <mrichd>


 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?
 Do you agree with me about PANID vs Subnet or not? </mrichd>



 <donstk>


 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. </donstk>



 <ralphd>


 Don - at present, MPL is, as far as I know, independent of RPL.  In
 particular, MPL can be used in a mesh that does not use RPL.  Therefore,
 there might not be a DODAG ID to use as a MPL domain identifier. </ralphd>



 <mrichd>


 While I agree with you (ralph), that MPL is separate from RPL in the same
 way that
 HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to,
 if one want to use MPL in another environment one will have to specify
 the boundaries somehow.
 Using PANID limits one to 802.15.4-ish networks: what is the PANID of
 ethernet?  ROLL is specifically chartered to work across a multitude of
 different layer-2 protocols. </mrichd>



 <kerlyn>


 If MPL were defined in terms of scope 0x02 messages (as the Trickle
 Algorithm is) we'd be done by now.  An MPL domain would then be the
 set of links connected by  MPL forwarders, with the boundary set by
 administratively opting out interfaces (a MPL domain boundary would
 thus be defined as cutting through a node, not a link).[[BR]]

 Scope 0x03 is not defined on 802.3.  It is only needed at all on mesh
 networks, therefore it is defined (or not) on a link layer basis.
 </kerlyn>



 <mrichd>

 I like DODAG ID. That suits me fine.</mrichd>



 <kerlyn>


 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.  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.  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. </kerlyn>



 <ralphd>


 Following up on Kerry's observation that a node can belong to more than
 one DODAG, how does such a node determine which DODAG to use for scop 3
 forwarding, or which DODAG to use for filtering inbound scop 3 traffic?
 </ralphd>



 <rkelsy>


 I think you have to fall back on routing behavior.  Consider a
 mixed-PHY mesh, such as a a combination of 802.15.4 and PLC
 links.  If the routing layer considers it all one mesh, then it
 is, regardless of whether or not there are any 802.15.4 nodes in
 direct communication using the same PAN ID.  On the other hand,
 the routing layer could take the same physical setup and treat it
 as distinct 802.15.4 meshes with PLC interconnects, in which case
 you would get multiple 0x03 scopes.

   I shall not today attempt further to define 0x03 scope; and
   perhaps I could never succeed in intelligibly doing so. But I
   know it when I see it.
                          (paraphrasing Justice Potter Stewart) </rkelsy>




 <ralphd>


 OK, but I don't think there is a good way to associate a specific MPL
 datagram with a DODAG ID, so a node can determine which scope 3 that MPL
 datagram is associated with.

 And, using DODAG ID tightly couples MPL with RPL, when MPL as currently
 defined can be used without RPL.

 I think scope 4 is a much better candidate for the "composite" subnet use
 case, while scope 3 is good for a single physical mesh. </ralphd>



 <rcragi>


 “...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."...”

 “...Link-local scope is defined by link layer connectivity only, surely?
 Where does routing behavior come into it?...”

 “...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….”

 “...the PAN coordinator dictates the PAN ID therefore must share the PAN
 ID. Therefore this reduces to sharing a PAN ID…” </rcragi>



 <kerlyn>



 “...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. There's always the
 outside possibility that another (non 15.4) mesh data link may emerge in
 the future.  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.

 It should be possible to create an MPL Domain from traditional links (e.g.
 ethernet) that only uses scope 0x02 messages….”

 “...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….”

 “...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....”

 “...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....”

 “....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?...” </kerlyn>



 On 10/16/13



 <rcragi>


 “... There needs to be a decision on where to write the IP-over-foo scope
 3 definition, especially for IP-over-802.15.4…”
 “...In principle, I agree. Practically, what is the best way to achieve
 this?

 A 6lo-led RFC for all IP-over-foo
 Updates to all the existing IP-over-foo RFCs
 Lots of short RFCs for each IP-over-foo
 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….”

 “...it should be clear that a statement regarding scope 3 is included in
 the corresponding IP-over-foo RFC...”

 “...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…”

 “...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….”

 “...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...” </rcragi>



 <kerlyn>


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



 On 10/17/13



 <ralphd>


 Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict
 regarding the way in which multicast scope 3 is defined:

 RFC 4007, section 5:

    o  The boundaries of zones of a scope other than interface-local,
       link-local, and global must be defined and configured by network
       administrators.

 RFC 4291, section 2.7:

          Admin-Local scope is the smallest scope that must be
          administratively configured, i.e., not automatically derived
          from physical connectivity or other, non-multicast-related
          configuration.

 Noting this conflict, I propose adding a bit of text to draft-ietf-6man-
 multicast-scopes to update RFC 4007 for consistency with RFC 4291:

 Add section 3 (and renumber current section 3-5):

 3.  Updates to RFC 4007, section 5

    Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the
    way in which multicast scope 3 is configured.  To resolve that
 disagreement,
    change the last bullet in the list in section 5 of RFC 4007 as follows:

 OLD:

    o  The boundaries of zones of a scope other than interface-local,
       link-local, and global must be defined and configured by network
       administrators.

 NEW:

    o  Admin-Local scope is the smallest scope that must be
       administratively configured, i.e., not automatically derived
       from physical connectivity or other, non-multicast-related
       configuration.

 Looking for consensus in the 6man WG before I make this change...
 </ralphd>

-- 
---------------------------------------+------------------------------
 Reporter:  [e-mail]  |       Owner:  [e-mail]
     Type:  defect                     |      Status:  reopened
 Priority:  major                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

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