Subject: [6tsch] splitting the 6tus draft?

From: Thomas Watteyne <[email-masked]>
Date: Thu, 16 May 2013 18:47:55 -0700

All,

We have been talking about splitting the 6tus draft a couple of times of
the last calls, and I know that the authors are also discussing this.

6tus will be a major contribution of the 6TSCH group, and I believe we
should be careful not to have a document which ends up encompassing too
many things. It's already pretty long as it is, and there is much more to
come.

In my mind, 6tus does 3 things:
- it manages hard cells, which is really just following commands sent by
the PCE.
- it manages soft cells, which includes a negotiation protocol between
neighbor nodes.
- it can do GMPLS-like switching if the corresponding tracks/label are
installed.

With these assumptions, we could split the 6tus draft into the following:
- "6tus specification", which is the current draft, minus
the negotiation protocol, and plus the commands to manage the label
switching. This would be a pretty "dry" draft, which mainly lists the
commands to interact with 6tus, and modules inside.
- "6tus for centralized scheduling", which indicates how the 6tus layer is
to be used in the presence of a PCE. This relates heavily to the (future)
draft which details the protocol between the PCE and the nodes.
- "6tus for distributed scheduling", which indicates how the 6tus layer is
used in the distributed case. The big part here will be
the negotiation protocol between neighbors.
- "6tus support for label switching". This is independent from the previous
2, and details how 6tus handled switching a packet along a specific track.

I will prepare a handful of slides so we can discuss this on the phone
tomorrow. *Qin*, *Xavi*, you are the two first authors of this draft. If
you cannot attend the call, could you please make sure to post your
thoughts about this on the ML so we can discuss those during the call?

Thanks,
Thomas

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 17 May 2013 01:44:47 -0700

Thomas,

Sorry, I can not attend Friday's meeting, because I'm still in Beijing.

Basically, I agree with you to split 6tus into the four parts you listed.
Just have the following two comments.

1) "6tus specification" should includes "initial network formation", i.e.
the manner to join existing network, because it is common for all of the
other three parts (centralized, distributed, and label switching).

2) Besides the main functions you listed, the current version of 6tus also
describes Statistics and Maintenance. I'm not sure where they should be.

Thanks
Qin

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 May 2013 09:07:27 -0400

>>>>> "Thomas" == Thomas Watteyne <[email-masked]> writes:
    Thomas> We have been talking about splitting the 6tus draft a couple of times of
    Thomas> the last calls, and I know that the authors are also discussing this.

    Thomas> 6tus will be a major contribution of the 6TSCH group, and I believe we
    Thomas> should be careful not to have a document which ends up encompassing too
    Thomas> many things. It's already pretty long as it is, and there is much more to
    Thomas> come.

Keep it to one document until the BOF.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [