Re: [6tsch] What is missing slides -- input needed

[Xavier Vilajosana Guillen <[e-mail]>]

Thanks Pascal, your detailed description makes things more clear now. I
will work on the slides so they guide us through this outline.

cheers!
Xavi


On Wed, Jul 17, 2013 at 8:23 AM, Kris Pister <[e-mail]> wrote:

>  I agree with everything that Pascal wrote.
>
> ksjp
>
>
> On 7/17/2013 2:42 AM, Pascal Thubert (pthubert) wrote:
>
>  Hello Xavi:****
>
> ** **
>
> You can expect that people before you (Thomas for his draft and Maria Rita
> for 1.a) will have described the value of deterministic networking, the
> capabilities (and limits) of deterministic wireless, and the applications
> that will benefit from IPv6 over TSCH. So you’ll be facing a crowd that
> already has a sense of a huge value for the real world, even for everyday
> life.****
>
> ** **
>
> Your item 5 is the core of the question you are treating. I think that
> should be most of your time. At the end your 15 minutes, people must also
> be convinced that there is work to be done, understand what the scope of
> that work is, and that it is achievable within IETF classical operations.
> Your list for item 5 is perfectly in line with my thinking. I’d just add
> security and in particular commissioning and join process. You may want to
> use the architecture blocks or a subnet diagram as illustrations.****
>
> ** **
>
> People should have gotten your item 1 in the welcome message from the
> chairs. As an intro, I’d insist that we aim at enabling new applications
> such as automation and metering over a converged IP network, for the
> well-known benefits that we found converging voice and video.****
>
> For item 2: It seems to me that the following sub-items are not
> controversial and position the missing links:****
>
> - existing standards found in smartgrid for metering use IETF building
> blocks but are not designed to operate on TSCH => missing deterministic
> aspect****
>
> - existing TSCH-based standards found in industrial are not compatible
> with one another => double OPEX, customer unsatisfaction****
>
> - they have their own versions of protocols and elements that the IETF
> defines (PCE/P, ICMP, DHCP, PANA, DTLS …) => missing the benefits of
> sharing those building blocks****
>
> - but do not support other required functionalities that are available
> with IETF protocols (RPL, ND, CoAP..) => missing distributed routing ****
>
> All in all, the lack of IETF building block hinders the network
> convergence that we are after.****
>
> I’d place your item 4 before your item 3, In there, you probably want to
> indicate that each of the existing solutions address a subset of the
> problem but that we want a single converged solution, in particular with a
> mix of centralized and distributed path computation, and a mix of track
> forwarding and routing. ****
>
> ** **
>
> At the end of item 4 (now 3), the audience would have a nice view of the
> landscape of existing -deployed- work as a side effect. This can be used to
> justify the bottom line of your item 3, clarifying that compared to what
> was already achieved and validated, what we are talking about is mostly the
> cement as opposed to the building blocks. This gives you an excellent intro
> for item 5, and you should be there around ETA = 5 minutes. ****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Notes:****
>
> ** **
>
> In the thread we discussed that we do not want to use the term
> proprietary, so as to avoid an inappropriate tension and jitter.****
>
> ** **
>
> Existing protocols, the fact that the concept validation and a large chunk
> of the technical engineering were done already, will be revisited in other
> sections, in particular 2a and 2b. So you can make a forward reference. So
> please save your time on those.****
>
> ** **
>
> ****
>
> ** **
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Xavier Vilajosana Guillen [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* mercredi 17 juillet 2013 02:04
> *To:* [e-mail]
> *Cc:* Kris Pister; Thomas Watteyne; Pascal Thubert (pthubert)
> *Subject:* Re: [6tsch] What is missing slides -- input needed****
>
> ** **
>
> Hi Kris, Pascal, all,
>
> some of the ideas drawn on this discussion are confusing me, sorry!. I
> like to be very synthetic and write the main points as I have on my mind:*
> ***
>
> 1-we aim to define how to run IPv6 on IEEE 802.15.4e TSCH.****
>
> 2-An analogy of our work can be found on ISA100.11a and WiHART approaches
> although the flavor is different as they don't use IETF building blocks. In
> fact these blocks have not been though for IEEE 802.15.4e, so while people
> may think the work is done, that is not case -- and this goes against our
> work as we need to convince as well--****
>
> 3-For our case, the blocks we need to use already exist (zigbee IP,
> etc...) however the guidelines on how/what exactly glue together are *
> missing*.****
>
> 4-The latest made vendors to implement their own variations of these
> blocks that limit open-inter-operability or at least make it harder. ****
>
> 5-Our aim therefore is glue all together and glue it with the IP
> architecture including what is on the backbone (ND, etc..)****
>
>     The main points that need to be glued together are:****
>
>          -Scheduling construction and maintenance:****
>
>                      -Centralized vs distributed: support for both****
>
>                      -Protocols to distribute the information: Based on
> PCE architecture or distributed (RSVP like)****
>
>           -QoS and TE due to the cell nature of the underlying MAC layer
> (including priorities, Traffic Classes, etc..)****
>
>           -RPL on TSCH, routes and best effort vs deterministic tracks:
> support to mobility and fast commissioning****
>
>           -Security, key distribution, EB security****
>
>           -ND and backbone architecture****
>
>           -Packet switching and tunneling****
>
>           -management and maintenance of TSCH, seen as an orchestra
> director based on underlying TSCH information (6top)****
>
>
>
> do I miss any points? :-)****
>
> ** **
>
> thanks!****
>
> Xavi****
>
> ** **
>
> ** **
>
> are these points covering the topic? What else I'm missing. ** **
>
> ** **
>
> On Tue, Jul 16, 2013 at 2:56 AM, Pascal Thubert (pthubert) <
> [e-mail]> wrote:****
>
> Dear Kris and Xavi:****
>
>  ****
>
> Please see below.****
>
>  ****
>
> I agree with you on all of this.  ****
>
> [] Same here; I think that Xavi’s text is well-balanced. And we will not
> have time for controversies at the BoF so this discussion on avoiding them
> is critical.****
>
> We're trying to make a fully IETF/IEEE compliant standard, and there are
> definitely some missing blocks.  We can point to some industrial standards
> that have some similarities, to say "see, it can work really well, but they
> don't do us any good because they aren't based on IEEE 15.4e".
> Our goal is to tell people how to run IPv6 on 15.4e.  ****
>
> *[] *Yes, that is the primary goal. Hopefully the architecture that we
> are producing applies to all sorts of TDM-based LLNs. The key here is to
> leverage the new level of guarantees and services that Time Slotting
> enables. ****
>
>
> I just have a pet peeve about the IETF calling anything that isn't IETF
> "proprietary".****
>
> *[] *It’s true that IETF has its view of open standards that is useful
> for discussion within the IETF, but 1) your words are not true to that
> definition (see section 7 of RFC 2026) and 2) it is not just the IETF that
> redefines the term for its own use; it’s really all sorts of countries and
> organizations, often referring to the way the standard was elaborated and
> is made available, in particular with regards to fee policies, IPR rules,
> or open source implementations. Still I agree that this time and place are
> not for fighting on the definition of such terms. If the IETF term is not
> the right tool for our discussion then let us be more specific on why we
> can’t just live with a status quo. ****
>
> The existing protocols:****
>
> - are not fully compatible with IEEE 15.4e which came later****
>
> - are not compatible at all at any layer though similar on paper****
>
> - are not implemented as open source****
>
> - do not define all the required interfaces and protocols for operation
> over the Internet (e.g. interface to the WiHART AP or ISA100.11a backbone
> router operations over the backbone)****
>
> - have their own versions of protocols and elements that the IETF defines
> (PCE/P, ICMP, DHCP, PANA, DTLS …) and for which open source implementations
> are available****
>
> - do not support other functionalities that are available with IETF
> protocols (RPL, ND, CoAP..).****
>
> - … ?****
>
> Just like proprietary RPL implementations over TSCH, industrial standards
> demonstrate both the need and the feasibility of our work and show the way.
> ****
>
>
> And I don't think that we should try to point to WiHART and ISA100 and say
> "they are missing some blocks" because they are outside of our scope anyway.
> ****
>
> *[] *Agreed. At the same time, we need to explain why we’re not all set
> with what exists already on the market. We must make sure that we do not
> make it look like criticizing the excellent work that is really our
> foundation. On the contrary we want to strongly express that reuse all the
> concepts that those protocols have demonstrated but will base the devices
> interactions on existing IETF (open ; ) standards when possible.****
>
> Makes sense?****
>
> Pascal****
>
> On 7/15/2013 5:29 PM, Xavier Vilajosana Guillen wrote:****
>
>   thanks Kris, this makes sense. Last Friday on the phone call we kept
> semi-propietary "word" because there are some vendor specific blocks that
> although are defined do not match between different  vendors (e.g way
> schedule is distributed, at least in 15.4e). I think it is already defined
> in WHart and ISA100.****
>
> The points you raise here are *very important* as this is what some of
> the people that will be listening at the BoF will raise. So we have to be
> very sure and be very careful on how we present this.  The idea of that
> presentation is to outline what is missing and why we go for 6TSCH as a
> "glue" for all the blocks.
>
> so my comments inline:
>
> 1) they are based on TSCH, but not IEEE 802.15.4e TSCH.  4e did not adopt
> either WiHART or ISA100, rather we/it came up with its own way of doing
> things.
> agree.. I clarify that. I also clarify that we go for defining how this
> blocks are built on top of IEEE 802.15.4e. (right?)
>
> 2) I don't think that even the IETF gets to say that either of these
> protocols is semi-proprietary anymore.  they are both IEC standards, and
> they are interoperable across many vendors (of the wireless part).
> In the case of IEEE 802.15.4e networks,  what about centralized scheduling
> distribution or distributed scheduling. What about how security is
> installed at each node, what  about QoS maintenance (including
> overprovisioning, or cell reallocation). Maybe vendors inter-operate ( in
> ISA100 and WHART, not so sure in 15.4e), but are aiming to propose a common
> approach for that right?-- this is because the existing approaches (in the
> case of 15.4e) are vendor specific ... I guess this is what we want to show
> in the BoF, everything exists but we aim to find a common direction for
> everyone.
>
> 3) all of the blocks are defined, and there aren't any missing.  ****
>
> These are complete standards-based solutions, they just aren't based
> (completely) on IETF/IEEE standards.****
>
> well because some parts are not defined by IETF yet right? e.g messages on
> the air to schedule one link with a neighbour. ****
>
> X****
>
>  ****
>
>  ****
>
> On Mon, Jul 15, 2013 at 4:55 PM, Kris Pister <[e-mail]> wrote:***
> *
>
> Xavi -
>  regarding the existing industrial implementations of TSCH, I'd say things
> a little differently.
> 1) they are based on TSCH, but not IEEE 802.15.4e TSCH.  4e did not adopt
> either WiHART or ISA100, rather we/it came up with its own way of doing
> things.
> 2) I don't think that even the IETF gets to say that either of these
> protocols is semi-proprietary anymore.  they are both IEC standards, and
> they are interoperable across many vendors (of the wireless part).
> 3) all of the blocks are defined, and there aren't any missing.
> These are complete standards-based solutions, they just aren't based
> (completely) on IETF/IEEE standards.
>
> ksjp ****
>
>  ****
>
> On 7/15/2013 4:03 PM, Xavier Vilajosana Guillen wrote:****
>
>   Dear all,
>
> I am working on what is missing? presentation slides. I want to go deep on
> the description of the following points. From what we listed last webex I
> developed the content but I need further input. Please update the following
> points with your thoughts: (all ideas are welcome, I will filter later!)
>
>
> Deterministic wireless over TSCH is demonstrated and available but
> semi-proprietary (TSMP, ISA100.11a, WiHART)
>    - Vendors have semi proprietary solutions as there are some blocks
> missing:
>        -These blocks are mainly on the upper Data Link Layer and its
> integration with the network layer.
>        -These blocks are mainly for the management and operation of the
> network
>        -missing blocks limit interoperability and mass scale adoption of
> the technology
>        -...****
>
> (give me some feedback here please)****
>
>        ****
>
>
> Same for RPL/TSCH with scalability to *1000s
>    -Vendor specific RPL proved to scale to 1000s (need info about that
> please!)
>    -TSCH networks proved to scale to 1000s
>    -Missing junction between both. RPL on TSCH.
>    -....
>
> (give me some feedback here please)
>
> Most IETF components exist (ZigbeeIP)
>     - ZigBee IP Supports 6LoWPAN for header compression, IPv6, PANA for
> authentication, RPL for routing, and TLS and EAP-TLS for security, TCP and
> UDP transport protocols.
>      -the building blocks exist but need to be fit to TSCH nature. Slotted
> and deterministic MAC layer, mapping of RPL routes to TSCH schedules (that
> globally build tracks.) -- Coexistence of Tracks and routes.
>
> (give me some feedback here please)
>
>
> Missing IETF architecture to put it all together
>    - Pascal Picture from architecture draft.****
>
>    - Coexistence==Support of PCE/ Distributed in same architecture****
>
>
> (give me some feedback here please)****
>
> Thanks!
> Xavi****
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>   ****
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>  ****
>
> ** **
>
>
>