Subject: [6lowpan] new charter text

From: Geoff Mulligan <[email-masked]>
Date: Wed, 11 Jun 2008 13:02:58 -0600

After reviewing the comments on the list and talking with Carsten and
Mark, we have come up with the following text for the Charter.

We hope (and think) that this reflects the input from the group and Mark
plans to take this to the IESG for rechartering approval.

We've had some excellent discussion on a few topics and this is great.
There is no reason why we should stop the discussion and work while Mark
handles the rechartering.

1. I think that the work is proceeding on the Security Analysis document
2. We have the current HC1G draft.  The issue being discussed is the
"compression" of the UDP checksum and it's impact on the end-to-end
model.  I would like to hear more input and discussion on this.  Please
speak up if you have thoughts on this.
3. We have some initial input on the Architecture document and I would
like to hear from anyone that would volunteer to continue to work on
this document.

	geoff

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 12 Jun 2008 10:49:03 +0900

Geoff,

6LoWPAN use-case was always in the recharter items, and there was no
objection on it. Any reason to take it out?
Thanks for the good work.

-eunah

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 10:11:17 +0200

Same question.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 12 Jun 2008 10:43:01 +0200

I have no problem with the WG having an informational use-case work item 
in its charter. We have to understand that use-cases cannot cover the 
entire spectrum of how a protocol may get used, but can provide a 
general understanding and lay the groundwork for certain boundaries and 
requirements.

- Mark

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Jun 2008 10:43:59 +0200

Hi Geoff:

There was a clear support for the group on my proposal from May 30th.

Now you took out:
- 6LoWPAN use-case as Eunah points out
- and the larger work on improving 6LowPAN operation (fragment recovery
and whatelse)

You need to explain why. There is advanced work on both and people
willing to do the job.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoff Mulligan
>Sent: mercredi 11 juin 2008 21:03
>To: 6lowpan
>Subject: [6lowpan] new charter text
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 10:45:31 +0200

We're in sync, this is exactly in the spirit of the existing ID.

Thanks.

Cheers.

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 06:38:36 -0600

It didn't seem to be a priority item. 

Perhaps we should consider incorporating the Use Cases into the
architecture document.  If not then I think once we complete the few
documents we should then revisit the use cases.

	geoff

---

From: Mark Townsley <[email-masked]>
Date: Thu, 12 Jun 2008 15:58:33 +0200

> There was a clear support for the group on my proposal from May 30th.
I agree. My read of the list was that there was support for your proposal.

- Mark
>> We hope (and think) that this reflects the input from the group and
>>     
> Mark
>   
>> There is no reason why we should stop the discussion and work while
>>     
> Mark
>   
>> 1. I think that the work is proceeding on the Security Analysis
>>     
> document
>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 12 Jun 2008 16:06:52 +0200

Geoff Mulligan wrote:
> architecture document. 
Whether the use-cases are in the arch document or separate is somewhat 
orthogonal to whether they are chartered work right now.
>  If not then I think once we complete the few
I a missing why writing down use-cases is not a good thing to do sooner 
rather than later. I don't think it should stop protocol work in its 
tracks, but I see no indication right now that it would. As long as the 
use-cases are considered informational and can run largely in parallel* 
to the normative work at this stage, I don't know why we wouldn't pursue it.

- Mark

*If this were the very beginnings of 6lowpan, I would insist on 
use-cases to help drive requirements, architecture, and finally solution 
design. While we are somewhat past that stage,  I do think they could 
still be very useful to ROLL, as well as going forward as we continue to 
debate the pros and cons of various optimizations.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 08:49:41 -0600

It was clear that items: 1(ND), 3(Architecture) and 5(Security) were
priority items.  It was less clear to the three of us that use cases
were a priority item.

It sounds like we have people that would like to continue to work on the
use cases and that completing them in parallel to the other efforts
would be a "good thing".

What schedule do the authors anticipate completing the document?

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 19:48:36 +0200

Hi Geoff,

> Perhaps we should consider incorporating the Use Cases into the

Heu ? I do not think that it belongs there though ...

> documents we should then revisit the use cases.

Not sure to understand ... Why not adding this item now in addition to the
fragment recovery item since there was a consensus (if OK with Mark) ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 19:50:11 +0200

Hi Mark,

> debate the pros and cons of various optimizations.

Absolutely ! The only (but useful) objective is to document 6lowpan
application, informational ID of course.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 19:52:52 +0200

Hi Geoff,

> What schedule do the authors anticipate completing the document?

Well hopefully you do not require to terminate the document before it
becomes a WG item ;-) To answer your question, it is already the second
revision, the third revision will be posted before Dublin and we'll be
having a fairly stable ID.

Thanks.

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 11:59:18 -0600

Please do not misunderstand my/our intentions.  In reading the various
messages about the rechartering, it did not appear to us as though the
use-case was a priority item - not that it was not useful or would not
be useful, just not a priority.  That was the only reason it was left
off of the charter.  It was very clear that ND, Arch, and Security were
at the top of the list.

I am not at all against continuing with the use-case ID in parallel to
the rest of the documents.  I think that it is and could be useful.

I will add it back to charter text, but please let me know a date that
we can plan to have the ID completed.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 12:00:27 -0600

I would just like a date that we all feel comfortable putting in for the
completion and moving to the IESG.

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 20:03:41 +0200

Hi Geoff,

> off of the charter.  It was very clear that ND, Arch, and Security were

And they are on the top of the list, no question about this.

> we can plan to have the ID completed.

Sure, what about Dec 2008 for IESG submission?

Thanks.

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 12:19:46 -0600

This is probably fine.  Since we are already no Rev 2 we might be able
to complete it sooner, but I don't want to pressure anyone.  I hope that
the current authors can provide some input.

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jun 2008 20:37:08 +0200

> the current authors can provide some input.

I'm one of them. Eunah, what do you think ?

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 12 Jun 2008 12:47:08 -0600

I'm sorry JP.  I had forgotten that you were an author.  I hadn't looked
at the authors and had just remembered Eunsook and Dominik.  Sorry to
Nicolas also.

Since we want to press forward, I'll assume that Dec 08 is a comfortable
date and put this missing piece back into the charter and resend it to
everyone.

	geoff

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Fri, 13 Jun 2008 16:15:55 +0900

Sorry not to involve the discussion on time.
I was out of the office.
Thanks JP to handle this matter. :)

Dec 2008 sounds fine with me.

-eunah

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 13 Jun 2008 07:59:33 -0600

With the input from the authors we've put the "Use Cases" back into the
text for the charter for the working group with a delivery date of Dec
08.

Attached is the NEW new charter text.

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Jun 2008 18:01:50 +0200

Hi Geoff,

Thanks for sending out the new revision. One question, one comment.

Question: could you explain the rationale for leaving out the fragmentation
recovery item?

Comment:

"3. Produce "6LoWPAN Architecture" to describe the design and
implementation of 6LoWPAN networks.  This document will cover the
concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such
as operation with sleeping nodes, network components (both battery-
and line-powered), addressing, and IPv4/IPv6 network connections.
As a spin-off from that document, "6LoWPAN Routing Requirements" will
describe 6LoWPAN-specific requirements on routing protocols used in
6LoWPANs, addressing both the "route-over" and "mesh-under" approach.
Both documents will be informational."

I do not understand the rationale here: I think that we should first
determine whether we both need a mesh-under *and* a route-over approach. You
know my opinion: we have numerous examples in the past of such approaches
that ALL failed for obvious technical reasons but this is my technical
opinion. As far as 6lowpan is concerned, shouldn't we first have a
discussion to get a consensus there ? *If* it turns out that both are
needed, then add an introductory section in the architecture document
pointing to the requirement document(s).

Thus I would rather suggest not to list this as a WG item but to leave it
out for the moment and continue to have the discussion until we have a
consensus. Then at that point we could decide what to do. On the other hand,
having a separate documents listing the 6LoWPAN specific routing
requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot
of sense.

Thoughts ?

Thanks.

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 13 Jun 2008 11:25:05 -0600

JP,
  As I said previously, when Carsten, Mark and I reviewed the
comments/messages on the list it was clear that ND, Architecture, and
Security were priority items along with dealing with enhancements to
compression of non link local addresses and that there was clear support
to take these on within the working group. And now also the Use Cases
draft.

I am less certain that there is consensus that fragment recovery is a
necessary working group item at this point.  So I will ask the WG.

As to your question about the Arch doc, I'm not sure that I understand
the question or the timing?  The text for this hasn't changed for
months.  It seems that there are members of the WG that want to see the
architectural description that includes both a mesh under solution and a
route over.  How would you propose that we determine if there is a need
for both?

geoff

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Jun 2008 19:33:58 +0200

Hi Geoff,

> route over.  How would you propose that we determine if there is a need

My proposal would be to have a discussion on this topic first, trying to
reach a consensus in the WG on whether or not we need to define a mesh-under
solution. Once we have reached a consensus, then move on and start to
incorporate it as part of the architecture ID or another document.

In term of routing requirement ID, I would suggest:
* To move ahead with the 6lowpan specific requirement ID, owned by the
6lowpan WG and reviewed by ROLL,
* hold-off on the mesh-under routing requirements until we have reached a
consensus.

Makes sense ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Jun 2008 19:36:44 +0200

Adding ROLL.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Jun 2008 19:37:15 +0200

Adding ROLL.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 13 Jun 2008 11:47:26 -0600

So do think that the text of the Arch doc item needs to be changed or
are you thinking that it arch doc item needs to be removed completely
until we have the mesh-under vs router over discussion?

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Jun 2008 20:03:25 +0200

I would suggest to reword the text related to the architecture ID and remove
the mesh-under/route over discussion for the moment.

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 13 Jun 2008 12:10:17 -0600

Folks,
  I think that our charter will be discussed on the next IESG telechat,
next Thursday!  We need to get the text correct and to Mark WELL BEFORE
the Thursday.

JP has suggested a change to the wording for the Arch Doc draft item.
Please send a message indicating your thoughts about the change.

While I thought that we did have consensus around this particular item I
would like to make sure that we do.

Should we remove the text about mesh-under and route-over?
Should we leave the text as it is?

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Jun 2008 20:22:07 +0200

> the mesh-under/route over discussion for the moment.

There appears to be some confusion here.

The text about the architecture document says:

> This document will cover the concepts of "Mesh Under" and "Route  
> Over",

Any architecture document that does not define these terms would be a  
rather strange architecture document indeed.

>>> solution.

Why would we need such a consensus in the WG with respect to the  
current charter text?
Right now the charter does not ask require the WG to "define a mesh- 
under solution", and I'm pretty sure we have had rough consensus for a  
while that we aren't in a position right now to define the mesh  
routing protocol part of that solution.
So the charter proposals on the table always have left that part out.

I'm a bit tired of reopening this specific discussion; it is quite  
clear now that there always will be L2 meshing and L3-only routing  
camps.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Jun 2008 20:25:55 +0200

> necessary working group item at this point.  So I will ask the WG.

There certainly was some interest in this optimization.
I'm not feeling comfortable at this point that we can reach consensus  
on a solution within the time frame of this charter round.
So my proposal would be to keep discussing this optimization (as we  
undoubtedly will do with other optimizations as well), maybe converge  
quickly, and then decide whether we ask for a charter extensions this  
round or add it to the next charter.

Gruesse, Carsten

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 13 Jun 2008 12:14:46 -0700

> rather strange architecture document indeed.

I agree 100% here. The current text on the charter regarding
describing the concept of "Mesh Under" and "Route over" are very
important.  I am sure there are folks in the wg who can handle texts
for the respective sections. Please keep them.

Also, it seems that Arch document would be a good place to include a
few use-case scenarios too for completeness.

Thanks,
-Samita

---

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jun 2008 10:46:05 +0200

Hi,

> for the respective sections. Please keep them.

Remember this is not a text book (referring to your comment several IETF ago
Carsten) but a document that describes the 6lowpan architecture that does
not specify route over and where mesh-under is not yet a given ...

> few use-case scenarios too for completeness.

You might have noticed that there is a separate WG item for this.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jun 2008 11:30:47 +0200

Hi Carsten,

> rather strange architecture document indeed.

Well hopefully we do not need to define what Routing means at the IETF ;-)
and the notion of mesh-under is a form of routing at layer 2 (not really in
the scope of the IETF).

Since this is a contentious debate to say the least, I was proposing to deal
with it as a separate item for the moment so as to quickly move forward with
the architecture document where lot of work is still needed.

> routing protocol part of that solution.

Great.

> clear now that there always will be L2 meshing and L3-only routing

This is why I was suggesting to leave it out for the moment in order to
quickly move forward on other key topics and then try to reach a final
consensus documented in the separate ID.

Thanks.

JP.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jun 2008 11:31:03 +0200

> round or add it to the next charter.

OK.

JP.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 14 Jun 2008 22:31:54 +0200

> the architecture document where lot of work is still needed.

I'm still confused.
What is the debate you are referring to?

In case you actually do mean the mesh-under vs. route-over debate:
It is pretty clear that there will be mesh-under and route-over.
I cannot quite imagine reaching consensus on dropping one of them now.
I also cannot imagine a coherent architecture that ignores this  
important distinction.
So I thought we would continue to address both approaches in the  
architecture document.

(For those who came late to 6lowpan: The assumption so far has been  
that 6lowpan would, as any IPv6 link is, be agnostic with respect to  
forwarding/routing operating on top of it, and that it would support  
L2 forwarding ("mesh-under"), with a slight focus on stubby lowpans.   
See section 4.2 of RFC 4919.)

Gruesse, Carsten

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Mon, 16 Jun 2008 15:58:27 +0900

I support the current proposed charter.
I also think that 6LoWPAN architecture needs to include both approaches.

Thanks.
-eunah

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 16 Jun 2008 10:03:31 +0200 (CEST)

Dear all, Geoff,

I support leaving the new charter text as it is.

Greetings,

Carles

> ï»¿Should we remove the text about mesh-under and route-over?
>> >>>> determine whether we both need a mesh-under *and* a route-over
>> approach.
>> >>>> You
>> >>>> consensus. Then at that point we could decide what to do. On the
>> other
>> >>>> hand,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Jun 2008 10:51:35 +0200

Hi:

>necessary working group item at this point.  So I will ask the WG.

Considering that 6LoWPAN packets can be as large as 2K bytes and that
a 802.15.4 frame with security will carry in the order of 80 bytes of
effective payload, a packet might be fragmented into about 25
fragments at the 6LoWPAN shim layer.  This level of fragmentation is
much higher than that traditionally experienced over the Internet
with IPv4 fragments.  At the same time, the use of radios increases
the probability of transmission loss and Mesh-Under techniques
compound that risk over multiple hops.

Past experience with fragmentation has shown that missassociated or
lost fragments can lead to poor network behaviour and, eventually,
trouble at application layer. Enlighteneing reading on that subject
is found in  http://tools.ietf.org/html/draft-mathis-frag-harmful.  
That experience led to the definition of the Path MTU discovery
protocol that avoids fragmentation over the Internet.

An end-to-end fragment recovery mechanism can be a good complement
to a hop-by-hop MAC level recovery with a limited number of retries.
Additional flow control and Explicit Congestion Notification would
help prevent congestion collapse. We have enough experience at the 
IETF to know that these mechanisms are required and design them 
properly.

Pascal

Behalf Of Geoff Mulligan
>Sent: vendredi 13 juin 2008 19:25
>To: Jean Philippe Vasseur (jvasseur)
>Cc: 6lowpan
>Subject: Re: [6lowpan] New new charter text
>
>JP,
approach. You
>> consensus. Then at that point we could decide what to do. On the
other hand,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Jun 2008 11:46:55 +0200

Hi Geoff:

This part:
"
such as reusing the structure of the 802.15.4 network
(e.g., by using the coordinators), and reduce the need for multicast
by having devices talk to coordinators (without creating a single
point-of-failure, or changing the semantics of the IPv6 ND
multicasts) 
"

Might be unwelcome. Seems to dictate solutions, which solutions might be
hard to achieve at IETF. 
Note that I am in favor of using L2 beacons as opposed to uniquely data
frames to carry RAs.
Can we just remove this text for the time being, and just say that we
want to
" reduce the need for multicast ", "limit the need to wake up sleeping
devices", that type of things?

Pascal

Behalf Of Geoff Mulligan
>Sent: vendredi 13 juin 2008 16:00
>To: 6lowpan
>Subject: [6lowpan] New new charter text
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jun 2008 15:39:44 +0200

On Jun 16 2008, at 10:51, Pascal Thubert (pthubert) wrote:

> http://tools.ietf.org/html/draft-mathis-frag-harmful

Which has since become RFC 4963, "IPv4 Reassembly Errors at High Data  
Rates".
Mandatory reading in some of our classes (see also RFC 3819, for a  
more general overview of L2/L3 issues), but kind of less relevant for  
IPv6.

(PLPMTUD is RFC 4821, but doesn't really help with the 6lowpann issue,  
because the IPv6 MTU *MUST* be >= 1280, and we would prefer  
applications to stay well below that -- there is no easy way in IPv6  
to tell them.)

The situation right now (RFC 4944) is that applications just have to  
know that large packets will have bad performance.
This is a classical case of the L2/L3 not being able to tell L4/L7  
something it needs to know.
Fortunately, many 6lowpan applications will run custom protocols on  
top of UDP, so they can keep this under consideration.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Jun 2008 17:26:39 +0200

Hi Carsten;

Thanks for the pointer, it's all the more interesting that
tools.ieft.org fails to refer it.
I'll update the fragment recovery draft with the proper reference. 

Now I fail to gather your conclusion: 
Do you mean that applications should refrain from sending more than 80
bytes at a time to avoid 6LoWPAN fragmentation to occur?

Pascal

>From: Carsten Bormann [mailto:[email-masked]]
>Sent: lundi 16 juin 2008 15:40
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Geoff Mulligan; Jean Philippe Vasseur (jvasseur);
6lowpan
>Subject: Re: [6lowpan] New charter text: fragment recovery item
>

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Jun 2008 10:02:01 -0700

Hi Pascal,

> devices", that type of things?

I  respectfully disagree with you on that. The solution that reduce
the need of multicast in IPv6 already exists and it has been discussed
in the working group many times in the past. Please refer to:
draft-chakrabarti-6lowpan-ipv6-nd-04.txt

There is a need for reducing multicast and broadcast in the
reduced-power and low-processing ability devices that require to save
power and do not want to wake up on multicast/broadcast messages - it
is pretty clear in 802.15.4 network.
The charter talks about the context of IPv6 where multicast is
primarily used for solicitation and advertisement and that will have
to be reduced since 802.15.4 is a shared network.

 I'll re-submit a revised draft before this IETF.

-Samita

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jun 2008 21:12:10 +0200

> bytes at a time to avoid 6LoWPAN fragmentation to occur?

In general: No.  This is IPv6, so nodes MUST be able to communicate  
using packets of up to 1280 bytes.

When designing an application protocol specifically for 6lowpans: I  
would try to optimize packet sizes so most packets fit in one  
fragment, possibly using semantic fragmentation to achieve that.  I'd  
certainly not start sending 16-fragment packets as a matter of routine.

So my (personal) summary for the discussion of this work item proposal  
would be: good point, but maybe not the most important optimization  
right now, as many applications are likely to minimize their  
transmission sizes anyway.

Gruesse, Carsten

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 17 Jun 2008 11:36:44 +0900

I am repeating my comments:

Samita, are you working for ND-Opt revision ? That's very welcome to me and
I am willing to contribute on this deliverable if any chances...:-)

[cut and paste from the previous thread]

This is a tip for understanding and referring how we can fat down NDP for
6lowpan networks. In 16ng working group, we tried to live up with IEEE
802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA
optimization results...

Hope those efforts help...

Daniel Park

Co-chair, 16ng working group.

*8.2**.  Router Advertisement*

   The AR SHOULD send a number (configurable value) of router
   advertisements as soon as the IPv6 link is established, to the MS.
   The AR sends unsolicited router advertisements periodically as per
   [RFC4861 <http://tools.ietf.org/html/rfc4861>].  The interval between
periodic router advertisements is
   however greater than the specification in Neighbor discovery for
   IPv6, and is discussed in the following section.

*8.3**.  Router lifetime and periodic router advertisements *

   The router lifetime SHOULD be set to a large value, preferably in
   hours.  This document over-rides the specification for the value of
   the router lifetime in Neighbor Discovery for IP Version 6 (IPv6)
   [RFC4861 <http://tools.ietf.org/html/rfc4861>].  The AdvDefaultLifetime
in the router advertisement MUST
   be either zero or between MaxRtrAdvInterval and 43200 seconds.  The
   default value is 2 * MaxRtrAdvInterval.

   802.16 hosts have the capability to transition to an idle mode in
   which case the radio link between the BS and MS is torn down.  Paging
   is required in case the network needs to deliver packets to the MS.
   In order to avoid waking a mobile which is in idle mode and consuming
   resources on the air interface, the interval between periodic router
   advertisements SHOULD be set quite high.  The MaxRtrAdvInterval value
   specified in this document over-rides the recommendation in Neighbor
   Discovery for IP Version 6 (IPv6) [
RFC4861<http://tools.ietf.org/html/rfc4861>].
The MaxRtrAdvInterval
   MUST be no less than 4 seconds and no greater than 21600 seconds.
   The default value for MaxRtrAdvInterval is 10800 seconds.

-- 
Soohong Daniel Park [at] Samsung Electronics
Standard Architect, http://blog.naver.com/natpt
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Jun 2008 23:52:04 -0700

Hi Daniel,
Yes, we will have an update of the ND-OPT draft as it has currently in
expired state.

If you have any specific comment/contribution on ND-OPT, let's discuss off-line.
The following information on ND tuning for 802.16 network is useful.

Thanks,
-Samita

On Mon, Jun 16, 2008 at 7:36 PM, Daniel Park <[email-masked]> wrote:
> 8.2.  Router Advertisement
>
>    [RFC4861].  The interval between periodic router advertisements is
> 8.3.  Router lifetime and periodic router advertisements
>
>    [RFC4861].  The AdvDefaultLifetime in the router advertisement MUST
>    Discovery for IP Version 6 (IPv6) [ RFC4861].  The MaxRtrAdvInterval

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jun 2008 10:01:13 +0200

Hi Samita:

I fail to see how we disagree ???

I am suggesting here to change the text that indicates what the solution
should *be* into text that indicates what the solution should *be
doing*. 

And we seem to agree on what it should be doing. I certainly read your
draft and liked it a lot. I do think there is a need to couple proactive
"white board" registration (such as detailed in the BbR draft) with your
reactive model and I'm ready to work with you on that anytime. 

Pascal

>From: Samita Chakrabarti [mailto:[email-masked]]
>Sent: lundi 16 juin 2008 19:02
>Cc: Geoff Mulligan; 6lowpan

---

From: "Dominik Kaspar" <[email-masked]>
Date: Tue, 17 Jun 2008 11:01:40 +0200

Hi,

I believe that the Use Cases document is very meaningful work. I will
continue to contribute to this document and I agree that finishing the
I-D until December 2008 is a feasible goal.

Greetings,
Dominik

---

From: Geoff Mulligan <[email-masked]>
Date: Tue, 17 Jun 2008 11:42:35 -0600

Dominik,
  Great.  Thanks.

	geoff