Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Robert:

I'm in sync with you now. I will apply the changes that you suggest.
And yes, I was confused between MH and RH, and I need to add the deep hops to the MH description.

Finally, for the fence discussion, we try to avoid it by saying that both are legal but not in a same network, so we are creating exclusive features but not deprecating them.
I know it's a trick, but that's supposed to help the transition for those who wish to transition at all.

Thanks for this!

Pascal


> -----Original Message-----
> From: Robert Cragie [mailto:[e-mail]]
> Sent: mardi 2 décembre 2014 12:16
> To: Pascal Thubert (pthubert); [e-mail]
> Cc: Routing Over Low power and Lossy networks; [e-mail]
> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-routing-
> dispatch-00.txt
> 
> Hi Pascal,
> 
> Comments inline.
> 
> Robert
> 
> 
> On 02/12/2014 3:31 PM, Pascal Thubert (pthubert) wrote:
> > Hello Robert:
> >
> > I agree with you. This  is exactly the dilemma. But I do not read your own
> advice in there?
> <RCC>The point I was trying to make is that whilst there may be a case
> for changing something in an incompatible way due to "limited
> deployment", it is a) hard to draw the line at what "limited" means and
> b) it's sets a precedent for a specification to change further in the
> future. Whilst I accept that progress is inevitable, it is
> counterproductive if it happens too quickly. So what I was asking in
> essence was which side of the "limited deployment" line do people see
> the use of the mesh header? I confess I am sitting on the fence at the
> moment.</RCC>
> >
> > For your questions on the draft:
> >
> >> Also a comment re. section 8, I think the 'I' field needs to be 1, as
> >> 'Size' represents the HopsLft field, not the size of the header.
> > I think you got it reversed. ' I' set is the can-ignore case where the size in a
> length in bytes to be skipped if not understood.
> >
> > The text says:
> > "If the I Flag is set, the Size / Format field contains the Length of the 6LoRH
> expressed in bytes."
> >
> > Which  means
> > (I ==0 ) => "Size field contains length in bytes"
> >
> > So
> > "the Size field does not contain the Length in bytes" => (I=0)
> <RCC>Yes, I did get it wrong. I do think the description of the 'I' bit
> could be clearer. For example, why not describe the two cases like this:
> 
>         0                   1
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ..........    +-+
>        |1|0|0|   TSE   |    Type       |                      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ..........    +-+
>                                         <-- Implied length -->
> 
> 
> where 'TSE' means 'Type specific extension', which is described in each
> case of type and the length is either implied or explicitly stated after
> the type field. The other case is:
> 
>         0                   1
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ....    +-+
>        |1|0|1| Length  |    Type       |                |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ....    +-+
>                                         <--  Length  -->
> 
> 
> which is the length case, which can be skipped by implementations that
> do not understand the type. 'Size' and 'length' are terms that are too
> similar in my opinion.
> </RCC>
> 
> >
> >
> >> It also doesn't seem to cover the Deep Hops Left concept in RFC4944.
> > The ' Deep Hops Left ' comes from a structural limitation of the mesh header in
> RFC 4944, which encodes a hops left. No such thing here.
> > The idea is that you place as many consecutive RH3-6LoRH as you need.
> <RCC>We are talking about MH-6LoRH not RH3-6LoRH, aren't we? Hops left
> can also be more than 6 bits? Perhaps an illustration would help.</RCC>
> >   This is how we do not max out the number of hops, and also how we handle
> the various sizes of compressed addresses. But agreeably, we need to provide
> more details on address compression and how the header is stripped hop by
> hop.
> > Which we will do as a group if we take the 6LoRH path, but would be a waste
> of time if the group rejects this approach overall.
> >
> > Thanks for your comments : )
> >
> > Pascal
> >
> >
> >> -----Original Message-----
> >> From: Robert Cragie [mailto:[e-mail]]
> >> Sent: lundi 1 décembre 2014 19:17
> >> To: Pascal Thubert (pthubert); [e-mail]
> >> Cc: Routing Over Low power and Lossy networks; [e-mail]
> >> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-
> routing-
> >> dispatch-00.txt
> >>
> >> Hi Pascal,
> >>
> >> I agree that with hindsight it could be considered a bit greedy of
> >> RFC4944 to allocate 1/3 of the dispatch code space to the mesh header
> >> (especially when the definition of it itself is questionable) but what
> >> you are advocating is a replacement, not a framework extension. RFC6282
> >> only deprecated an ESC code, i.e. something which had not yet been used,
> >> which is not quite the same. This effectively makes this at best a new
> >> version of 6lowpan (which is difficult to distinguish) or at worst
> >> arguably a whole new protocol.
> >>
> >> Whilst hindsight is a wonderful thing, it can lead to the situation
> >> where a standard never stands still and keeps evolving. This makes it
> >> very difficult to develop products as there is always the fear that
> >> something will change the next year. Upgrading products is often quite a
> >> difficult process, especially in the case where there could quite
> >> feasibly be thousands of deployed devices which may have limited upgrade
> >> capability.
> >>
> >> I would like to hear what other people think about this.
> >>
> >> Also a comment re. section 8, I think the 'I' field needs to be 1, as
> >> 'Size' represents the HopsLft field, not the size of the header. It also
> >> doesn't seem to cover the Deep Hops Left concept in RFC4944.
> >>
> >> Robert
> >>
> >> On 27/11/2014 2:03 PM, Pascal Thubert (pthubert) wrote:
> >>> Dear all:
> >>>
> >>> This is a response to the question about the compression of RFC 6553 on
> top
> >> of RFC 6554.
> >>> It seems exaggerated to consume a dispatch type for the RPL option only.
> >>> But here, we introduce a routing header which is the equivalent of the mesh
> >> header in RFC 4944; we propose a compressed TLV format that can encode
> RH3,
> >> RPL option, IP-in-IP, and is further extensible, for instance for upcoming
> BIER.
> >>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable
> >> space for application only in Mesh-under.
> >>> This draft reuses that space in Route-over with the assumption that Route-
> >> over will not co-exist in a sma enetwork with Mesh-under encoded in the RFC
> >> 4944 fashion.
> >>> If there is effectively a need for co-existence, devices have to implement
> the
> >> new Mesh-under format that is also proposed in the draft.
> >>> Comments welcome,
> >>> Pascal
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]]
> >>> Sent: jeudi 27 novembre 2014 14:36
> >>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutain;
> >> Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
> >>> Subject: New Version Notification for draft-thubert-6lo-routing-dispatch-
> >> 00.txt
> >>>
> >>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt
> >>> has been successfully submitted by Pascal Thubert and posted to the IETF
> >> repository.
> >>> Name:		draft-thubert-6lo-routing-dispatch
> >>> Revision:	00
> >>> Title:		A Routing Header Dispatch for 6LoWPAN
> >>> Document date:	2014-11-25
> >>> Group:		Individual Submission
> >>> Pages:		19
> >>> URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-routing-
> >> dispatch-00.txt
> >>> Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-routing-
> >> dispatch/
> >>> Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch-
> 00
> >>>
> >>>
> >>> Abstract:
> >>>      This specification provides a new 6LoWPAN dispatch type for use in
> >>>      Route-over and mixed Mesh-under and Route-over topologies, that
> >>>      reuses the encoding of the mesh type defined in RFC 4944 for pure
> >>>      Mesh-under topologies.  This specification also defines a method to
> >>>      compress RPL Option (RFC6553) information and Routing Header type 3
> >>>      (RFC6554), an efficient IP-in-IP technique and opens the way for
> >>>      further routing techniques.  This extends 6LoWPAN Transmission of
> >>>      IPv6 Packets (RFC4944), and is applicable to new link-layer types
> >>>      where 6LoWPAN is being defined.
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>> The IETF Secretariat
> >>>
> >>> _______________________________________________
> >>> 6lo mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/6lo
> >>>
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6lo
> >
>