Subject: Re: [6lo] Request for agenda items

From: "Turner, Randy" <[email-masked]>
Date: Tue, 9 Jun 2015 18:18:01 +0000

Hi,
I recently submitted a draft regarding DHCP configuration of RFC 6282 compression contexts that I would like to discuss at a Prague 6lo meeting slot - it's a quick read, shouldn't take more than 10 mins.

https://tools.ietf.org/html/draft-turner-dhcp-6co-00

Thanks!
Randy

From: Gabriel Montenegro <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 8, 2015 at 8:45 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Samita Chakrabarti <[email-masked]<mailto:[email-masked]>>, "James Woodyatt ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: [6lo] Request for agenda items

Folks,

We have requested 2 meeting slots for Prague: a 2 hour and a 1 hour. We may not get the full 2 meetings, as this depends on whether we can show we actually need them. Time in Dallas at the last IETF was very tight. In order to better gauge how much time we will need, we'd like to get an initial idea about the agenda.

Please let us know if you would like a slot in Prague. As always, we can't guarantee we will grant all requests, but knowing them ahead of time is always better.

Thanks,

chairs

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 09 Jun 2015 21:42:43 +0200

Hi Randy,

Turner, Randy wrote:
> DHCP configuration of RFC 6282 compression contexts

RFC 6282 compression contexts need to be identical between each pair of
compressing and decompressing nodes, i.e., throughout the LoWPAN.  RFC
6775 provides a way to disseminate this information that is relatively
robust in this respect; there is also a discussion about the life cycle
considerations that apply here in Section 7.2 of RFC 6775.
A quick scan of the new draft does not yield answers to the obvious
questions:
-- how is the consistency throughout the LoWPAN ensured?
-- how are life cycles managed?

Actually, I would like to have additional information about why you
think that DHCP is a better way to manage compression context
information than the mechanisms provided in RFC 6775.

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 9 Jun 2015 19:54:10 +0000

>Actually, I would like to have additional information about why you think that DHCP is a better way to manage compression  >context information than the mechanisms provided in RFC 6775.

[SC>] I have the same question for Randy before going into the details. 6lo/6lowpan is built upon ND auto-configuration where no additional infrastructure is needed to support address/compression context assignment etc.   

There may be some deployment cases where one optionally wants to use existing infrastructure[ DHCPv6] to offer the services. 
Understanding that requirement is important.

Thanks,
-Samita

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 9 Jun 2015 21:14:57 +0000

Hi Carsten,

Thanks for reading the draft.

Let me think about your life cycle question - if we need to add something,
that¹s fine. We can do that.

As for DHCP vs. 6775, my company, as well as others, have proposed a
network that relies on RPL DIO messages to establish neighbor and routing
connectivity to the network. This type of network has no IPv6 ND traffic
on the network (yet).

Rather than overload neighbor discovery with more and more configuration
duty, we¹re using something that is designed for network configuration.
We could have used RFC 6775 ³only² to disseminate compression contexts,
but we also have to configure other parameters, such as:

https://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-04

So we¹ve already bitten the bullet on using DHCPv6, which will come in
handy if/when we need to configure other parameters that NAN devices may
need to know - it seemed a better long term solution than burdening RPL
DIOs or ND messages with even more configuration options.

We¹re also using the ³Rapid Commit² option to limit the DHCP traffic on
our constrained network, along with an idea or two from Jonathan Hui¹s
original draft on DHCP for 6LoWPANs
(https://tools.ietf.org/html/draft-hui-6lowpan-dhcp-00)

Thanks again for your comments

Randy