Hi Jonathan,
On 5/21/08 3:19 PM, "Jonathan Hui" <[EMAIL PROTECTED]> wrote:
>
> Hi Mark:
>
> On May 20, 2008, at 8:24 AM, Mark Townsley wrote:
>>> - To your point on ND, this is precisely why the architecture draft
>>> is so important. We haven't given it as much attention lately, but
>>> it will help resolve the question your raise and many other
>>> questions in the future. For example, the architecture draft
>>> identifies two modes of operation: mesh-under and route-over. Both
>>> of which may require different ND mechanisms. This doesn't apply to
>>> just ND, but may apply questions of fragmentation, header
>>> compression, security, etc.
>> I worry about the under/over debate. It seems that with all the
>> effort and enthusiasm in ROLL, we might be well-served at the moment
>> by focusing on helping them be successful with route-over than
>> spending too much of our time on route-under.
>
> I worry too, especially since it will pull the WG in different
> directions. I'm with you on the preference for route-over, but others
> in this group feel strongly about mesh-under as well, especially since
> ISA100.11a seems to have adopted a mesh-under approach. I've
> personally been focused on developing route-over solutions while being
> conscious of supporting mesh-under when possible (evident with 6lowpan-
> hc). However, things will start to diverge when we start to talk about
> bootstrapping, ND, etc. So we should make a conscious decision of
> whether we're supporting one or both.
And I agree with, hence my previous email ... So far I have heard any strong
valid argument in support of both but I can certainly list a number of
reasons why not doing both.
But for the time being I think that we should try to quickly converge to get
the new charter stabilized to get back to Mark; there are IMO a long list of
items on which we should quickly move on (stateful header compression,
security, ...).
Thanks.
JP.
>
> --
> Jonathan Hui
>
>>
>>>
>>> - I hesitate a bit that we suggest possible solutions to ND in the
>>> charter ("reusing the 802.15.4 network structure (use the
>>> coordinators)") especially since the definition of such link
>>> mechanisms are still in motion within the IEEE. It seems more
>>> productive to me if we can develop mechanisms that are less
>>> dependent on the specific structure of 802.15.4 mechanisms.
>> I agree that we should develop mechanisms that could work
>> generically whenever possible.
>>
>> - Mark
>>>
>>> Rest of the charter looks good to me.
>>>
>>> Thanks.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>
>>>
>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote:
>>>
>>>> Pascal Thubert (pthubert) wrote:
>>>>> Hi Mark:
>>>>>
>>>>> I think we need a work item (usually implicit) around the concept
>>>>> of
>>>>> improving existing WG RFCs. RFC 4944 can be improved in several
>>>>> aspects:
>>>>>
>>>>
>>>>>
>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a
>>>>> to
>>>>> conform to 6LoWPAN would be a major win, but is certainly not a
>>>>> given.
>>>>> At the moment, the ISA100.11a documents expose discrepencies with
>>>>> RFC
>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc
>>>>> resolve
>>>>> for the most part.
>>>>>
>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager to
>>>> improve RFC 4944, but not eager to endorse changes that inhibit
>>>> interoperability.
>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop
>>>>> radio
>>>>> mesh exposes the network to congestion collapse, as described in
>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec
>>>>> overy . I think that the WG should dedicate some bandwitdth to
>>>>> provide
>>>>> additional functions that would improve the LoWPAN operation WRT
>>>>> flow
>>>>> control and recovery of fragments.
>>>>>
>>>> Fragmentation, OK, but why is flow control a network layer issue
>>>> rather
>>>> than a transport layer issue?
>>>>> Another aspect of ISA100.11a is the concept of a backbone router.
>>>>> It
>>>>> would be appropriate that the IETF comes up with a proposal to
>>>>> implement
>>>>> the concept in the IPv6 world. This partially falls under the
>>>>> first work
>>>>> item on ND but might also include ND proxy over the backbone
>>>>> which is a
>>>>> stretch to the work item. More in
>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>>>>> .
>>>>>
>>>> Well, don't we need to define what ND looks like on a lowpan
>>>> before we
>>>> decide whether it needs to be proxied or not?
>>>>
>>>> - Mark
>>>>> What do you think?
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>>>>> On
>>>>>>
>>>>> Behalf Of Mark Townsley
>>>>>
>>>>>> (townsley)
>>>>>> Sent: jeudi 15 mai 2008 23:02
>>>>>> To: [email protected]
>>>>>> Subject: [6lowpan] New charter for 6lowpan
>>>>>>
>>>>>>
>>>>>> I'd like to ask the group one final time for comments on the
>>>>>> proposed
>>>>>> new charter. I've also asked the ROLL WG chairs to comment.
>>>>>>
>>>>>> As I said before, soon after the format document was published,
>>>>>> there
>>>>>>
>>>>> is
>>>>>
>>>>>> nothing stopping the WG from discussing and working on new and
>>>>>> existing
>>>>>> items at this time. In fact, activity helps us to decide what
>>>>>> should be
>>>>>> in and out of the charter. Please do not construe not having a
>>>>>> charter
>>>>>> in place as a reason not to update drafts, or discuss topics
>>>>>> that need
>>>>>> to be discussed. Just as when we have BoF's and mailing lists
>>>>>> before
>>>>>> creating a new WG, it is good to have WG meetings and on-lists
>>>>>> discussions when creating new WG charters.
>>>>>>
>>>>>> - Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 6lowpan mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>>>
>>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
