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


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


 >On 15/11/2013 00:31, Kerry Lynn wrote:
 >…
 >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 vover 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.
 <RCC>+1 - how PAN ID is assigned does not constitute "administratively
 configured" as it is a layer 2 concept.</RCC>
 >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.
 <RCC>Agree that RPL should not be mentioned here.</RCC>

 >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.
 <RCC>MPL is orthogonal to RPL DODAGs. If there is a requirement to reach
 all nodes in a RPL DODAG which spans multiple 802.15.4 PANs, then that
 would be administratively configured and scope 4. If a RPL DODAG is wholly
 contained within the PAN ID then there would need to be some additional
 discriminator to limit propagation among a node set smaller than that of
 all nodes with the same PAN ID. In other words, it cannot be limited by
 just scope, which is too coarse a measurement. MPL doesn't cater for this
 as MPL Domains are defined as scope zones.</RCC> <robertCragie>


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


 > On 15 Nov 2013, at 00:12, Samita Chakrabarti <samita.chakrabarti at
 ericsson.com> wrote:
 >
 >> 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 - I don't understand what you're suggesting as "scopes of different
 protocols in the 6man-multicast-scopes".  Do you mean examples of the
 definition of scope 3 for various L2 technologies? - Ralph <ralph>

-- 
---------------------------------------+------------------------------
 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:18>
roll <http://tools.ietf.org/wg/roll/>