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

[Kris Pister <[e-mail]>]

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]]
> *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] <mailto:[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]
>     <mailto:[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]  <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/6tsch
>
>
>     _______________________________________________
>     6tsch mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/6tsch
>