Hi Daniel,

I think the conclusion in that case was that scope 4 would have to be used
as it would be difficult to imagine anything other than administrative
configuration for a scope which spans multiple links on different link
layer technologies.

Robert
On 25 Oct 2013 12:35, "Popa, Daniel" <Daniel.Popa@itron.com> wrote:

> Hi Peter,
>
> By "homogeneous multi-link network" do you refer to "homogeneous
> link-layer technology" ?
>
> If this is the case, I suggest we do not correlate the scope of the
> multicast to the use of a specific link-layer technology... We should be
> able to deploy systems where all nodes in a multi-link network can be
> members of the same "multilink-local multicast scope", independently of the
> link-layer technology they use (homogeneous or heterogeneous) to
> communicate with each other.
>
> Regards,
> Daniel
>
> -----Message d'origine-----
> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de
> peter van der Stok
> Envoyé : vendredi 25 octobre 2013 11:53
> À : roll@ietf.org
> Objet : Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was
> Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of
> 3 - subnet-local)
>
> I like the consensus that seems to emerge.
>
> It should be clear that the realm-local specification concerns a
> homogeneous multi-link network For example:
>
>   o Multiple links, following the same IP over Foo specification, and the
> interfaces attached to those links may form a multilink-local scope based
> on underlying network technology; for example, [cite the
> IP-over-IEEE802.15.4 definition].
>
> Peter
>
>
> Robert Cragie schreef op 2013-10-24 08:59:
> > On 23 October 2013 22:38, Kerry Lynn <kerlyn@ieee.org> wrote:
> >
> >> On Wed, Oct 23, 2013 at 5:21 PM, 神明達哉 <jinmei@wide.ad.jp>
> >> wrote:
> >>
> >>> At Wed, 23 Oct 2013 15:56:46 -0400,
> >>>
> >>> Ralph Droms <rdroms.ietf@gmail.com> wrote:
> >>>
> >>>> Perhaps we want to go a step farther and take the zone boundary
> >>> text
> >>>> out of RFC 4007 altogether?
> >>>
> >>> Basically works for me.
> >
> > <RCC>Me too</RCC>
> >
> >>>> 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 The boundaries of zones of a scope are defined by the IPv6
> >>>> addressing architecture.
> >>>
> >>> With a reference (it's currently RFC 4291)?
> >>>
> >>> I'd also note that not all points described in the RFC 4007 text are
> >>> described in RFC 4291 (at least not very clearly). So, not just
> >>> remove the text from RFC 4007, I'd like to unify it in the address
> >>> architecture, e.g. update the following part of RFC 4291:
> >>>
> >>> 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.
> >>>
> >>> as follows:
> >>>
> >>> 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.
> >>> For all non-reserved scopes except the global scope, the zone
> >>> boundaries must also be administratively configured.
> >>
> >> I think this statement is self-contradictory. When automatic
> >> configuration is discussed, it is in relation to zone boundaries.
> >> Here's an attempt to explain
> >>
> >> this without negations:
> >>
> >> Interface-Local, Link-Local, and Realm-Local scope boundaries are
> >> automatically
> >>
> >> derived from physical connectivity or other, non-multicast related
> >> configuration.
> >>
> >> Global scope has no boundary. The boundaries of all other
> >> non-reserved scopes
> >>
> >> are administratively configured.
> >
> > <RCC>
> > That makes it clear. IMO RFC4007 should be changed to something like:
> >
> > o Each interface on a node comprises a single zone of interface-local
> > scope (for multicast only).
> >
> > o Each link and the interfaces attached to that link comprise a single
> > zone of link-local scope (for both unicast and multicast).
> >
> > o Multiple links and the interfaces attached to those links may form a
> > multilink-local scope based on underlying network technology; for
> > example, [cite the IP-over-IEEE802.15.4 definition].
> >
> > o There is a single zone of global scope (for both unicast and
> > multicast) comprising all the links and interfaces in the Internet.
> >
> > o The boundaries of zones of a scope other than interface-local,
> > link-local, multilink-local and global must be defined and configured
> > by network administrators.
> >
> > Either that or just remove the text as Ralph suggested earlier.
> > </RCC>
> >
> >> BTW, just my opinion, but "Realm-Local" might be more meaningfully
> >> named
> >>
> >> "Multilink-Local"
> >
> > <RCC> I agree - it is more meaningful</RCC>
> >
> >> -K-
> >>
> >>> --
> >>> JINMEI, Tatuya
> >>>
> >> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>> Requests:
> >>> https://www.ietf.org/mailman/listinfo/ipv6 [1]
> >>>
> >> --------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll [2]
> >
> >
> >
> > Links:
> > ------
> > [1] https://www.ietf.org/mailman/listinfo/ipv6
> > [2] https://www.ietf.org/mailman/listinfo/roll
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>