Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

[Robert Cragie <[e-mail]>]

Comments inline, bracketed by <RCC></RCC>

Robert

On 15/11/2013 00:31, Kerry Lynn wrote:
> Hi Pascal,
>
> On Thu, Nov 14, 2013 at 6:58 PM, Pascal Thubert (pthubert) 
> <[e-mail] <mailto:[e-mail]>> 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 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.
<RCC>+1 - how PAN ID is assigned does not constitute "administratively 
configured" as it is a layer 2 concept.</RCC>
>
>     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.
<RCC>Agree that RPL should not be mentioned here.</RCC>
>
>     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.
<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>
>
> HTH, -K-
>
>     Cheers;
>     Pascal
>
>
>     -----Original Message-----
>     From: Brian Haberman [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     Sent: jeudi 14 novembre 2013 07:23
>     To: Pascal Thubert (pthubert)
>     Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power
>     and; [e-mail] <mailto:[e-mail]> IPv6 List; [e-mail]
>     <mailto:[e-mail]>
>     Subject: Re: [6lo] Fwd: New Version Notification for
>     draft-ietf-6man-multicast-scopes-02.txt
>
>     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.
>
>     Regards,
>     Brian
>
>     On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote:
>     > Hello Brian:
>     >
>     > 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.
>     >
>     > Cheers
>     >
>     > Pascal
>     >
>     >
>     > -----Original Message-----
>     > From: Brian Haberman [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     > Sent: mercredi 13 novembre 2013 07:22
>     > To: Pascal Thubert (pthubert)
>     > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and;
>     > [e-mail] <mailto:[e-mail]> IPv6 List; [e-mail]
>     <mailto:[e-mail]>
>     > Subject: Re: [6lo] Fwd: New Version Notification for
>     > draft-ietf-6man-multicast-scopes-02.txt
>     >
>     > Pascal,
>     >
>     > On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote:
>     >> The document has been accepted as a WG work item.  Check out
>     >>
>     http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-
>     >> 0
>     >> 2.txt
>     >>
>     >>
>     >> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert
>     (pthubert)" <[e-mail] <mailto:[e-mail]>> wrote:
>     >>
>     >>> Hello Ralph:
>     >>>
>     >>>
>     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?
>     >>>
>     >
>     > Scopes are still nested.  See RFC 4007.  Are you saying that
>     this document is changing that?
>     >
>     > Regards,
>     > Brian
>     >
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo