Hi Pascal,

On Thu, Nov 14, 2013 at 6:58 PM, Pascal Thubert (pthubert) <
pthubert@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.
>

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.

HTH, -K-

Cheers;
> Pascal
>
>
> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: jeudi 14 novembre 2013 07:23
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and;
> ipv6@ietf.org IPv6 List; 6lo@ietf.org
> 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:brian@innovationslab.net]
> > Sent: mercredi 13 novembre 2013 07:22
> > To: Pascal Thubert (pthubert)
> > Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and;
> > ipv6@ietf.org IPv6 List; 6lo@ietf.org
> > 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)" <
> pthubert@cisco.com> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>