RE: [6lowpan] 6lowpan hallway pre-meeting

All,

Thanks for the meeting minutes. I am sorry I could not attend.

My initial comments:

Address assignment:
Before I comment on this I agree scalability is a concern in routing,
but I am a bit concerned of assuming the amount of "MAC technologies"
embedded into addresses such as the topology information. In this path,
I am afraid that solutions would not be generic enough. From my
perspective, I think how addresses are assigned is implementation
dependent. 

Dictating the addressing methodology to have implicit routing
information is an interesting idea but not sure all implementations may
need it. Decoupling the addressing and routing because of the following
reasons:

1. Making a node to route a particular fashion may not be suitable for
lowpans as nodes are constrained in different manners. (bandwidth,
energy, etc) and may want to choose routing via different nodes
depending on these constraints.
2. Heterogeneity can exist at different layers. Various kinds of
heterogeneity may exist. Addressing is just one kind of service.
3. Specifying how MAC addresses are assigned may not be an IETF concern.

Optimization:
I agree that device constraints restrain the packet size. My 2c for the
"It is not quite clear what we are optimizing for", is in my mind, I
think we one of the many things that we may are optimizing for is the
control messages to be within one 802.15.4 packet. (Control packets
could be packets needed to maintain the network such as routing packets,
etc.) The others are of course the amount of packets needed, methods for
disseminating packets, etc.

I also want to capture one more important application that I found
missing here is the industrial automation space: This includes proactive
maintenance, machine monitoring, etc. This is an important space as this
has some unique requirements is characterized by frequent bursty data
but less frequent in terms of collection cycles.

Interface to routing:
I really like the "plug and play" concept for routing layers as the
routing protocol is application dependent. One strategy we may choose to
do is to specify frame work for reactive and proactive routing protocols
at LoWPAN and specify guidelines for adapting routing layer to lowpans.

Nandu

 am a little concerned about specifying addresses where routing is
embedded. 
-----Original Message-----
From: 6lowpan-bounces@lists.ietf.org
[mailto:6lowpan-bounces@lists.ietf.org] On Behalf Of Carsten Bormann
Sent: Sunday, July 31, 2005 10:29 AM
To: 6lowpan@ietf.org
Cc: Carsten Bormann
Subject: [6lowpan] 6lowpan hallway pre-meeting

Lowpanners,

there are 9 drafts that are relevant to this week's meeting at the IETF.

Two working group drafts:

draft-ietf-6lowpan-format-00.txt
draft-ietf-6lowpan-problem-00.txt

Seven independent submissions:

draft-chakrabarti-lowpan-ipv6-nd-00.txt
draft-chakrabarti-mobopts-lowpan-req-00.txt
draft-daniel-6lowpan-hilow-hierarchical-routing-00.txt
draft-daniel-6lowpan-interoperability-01.txt
draft-daniel-6lowpan-load-adhoc-routing-01.txt
draft-daniel-6lowpan-sslp-00.txt
draft-montenegro-lowpan-aodv-00.txt

It is pretty clear that we can't cover this ground in the one-hour  
meeting we have on the official agenda.
Since most of the authors and other interested people are here in  
Paris, I'm proposing that we have an off-line meeting

     Monday, 18:30, at the corner of the terminal room to the right  
of the entrance (where the L-shaped table arrangement is).

We need to discuss:

What is the impact of each of the seven independent submissions on  
the probable course of action?
Is the charter's assumption that we'll finish the encapsulation/ 
format first and then tackle security/routing the right way forward?
Are the additional proposals going to require changes in our current  
standards track document (draft-ietf-6lowpan-format-00.txt)?
What do the authors want to have happen to the additional submissions?

Of course, no decisions are made in smoke-filled rooms; this is just  
about maximizing use of the face time.
We will summarize the discussion to the list.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6lowpan@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan