Re: [Roll] New Text for the Charter

[Thomas Heide Clausen <[e-mail]>]

Pascal,

I agree with much of what you say, but notably except the last  
sentence of:

> My take is that we'll need to be creative when we define the  
> unicast routing to try and fulfill the multicast requirements we  
> have for as little additional cost as we can... But I would keep  
> the charter as it stands for that matter.

I think that if the "multicast"/"multipoint" requirement is to appear  
as an important design space constraint for ROLL protocols, then this  
should be made evident in the charter.

I also think that disambiguifying multicast/multipoint would be of  
value.

Thomas

On Feb 19, 2009, at 12:20 PM, Pascal Thubert (pthubert) wrote:

> Hi:
>
> First I wish to concur with Phil and JP that we need to avoid the  
> confusion between multipoint and multicast. I'll be elaborating a  
> little bit on multicast and IPv6.
>
> Link scope multicast (FF02:...)
> -------------------------------
>
> IPv6 relies on link scope multicast capabilities for a number of  
> activities, such as ND. IPv6 does not expect that a Link scope  
> multicast will ever be routed / relayed at layer 3. For instance ND  
> actively checks against a change in the hop limit that is set to  
> 255 for that purpose. Hello protocol uses FF02::5 with the  
> expectation that only direct connectivity shows up. Etc...
>
> Now the type of network we're looking at derives largely from the  
> NBMA model, and NBMA does not provide native link layer multicast  
> capability; moreover, in the P2MP case, FF02 would need routing and  
> relaying to span the whole network, which is incompatible with how  
> link scoped multicast is used in the first place. So for the  
> purpose of IPv6 operation, a number of approaches have been  
> proposed to emulate multicast and enable transparent IPv6 operations.
>
> RFCs 2491/2022/2332: This is the generic model for large NBMA. Mars  
> (RFC 2022) is an example of convergence protocol to emulate  
> multicast transparently to ND and others.
>
> RFC 3122: A new form of ND is introduced that does not need a link  
> spanning multicast service. Can be coupled with the above id DAD is  
> required. Secured and generalized in draft-thubert-3122bis.
>
> 6LoWPAN: A subcase of NBMA with a backbone link where FF02::  
> multicast actually works. An ND extension enables registration over  
> the NBMA edge and proxy operation over the backbone. That same  
> registration enables a service similar to MARS for the purpose of  
> NS/DAD, but in a lot simpler and less generic fashion. For those  
> link scope multicast that could not be avoided, such as some RAs,  
> Trickle optimizes the dissemination of the information in the Low  
> Power network.
>
> It's unclear at this point how far ROLL can reuse that art and how  
> efficient that would be; I certainly would not oppose to having an  
> additional work item to study this specific issue and produce an  
> informational draft. But it's not proven we have a specific problem  
> with link scope multicast that prevents ROLL operation either.
>
> L3 (routed) multicast, that is FF0x:... (x>2)
> ---------------------------------------------
>
> Multicast appears in the requirements document as the way to  
> distribute to many small groups of nodes; seems ROLL could survive  
> short term with multiple P2P even though it'd be inefficient in a  
> deep ROLL network.
>
> For all I've seen, that's mostly information and commands being  
> pushed from the infrastructure into the ROLL network. The way I see  
> it, we do not necessarily need a full fledged support of multicast,  
> but rather a way to distribute data coming from the outside along  
> trees that span the ROLL network from the network sinks. If the  
> routing that we define provides such trees, then the logical  
> structure can be economically reused for multicast distribution.  
> MANEMO did just that, though I think we never published the draft  
> that detailed the mcast NINA that carried MLD proxy registrations  
> up the TD tree.
>
> My take is that we'll need to be creative when we define the  
> unicast routing to try and fulfill the multicast requirements we  
> have for as little additional cost as we can... But I would keep  
> the charter as it stands for that matter.
>
> Pascal
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of JP Vasseur (jvasseur)
>> Sent: mercredi 18 février 2009 19:41
>> To: Philip Levis
>> Cc: ROLL WG; Thomas Heide Clausen
>> Subject: Re: [Roll] New Text for the Charter
>>
>>
>> On Feb 18, 2009, at 7:26 PM, Philip Levis wrote:
>>
>>> Comments inline.
>>>
>>> On Feb 18, 2009, at 10:17 AM, Thomas Heide Clausen wrote:
>>>
>>>>
>>>> On Feb 18, 2009, at 18:56 PM, Philip Levis wrote:
>>>>
>>>>> Comment follows.
>>>>>
>>>>> On Feb 18, 2009, at 7:17 AM, Thomas Heide Clausen wrote:
>>>>>
>>>>>> Chris, Jerald,  you both bring up an important question that I
>>>>>> hadn't fully realized: to which extend is the output of ROLL
>>>>>> going to be an unicast routing protocol? Multicast routing
>>>>>> protocol? Multicast transport protocol? Something else? All or
>>>>>> some of the above? Neither? In one protocol?
>>>>>>
>>>>>> I think that the charter might want to be a bit more specific on
>>>>>> this matter.
>>>>>>
>>>>>> I'd think that if ROLL wants to produce a single protocol doing
>>>>>> both uni- and multicast routing, then this should be spelled out
>>>>>> explicitly in the charter. If ROLL wants to produce both an
>>>>>> unicast routing protocol and a multicast routing protocol, then
>>>>>> this also should be spelled out explicitly in the charter.
>>>>>
>>>>> Thomas, I have to disagree on this point. I think that this
>>>>> decision, in and of itself, is protocol design. It would be a real
>>>>> mistake to bind the WG to one approach or the other without any
>>>>> examination of the tradeoffs of each approach. But that
>>>>> examination is what the re-chartering is for.
>>>>>
>>>>> For example, if the charter says "one protocol" but then this one
>>>>> protocol becomes clearly inferior to an approach with two
>>>>> protocols, we're in a bind. If the charter says "two protocols"
>>>>> but then there's a protocol that handles both seamlessly (and so
>>>>> has simpler code), we're in a bind.
>>>>>
>>>>> Phil
>>>>
>>>> Phil, I am actually not disagreeing with what you are saying
>>>> regarding the protocol(s) that will result. However if the ROLL
>>>> needs a solution for both unicast and multicast, then this should
>>>> be stated clearly. As it is, it reads simply:
>>>
>>> Great!
>>>
>>>>
>>>>
>>>>> -       Typical traffic patterns are not simply unicast flows,
>>>>
>>>>
>>>> Which I think is a bit too obscure a way of stating that the WG
>>>> will be working on both unicast and multicast solutions.
>>>
>>> I thought the new text says
>>>
>>> -       Typical traffic patterns are not simply unicast flows (e.g.
>>> in some environments most if not all traffic can be point to
>>> multipoint)
>>>
>>> so it articulates this. How do you think it could be improved?
>>>
>>> I think it might be important to separate the notion of "point to
>>> multipoint" from "multicast." Generally, IP mulitcast is handled by
>>> a node joining a multicast group. That is, the set of recipients is
>>> defined by which recipients join the group. In contrast, you'll
>>> notice that in some application docs the requirements are a bit
>>> different: a sender wants to deliver a message to a group of nodes,
>>> where the group is defined by the sender. Its seems very likely that
>>> multicast is a good way to achieve this, but we're then specifying
>>> the solution, rather than the requirement.
>>>
>>
>> You stole my words .. fully agreeing.
>>
>>> Does that make sense? It's a very fine line, trying to crisply
>>> define what the WG needs to accomplish without defining too tightly
>>> and excluding mechanisms that very useful.
>>>
>>> Phil
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll