Pascal,
I would correct the time [16:57] for [7:57].
Regards,
Diego
2015-11-27 13:43 GMT-03:00 Pascal Thubert (pthubert) <[email protected]>:
> Note: timestamps in PST.
> Connection details
>
> - Date: 7-8AM Pacific
> - Webex link:
>
> https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a
> - Webex Recording:
>
> https://cisco.webex.com/ciscosales/lsr.php?RCID=593dfc3212814becb59dd237f7804d5b
> - Wiki: https://bitbucket.org/6tisch/meetings/wiki/150925_webex
> - Slides:
>
> https://bitbucket.org/6tisch/meetings/src/master/151127_webex/slides_151127_webex.ppt
>
> Taking notes *(using Etherpad)*
>
> - Diego Duvojne
> - Thomas Watteyne
> - Michael Richardson
> - Pascal Thubert
> - Tengfei Chang
>
> Present *(alphabetically)*
>
> 1. Thomas Watteyne
> 2. Pascal Thubert
> 3. C-Y Lee
> 1. Call-in User_4 (did)
> 4. Diego Dujovne
> 5. Jonathan Munoz
> 6. lavanya (didn't identify him/herself)
> 7. Malisa Vucinic
> 8. Michael Richardson
> 9. Michel Veillette
> 10. Nicola Accettura
> 11. Pat Kinney
> 12. Sedat Gormus
> 13. Tengfei Chang
> 14. Xavi Vilajosana
> 15. Zhuo Chen
>
> Action Items
>
> - Pascal to publish Architecture draft update
> - Xavi to pubish Minimal draft update
> - Chairs to propose new charter to responsible A-D (Brian)
> - Thomas to push adoption e-mails to the 6TiSCH ML
> - Zhuo to kick a ML discussion on whether P2P routing and HbH
> scheduling apply to IP forwarding, G-MPLS, or both
>
> Agenda
>
> - Administrivia *[2min]*
> - Approval agenda
> - Approval minutes last call
> - Charte Update *[15min]*
> - Minimal Support: status *[15min]*
> - Architecture: status and directions *[15min]*
> - 6lo drafts (BBR and 6LoRH) *[10min]*
> - AOB *[1min]*
>
> Minutes
>
> · *[07.??]* Meeting starts Agenda change: Propose Xavi to start
> first. No opposition, approved. Minimal is first.
>
> · [07.06] Minimal Support: status *[15min]*
>
> - large list of issues created in bitbucket
> - last issue (#3) needs to be discussed
> - Xavi goes through summary of all changes. Made changes following
> the recommendation from the reviewers
> - editorial changes
> - changes to RPL
> - what happens if the network is not multi-hop
> - intended status: no
> - [Michael] no intended surveys, but BCPs ("profile") say that,
> "when using protocol X in context Y, you SHOULD use parameters Z". This
> is
> for operators rather than implementors. Minimal says you to use RPL,
> which
> you would not implement if you were just using IEEE802.15.4e. AD asked
> whether this will be used beyond a plugtest.
> - [Pascal] node requirements for IPv6 is informational, it does not
> mandate behaviors. Just information about the mote; but doesn't use
> "MUST".
> Minimal draft does say you need to compute the RPL rank according. That
> draft is what this is specified, so it's not just setting parameters.
> Think
> we are beyond informational.
> - [Malisa] agreed with Pascal & Michael, would make sense to
> publish as standards track. The DTLS profile that is a similar scope, is
> intended to be published as standards track.
> - [Michael] RFC6434 list RFCs that you are expected you should look
> at. RFC6434 should not have been informational. Strictly speaking,
> informational are not standards.
> - [Michael] we have a BCP number, but no informational numbers.
> - [Thomas] Consensus on Standards track. How do we proceed? We are
> building on top of it Default setup on top of it.
> - [Michael] A good answer. We have not articulated that.
> - [Thomas] It is important to publish this. Standard track. RPL
> rank no anywhere else. This is the spec.
> - [Pascal] Nobody wants informational, better standard track.
> Recommendation for developers than for deployers.
> - [Thomas] Discuss on the ML.
> - [Pascal] To get an RFC number, highly respected. Already
> implemented, tested.
> - [Thomas] Anything else? X: Publish it.
> - [Thomas] Send it to the ML and send a note.
> - [Pascal] Copy the link to the diff to see the changes. Thanks.
> Great work.
> - [07.25] Charter Update *[15min]*
> - [Pascal] Starts discussion on Charter. We are closing
> Architecture and Minimal. Plan: Architecture and Minimal published,
> start a
> new charter.
> - [Pascal] Charter: Is a contract with the IESG, 5 elements. 6top
> sublayer, 6top protocol. Lots of work on IEEE, there is a 6tisch
> interest
> group. The plan is go to standards track and then go to IEEE for next
> gen.
> Second item: Scheduling Function. We intend to keep SF at the IETF. SF0
> standards track too. Tracks on discussion on Detnet. Secure Bootstrap on
> the ML, keep it up. Architecture next step. Take the work back to the
> WG,
> wait until completed the WG and publish it.
> - [07.30] Architecture: status and directions *[15min]* Terminology
> tickets: 38 and 39. Update the link on Architecture. Next step to publish
> -09 and then discuss on the ML and work on the tracks. The architecture is
> built on too many pieces. Capture more detailed information, can be on the
> specification level. Hop-by-hop scheduling: we did not really work on it,
> we have seen interest on it, Chonggang provided help. Make tracks work.
> Fragments forwarding listed on Archie forever, either work on it or live
> without it. Clarified dependencies. More explicit on dependencies.
> - comments from Kris is that we have different ways of doing
> forwarding, routing and scheduling. This turns into many combinations,
> which is complicated.
> - proposal is to select a small number of combinations
> - Pascal talks about the different forwarding models (slide 20)
> - we now have IPv6 forwarding+RPL+static
> - we are now working on now have IPv6
> forwarding+RPL+neighbor-to-neighbor (SF0)
> - we have work in front of us with reactive P2P (RPL P2P or AODV
> v2)/ Charlie Perkins has indicated he might be interested in working
> on
> reactive P2P. That's a great fit with hop-by-hop scheduling.
> - question is whether we want to classical IPv6 forwarding.
> - Pascal indicates this table locks the number combinatorial
> combinations. This table is the proposal. That table is in the draft.
> - [Zhuo] saw that in the routing there is PCE.
> - [Pascal] PCEP is the protocol to install routes. PCE is the
> component which calculates the routes. Route computation happens inside
> the
> PCE. Forwarding happens in the devices. In centralized, the control
> plane
> centralized in the controller. In RPL, the routing is distributed. PCE
> is
> not a protocol. What would you like in that box? At this stage we don't
> have an idea what the protocol is.
> - [Zhuo] In my mind, thinking about track with hard cells. Track
> with soft cells. Something in future is track configured by the node.
> - [Pascal] that's what we have put in the lowest row the HbH
> scheduling will allocate soft cells.
> - [Zhuo] can that be a track?
> - [Pascal] had that discussion with Thomas, it's our decision.
> - [Pascal] alternatives:
> - we install the HbH in the routing table, or we use track
> forwarding in this table. Decision was not made yet. Proposal is to
> keep
> IPv6 forward. We are nowhere on the GMPLS way. If we want to go
> quickly to
> market. Let's take that to the ML.
> - action item: Zhuo to start a discussion on the ML
> - [Zhuo] OK
> - [Thomas] +1 on the table. Great overview of the roadmap. When
> will be published.
> - [Pascal] submit -09 now, but pushed to IESG very late in the
> process
> - [Pascal] RFC4861 is clearly designed not work in NBMA case. This
> is the case of the 6TiSCH mesh. Ralph asked us to work on this.
> - [Thomas] second idea to publish it ASAP.
> - [16.57] WG adoption calls on both drafts, we need to answer that
> call to weight on the adoption. This is very important for the work we do
> at 6TiSCH.
> - BBR is what we have in our architecture
> - 6lo routing dispatch is what we need to compress RPL. 6TiSCH has
> been complaining about that. 6lo is ready to adopt this compression
> mechanisms.
> - [Thomas] please send the initial call e-mails to
> - Action item: Thomas to push adoption e-mails to the 6TiSCH ML
> -
> - *[08.??]* Meeting ends
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
