Hi Mark, thanks for reigniting the discussion on this.
- Improving RFC 4944 is an important one. The biggest issue I have
with it in the near term is that the IPv6 header compression does not
allow compression of non-link-local addresses, which is an important
case if we truly intend to do inter-networking. This is the most
important point of the 6lopwan-hc draft. Backwards compatibility is
supported by utilizing new dispatch values. But it's important to
consider what the implementation costs are of supporting the
LOWPAN_HC1 defined in RFC 4944, especially since 6lowpan-hc does cover
most of the useful cases in LOWPAN_HC1. Something for the WG to
discuss...
- 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 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.
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: 6lowpan@ietf.org
>>> 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
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
