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)

[peter van der Stok <[e-mail]>]

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 <[e-mail]> wrote:
> 
>> On Wed, Oct 23, 2013 at 5:21 PM, 神明達哉 <[e-mail]>
>> wrote:
>> 
>>> At Wed, 23 Oct 2013 15:56:46 -0400,
>>> 
>>> Ralph Droms <[e-mail]> 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
>>> [e-mail]
>>> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 [1]
>>> 
>> --------------------------------------------------------------------
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll