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]):

 '''Related to draft-ietf-6man-multicast-scopes-02'''

 <ralph> http://www.ietf.org/mail-archive/web/roll/current/msg08342.html


 This revision adds the definition of "scop 3" for IEEE 802.15.4 networks:

 4.  Definition of Realm-Local Scope for IEEE 802.15.4

    When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
    include all interfaces sharing a PAN ID.

 I've cross-posted to 6lo to get review and comment from that WG.</ralph>


 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08343.html


 http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not
 seem to contains the section you're inlining. The only diff I found was
 -specific going -local.
 As we are at it, would we be ahead of ourselves if that the draft also
 specifies that a collection of RPL DODAGs of a same instance federated
 over an isolated backbone (such as a VLAN) in an 04 ?.

 If I may add, there is kind of an habit that scopes are nested. Seems that
 we are going away from that assumption and maybe it would be good to have
 a sentence saying that? </pascal>


 <ralph>http://www.ietf.org/mail-archive/web/roll/current/msg08344.html


 The document has been accepted as a WG work item.  Check out
 http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-
 scopes-02.txt </ralph>


 <samita> http://www.ietf.org/mail-archive/web/6lo/current/msg00298.html


 Indeed, Section 4 talks about the realm-local scope for IEEE 802.15.4

 "4.  Definition of Realm-Local Scope for IEEE 802.15.4

    When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
    include all interfaces sharing a PAN ID."

 In several places, I think there is a typo: s/scop /scope

 How about adding one or two examples in the appendix section  to clarify
 the nested scope in the home-network  containing two types of networks
 (wifi and LLN) ? Perhaps, we expecting that LLN could have further
 division in scope -- ie, IEEE 802.15.4 or BT-le or MS/TP networks.

 The example of mdns, rpl, and nd  possibly will fall in different scopes.
 </samita>


 <brian> http://www.ietf.org/mail-archive/web/roll/current/msg08345.html


 Scopes are still nested.  See RFC 4007.  Are you saying that this document
 is changing that? </brian>


 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08346.html


 03 seems to derive from autonomic behavior, whereas 04 derives from admin.
 I do not see there a direct indication that 03 is contained in 04 though
 in the deployments I have in mind it would certainly be the case. Whether
 we want to enforce or on the contrary do not want to enforce the nesting
 is probably something we want to clarify. </pascal>


 <brian> http://www.ietf.org/mail-archive/web/roll/current/msg08348.html


 Pascal,
     Scope 3 being contained within scope4 is mandated by RFC 4007.
 Specifically, RFC 4007 describes the following properties:

 o  Zone boundaries cut through nodes, not links.  (Note that the global
 zone has no boundary, and the boundary of an interface-local zone
 encloses just a single interface.)

 o  Zones of the same scope cannot overlap; i.e., they can have no links
 or interfaces in common.

 o  A zone of a given scope (less than global) falls completely within
 zones of larger scope.  That is, a smaller scope zone cannot include
 more topology than would any larger scope zone with which it shares any
 links or interfaces.

 o  Each zone is required to be "convex" from a routing perspective;
 i.e., packets sent from one interface to any other in the same zone are
 never routed outside the zone.  Note, however, that if a zone contains a
 tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer
 network of the tunnel can be located outside the zone without breaking
 the convexity property.


 I don't see anything in this draft that would change those properties.
 </brian>


 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08350.html


 I mostly agree Brian;

 It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.
 A RPL domain (that is an 03) that may span multiple PAN IDs. If PAN ID was
 04 that would have been reverse nesting.
 The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.

 Would a RPL domain be constrained by the PAN ID?

 In this case that would imply that all the LLN must always be a single PAN
 and constrain the size of a subnet to 64K.
 There is a lot behind the sentence "care must be taken in the definition
 of those larger scopes to ensure that inclusion constraint is met."
 </pascal>


 <tim> http://www.ietf.org/mail-archive/web/roll/current/msg08347.html


 > 03 seems to derive from autonomic behavior, whereas 04 derives from
 admin. I do not see >there a direct indication that 03 is contained in 04
 though in the deployments I have in mind >it would certainly be the case.
 Whether we want to enforce or on the contrary do not want to >enforce the
 nesting is probably something we want to clarify.
 Are there use cases documented somewhere in a 6lo or 6lo-related draft?
 I'm interested as we're updating the homenet text about multicast scopes.
 We have agreed some text in principle with Brian for that, but it's
 interesting because we may, indeed are likely to, have 6lo networks within
 future IPv6 home networks. </tim>


 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08349.html


 Hello Tim;
 The 6TiSCH architecture documents a use case whereby a large (RPL based)
 LLN is federated by an higher speed backbone such as Ethernet that mostly
 spans the LLN.
 The LLN is partitioned by RPL in multiple DODAGs, and the roots of the
 DODAGs connect to the backbone to provide end to end connectivity over the
 formed multilink subnet.
 The LLN probably forms a single RPL Domain though we have not discussed
 that yet. Discussing with Ralph, I understand that the RPL domain is 03
 and the whole multilink subnet is 04.
 It results that we cannot address a single RPL instance or a single DODAG
 as a scope. The intersection with 802.15.4 PAN-ID still troubles me a bit
 but that's another thread. </pascal>


 <michael> http://www.ietf.org/mail-archive/web/roll/current/msg08356.html


 >Pascal Thubert (pthubert) <pthubert at cisco.com> wrote:
     > The LLN probably forms a single RPL Domain though we have not
 discussed
     > that yet. Discussing with Ralph, I understand that the RPL domain is
 03
     > and the whole multilink subnet is 04.

 No, that's not quite right.

 Scope-3 is each of the LLNs that have a single technology instance (e.g.
 802.15.4 + PANID)

 Scope-4 is the whole multilink subnet as defined by the span of the
 collection of DODAGs (my suggestion)

 The RPL DODAG instances would likely span the backbone, and would be the
 basis for scope-4 configuration.</michael>


 <ralph> http://www.ietf.org/mail-archive/web/roll/current/msg08351.html


 >On Nov 14, 2013, at 6:58 PM 11/14/13, "Pascal Thubert (pthubert)"
 <pthubert at cisco.com> wrote:

 > I mostly agree Brian;
 >
 > It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.

 I consider a PAN ID to be equivalent to an address ... both are configured
 administratively but are part of the
 >
 > A RPL domain (that is an 03) that may span multiple PAN IDs.

 Pascal - RPL domains are, in my opinion, completely unrelated to MPL
 scopes.  RPL is only mentioned obliquely, as an example of a protocol that
 accommodates the memory constraints in highly constrained devices.  So, I
 don't think there is any reason to say "A RPL domain (that is an 03)".

 > If PAN ID was 04 that would have been reverse nesting.
 > The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.
 >
 > Would a RPL domain be constrained by the PAN ID?

 No ... RPL domain is independent of MPL scope.

 As a practical matter, a "RPL domain" is a little tricky to define, and
 even trickier to tie into a multicast scope.  There is nothing in the
 multicast address or the MPL header to tie it to a DODAG or some other RPL
 domain identifier.  In a mesh where multiple DODAGS and RPL domains may be
 interleaved, there doesn't seem to be a way to identify a MPL scope.

 >
 > In this case that would imply that all the LLN must always be a single
 PAN and constrain the size of a subnet to 64K.

 I think you're confusing the use of "scop 3" for carrying multicast
 traffic via MPL across a single mesh network and the use of, e.g., "scop
 4" for the scope of, say, mDNS for DNS-SD across a federation of subnets.

 I won't attempt the ASCII art here ... but here's an example scenario as I
 understand it: SEP2.0 DNS-SD/mDNS queries intended to span a federation of
 subnets is sent to (working from memory) FC04::FB.  When delivered to an
 LBR at the border of a 6LoWPAN mesh, that query would be encapsulated in
 FC03::<ALL_MPL_FORWARDERS> to carry it across the mesh. Similarly, a query
 from a mesh node would have an inner header with dst FC04::FB and
 encapsulated by the source with outer header dst
 FC03::<ALL_MPL_FORWARDERS>; then the MPL outer header would be taken off
 by the LBR and inner DNS-SD/mDNS query would be forwarded out any other
 interfaces based on the dst FC04::FB.

 > There is a lot behind the sentence "care must be taken in the definition
 of those larger scopes to ensure that inclusion constraint is met."

 OK, but I don't think draft-ietf-6man-multicast-scopes contradicts RFC
 4007 in any way. </ralph>


 <kerry> http://www.ietf.org/mail-archive/web/roll/current/msg08352.html


 > I mostly agree Brian
 > It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.
 One could take that argument to the extreme and say that selecting SSID
 (802.11) or plugging into a wall socket (802.3) is an administrative act.
 Let's not be too literal and instead say that the "automatic" zone
 boundary definition applies to an existing LAN.  If you think about a
 Link-Local zone, it is defined as a set of physically connected interfaces
 and the zone boundary is defined by a *lack* of forwarding (see [RFC4291]
 section 2.5.6).  I think if there is a need for scope value 3 it is to
 provide classic Link-Local multicast behavior over a connected mesh.  I
 think the definition should be independent of RPL and instead depend on
 some "L2 instance" definition. PAN ID works for 802.15.4 networks.
 >A RPL domain (that is an 03) that may span multiple PAN IDs.
 draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based
 on PAN ID.  The latest version makes no mention at all of RPL.
 >If PAN ID was 04 that would have been reverse nesting.
 > The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.
 > Would a RPL domain be constrained by the PAN ID?
 > In this case that would imply that all the LLN must always be a single
 PAN and constrain the size of a >subnet to 64K. There is a lot behind the
 sentence "care must be taken in the definition of those larger >scopes to
 ensure that inclusion constraint is met."
  I think the understanding that was reached at dinner last week is that,
 under certain circumstances, policy can count as "administratively
 configured".  Thus, if a RPL instance contained several PAN IDs then the
 former could be used as the basis of a scop 4 zone as long as if fully
 enclosed the PANs (scop 3 zones). OTOH, if a given PAN contains multiple
 RPL instances then the latter cannot be used to define a scop 4 zone
 boundary because that would violate the RFC 4007 constraints that Brian
 enumerated. </kerry>


 <michael> http://www.ietf.org/mail-archive/web/roll/current/msg08353.html


 >Kerry Lynn <kerlyn at ieee.org> wrote:
     > I mostly agree Brian;

     > It's a bit touchy because in 802.15.4 a PAN ID is configured
     > administratively and could lead to an 04 interpretation.
     > One could take that argument to the extreme and say that selecting
 SSID
     > (802.11) or plugging into a wall socket
     > (802.3) is an administrative act.  Let's not be too literal and
 instead say
     > that the "automatic" zone boundary
     > definition applies to an existing LAN.  If you think about a Link-
 Local

 I offer this definition: an independant outside observer can determine the
 boundaries of scope 3 (2, and 1) can be observed without knowledge of the
 internal policies of a node.  That's why we can say that it is
 automatically
 defined: there is no choice to make or policy to apply.

 This is obvious with a wired network: you just follow the wires.
 (The nodes/machines don't even need to be on.)
 For a wireless network, you need to have a radio to sniff with, but given
 that, you can mostly determine things.

 scope 4 is the first scope where a policy *may* come into play.

 The thing that broke up the log jam last week was the understanding that
 policies may be administratively defined such that the device can make a
 decision on it's own, but that this decision is not necessarily visible to
 an
 external observer. </michael>


 <samita> http://www.ietf.org/mail-archive/web/6lo/current/msg00299.html


 Hi Tim,

  >Are there use cases documented somewhere in a 6lo or 6lo-related draft?

  >I'm interested as we're updating the homenet text about multicast
 scopes.  We have agreed  >some text in principle with Brian for that, but
 it's interesting because we may, indeed are  >likely to, have 6lo networks
 within future IPv6 home networks.

 [SC>] AFAIK,  6lo/6lowpan basic documents do not discuss the multicast
 scopes in details.
 [SC>] It'll be certainly helpful to document the scopes of 6lo within the
 scope of home networks or equivalent.
 In addition I think, it'd be really helpful for implementers if we provide
 some examples of scopes of different protocols in the 6man-multicast-
 scopes doc along with the pointer to RFC 4007. </samita>



 <tim> http://www.ietf.org/mail-archive/web/roll/current/msg08358.html


 >On 15 Nov 2013, at 00:12, Samita Chakrabarti
 <[e-mail]> wrote:
 > In addition I think, it'd be really helpful for implementers if we
 provide some examples of scopes of different >protocols in the 6man-
 multicast-scopes doc along with the pointer to RFC 4007.
 That would be excellent.  A separate document targeted at homenet WG
 showing multicast scenarios might be nice, but perhaps overkill. </tim>

-- 
---------------------------------------+------------------------------
 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://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:17>
roll <http://tools.ietf.org/wg/roll/>