Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08

From: Paul Chilton <[email-masked]>
Date: Mon, 09 Aug 2010 22:01:11 +0100

I have reviewed the HC-08 draft and think it is ready to go to the IESG
However the known problem regarding compression of headers which fit 
only in the first fragment, described in section 2 should be retained as 
a work item within the WG in order to arrive at a solution which does 
not suffer from this restriction
Paul

Carsten Bormann wrote:
> LoWPANners,
>
> on Monday we discussed HC-07 and said we should issue a final short
> working-group last call based on the outcome of the previous WGLC of
> HC-06 as reflected in HC-07 plus a small clarification to that.
> Jonathan went ahead and submitted a fixed HC-08 right during the
> meeting!
>
> This is now a Working-Group Last-Call for:
>
> http://tools.ietf.org/html/draft-ietf-6lowpan-hc-08
>
> The document is intended to be submitted by this Working Group to the
> IESG for publication as a Standards-Track Document.  Note that the
> document updates RFC 4944: please pay careful attention to section 2
> (this approach is not a change to the previous WGLC, though).
>
> This is a one-week Working-Group Last-Call, ending on 2010-08-09
> (Monday, August 09, 2010) at 2359 UTC.
>
> Please review the document carefully (one last time), and send your
> comments to the 6lowpan list.  Please also indicate in your response
> whether or not you think this document is ready to go to the IESG.
>
> Carsten and Geoff
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>   
-- 

____________________________________________
Paul Chilton, Head of Software Innovation
Low Power RF Solutions (formerly Jennic Ltd)
NXP Semiconductors NV
Furnival Street, Sheffield, S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371   Registered In England
http://www.nxp.com     http://www.jennic.com
____________________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Aug 2010 13:48:10 +0200

Hi Paul:

This issue is addresses amongst
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover
y-07 .

The draft also addresses fragment forwarding in route over and fragment
recovery.

It is probably time to make a WG decision on whether we take the work
item or not.

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Chilton
Sent: Monday, August 09, 2010 11:01 PM
To: Carsten Bormann
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for
draft-ietf-6lowpan-hc-08

Carsten Bormann wrote: 

LoWPANners,

 

 
 
Carsten and Geoff

--

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Aug 2010 11:59:13 +0200

I have reviewed HC-08.  The review comments are attached.  
(Everything not indented by 8 spaces is my comment.)

As the review comments mix a few detailed editorial with very few substantive technical comments, let me quickly identify the more important latter ones in my message:

-- Elision of Padding in IPv6 option headers needs to be specified in such a way as to make sure that the immutability required of IPv6 padding options is preserved.  In essence, this means that only well-formed trailing padding can be elided, because only that padding can be reconstructed reliably.  This is not much of a technical change in practice, as well-formed padding should be the norm, but it is important to call out.

-- I think the NH=0 for EID=7 should be a MUST.  There is no value in leaving this open.

-- We need IANA considerations for the NHC byte.

Also, the editorial comments I have made should clarify the issues raised in Reddy's comments.
(They are editorial for me, but may be technical if someone had a different understanding.)

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 21 Aug 2010 12:12:22 +0100

Hello,

I could have sworn the following was brought up by someone else, but I
couldn't find it now, so wanted to make sure it was mentioned:

When using stateful compression for 16-bit inline, the description of how to
generate the address is:
	
	The address is derived using context information
      and the 16 bits carried in-line.

If the context is shorter than 112 bits, how do you fill in the remaining?
It can either be specified as filling with zeros, filling with :ff:fe00:, or
simply out of scope for this document.

I would vote for either filling with :ff:fe00: (unline with stateless
compression), since it results in the most efficient usage when forwarding
IPv6 packets, or leaving as out of scope.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: August 19, 2010 10:59 AM
To: 6lowpan 6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08

As the review comments mix a few detailed editorial with very few
substantive technical comments, let me quickly identify the more important
latter ones in my message:

-- Elision of Padding in IPv6 option headers needs to be specified in such a
way as to make sure that the immutability required of IPv6 padding options
is preserved.  In essence, this means that only well-formed trailing padding
can be elided, because only that padding can be reconstructed reliably.
This is not much of a technical change in practice, as well-formed padding
should be the norm, but it is important to call out.

-- I think the NH=0 for EID=7 should be a MUST.  There is no value in
leaving this open.

Also, the editorial comments I have made should clarify the issues raised in
Reddy's comments.
(They are editorial for me, but may be technical if someone had a different
understanding.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 21 Aug 2010 14:58:15 +0200

On Aug 21, 2010, at 13:12, Colin O'Flynn wrote:

> I could have sworn the following was brought up by someone else

Indeed, I read Joseph's message the same way.

I suggested some text to Jonathan to remedy this; Jonathan has prepared a -09 based on the WGLC comments that I think he will submit any day now.

Gruesse, Carsten

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 23 Aug 2010 09:06:32 +0100

Colin,

It was brought up at the last Zigbee IP test event.  Within Zigbee, 
several vendors are already using a 64 bit context, 16 bit MAC and 
filling in the gap with FF:fe00.  I think it would be good to document 
this case explicitly in the HC-08 specification.  It is more efficient 
than using a 112 bit context because only 64 bits of context need to be 
sent in the 6LowPAN-ND message.

Daniel.

Regards,

Daniel.

-- 

__________________________________________________

Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.)
NXP Semiconductors
Furnival Street, Sheffield, S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371 - Registered In England
http://www.nxp.com http://www.jennic.com
__________________________________________________

---

From: Peter Bigot <[email-masked]>
Date: Mon, 23 Aug 2010 09:17:46 -0500

When I first read the HC drafts, I interpreted "context" to permit
external knowledge, such as the fact that context 7 that I used it
told me to construct the IPv6 address from a locally stored constant
that was not part of any ND message.  Whether to pad with zeros or
with FF:FE000 smells like this sort of external knowledge.

Will it be required that padding be done this way for a 64-bit context
and 16-bit short address, or merely allowed?  Is padding-with-zeroes
as an equally valid interpretation of the context?  Does this freedom
to interpret apply to other context lengths where the prefix length
plus the address length does not equal 128?

Can I say that context 7 in a network I control means ignore any
provided prefix and use a hard-coded constant 112-bit prefix, if I
have some reason to believe this makes sense in my deployment
environment?

Peter

On Mon, Aug 23, 2010 at 3:06 AM, Daniel Gavelle
<[email-masked]> wrote:
> Colin,
>
> It was brought up at the last Zigbee IP test event.  Within Zigbee, several
> vendors are already using a 64 bit context, 16 bit MAC and filling in the
> gap with FF:fe00.  I think it would be good to document this case explicitly
> in the HC-08 specification.  It is more efficient than using a 112 bit
> context because only 64 bits of context need to be sent in the 6LowPAN-ND
> message.
>
> Daniel.
>
> Colin O'Flynn wrote:
>>
>> Hello,
>>
>> I have reviewed HC-08.  The review comments are attached.  (Everything not
>> indented by 8 spaces is my comment.)
>>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 16:27:13 +0200

> with FF:FE000 smells like this sort of external knowledge.

Generally, we have tried for each context to take the form of a prefix (a number of bits plus that number).
More complex contexts are possible, but we'd also like to be able to distribute them using 6lowpan-ND.

> as an equally valid interpretation of the context?  

Not for the contexts I'm talking about.

> Does this freedom

Probably, but then you can't distribute that context using 6lowpan-ND.
Or, in other words, you can only use nodes that already have that knowledge.

Gruesse, Carsten