Re: [6tsch] Finalized charter

[Thomas Watteyne <[e-mail]>]

JP, Carsten,

Thanks for the very valuable input on the charter. Let me try to summarize
your comments and provide an answer to the issues you raise below.

*BBR->LBR*

*Suggestion from JP. Changing BBR to LBR would align terminology with the
ROLL WG.*

For reference, here are the definitions in the latest versions of the
drafts:

   - *LBR* (draft-ietf-roll-terminology-12): Low power and Lossy Network
   Border Router.  The LBR is a device that connects the Low power and Lossy
   Network to another routing domain such as a Local Area Network (LAN), Wide
   Area Network (WAN) or the Internet where a possibly different routing
   protocol is in operation.  The LBR acts as a routing device and may
   possibly host other functions such as data collector or aggregator.


   - *BBR* (draft-thubert-6lowpan-backbone-router-03): An IPv6 router that
   federates the LLN using a Backbone link as a backbone. A BBR acts as a
   6LoWPAN Border Routers (6LBR) and an Energy Aware Default Router (NEAR).


These are indeed very close terms. Whatever the name, I believe we are
talking about an entity which plays several roles, including handling
downstream routes where applicable (RPL), compacting 6LoWPAN header
(6LoWPAN), and federating several LLNs under one prefix (ND). As usual,
these functions can be co-located in the same box.

While I don't have a strong opinion on this, I tend to agree that LBR is a
more established term than BBR, and maybe a bit more generic according to
the definitions above.

Yet, we have already sent the proposed charter to the ADs for review. What
I have done is filing
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/5/bbr-lbr, to keep
track of your suggestion. We can integrate it if requested during future
discussion about the charter with the IESG.

*Add PCE to WG to interact with*

*Suggestion from JP. The idea is to list PCE as a WG to interact with.*

The reason we did not include it in the text is because the definition of
the node<->PCE interaction is not within scope of this charter. Work item 1
covers the format of the payload (e.g. the bits and bytes to describe a
cell), but not the exact transport solution or interaction.

That being said, this is absolutely what we tend towards, and when we
explicitly work on that, we will be interacting with the PCE WG. I
understand you are suggesting to list PCE right away. I have filed
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/6/add-pce-to-wg-to-interact-with
 to cover this.

*Interaction between Work Item 1 and 2*

*Clarifying question from Carsten.*

The goal of work item 1 is to describe a format for the PCE to be able to
send commands to the nodes, and for the nodes to send statistics and
topological information to the PCE. In this version of the charter, we
assume that the schedule is static, i.e. we do not address the PCE->nodes
traffic yet. That being said, statistics and topological information can
flow from node to PCE in a network resulting from work item 2. This for
example allows for close monitoring of the health of the network.

That being said, the scope of work item 1 is very clear and very "atomic".
Management includes setup, update, tear down, as well as getting reports.
The scope of work item 1 is not to focus on "network management" as a
whole, only to produce formats and methods that can be used by all points
of command, including PCE, node configuration, network management, etc.

*hard-coded -> pre-configured*

*Suggestion from Carsten.*

The term "pre-configured" is indeed more elegant than the term
"hard-coded". Would you agree, however, that both terms end up expressing
the same idea? I have filed
https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/7/hard-coded-pre-configured
to
track and remember this suggestion.

Note that there is an intent that we provide a basic schedule that would
operate without any configuration. Then through the methods in item 1 we
propose to optionally set up an initial schedule that the node will use
instead.

*changing RPL?*

*Clarifying question from Carsten.*

The goal of the work at 6TSCH is absolutely not to change RPL, just to
describe how RPL can be be used on these time slotted networks. This is
probably going to be the biggest piece of the work done in work item 2.
What we might do is define some metrics and maybe even an OF, but NOT to
request any changes to RPL itself.

I would argue that, if the goal were to change RPL, this would appear
clearly in the charter text. In the absence of the statement "we want to
change RPL", we assume that the reader understands that the goal is to not
change RPL. We may study objective functions and new options, in particular
to transport a schedule, but we are not chartering to standardize work
there.

*security in scope?*

*Clarifying question from Carsten.*

We have had numerous discussion about this last week, including in-person
with Yoshihiro, Subir, Rafa, and by e-mail with Rene. I believe we had a
very similar discussion with Rene, which you can find at
http://www.ietf.org/mail-archive/web/6tsch/current/msg00985.html. Rene
agreed with the discussion.

In very short, work on security and management is welcome but we do not
charter a work item for this round.

I hope this answers your questions.

Thomas


On Mon, Aug 5, 2013 at 5:18 PM, JP Vasseur (jvasseur) <[e-mail]>wrote:

> Agree with Carsten and Pascal, I would stick to LBR and mention PCE
> specifically
>
> On Aug 5, 2013, at 1:54 AM, Carsten Bormann <[e-mail]> wrote:
>
> > On Aug 4, 2013, at 20:04, Ted Lemon <[e-mail]> wrote:
> >
> >> The normal pronunciation of this acronym at least in German
> >
> > For a German: TSCH = Tisch = "tish".
> > Add "six" (english pronunciation), and it's "sixtish".
> > Not too hard.
> >
> > On the charter itself: I was rather skeptical about the version we
> discussed in Berlin, and I'm now less worried.
> >
> > I don't quite understand the text for work item 1.  Why is this about
> querying (which I would have expected in a garden variety management
> protocol) and not about setting up?  Maybe I don't understand the
> relationship between 1 and 2.
> >
> > Work item 2: s/hard-coded/pre-configured/?
> >
> > I would probably stick with the "LBR" terminology as others have said.
> >
> > We may need to discuss how the multi-LBR technology in 6TSCH (ND-proxy?)
> relates to that potentially addressed by 6Lo.  Since I don't think we will
> fully understand the relationship before the charters get finalized, maybe
> just note that in the charter.  (Maybe it is also worth highlighting any
> working relationship with ROLL, if that is required.  Is RPL being modified
> by 6TSCH?)
> >
> > The charter currently does not discuss security or management, and I
> would prefer a clear statement whether that is in scope (re management, see
> comment about work item 1 above; security for bootstrapping a network is a
> complex issue where it would surprise me if people think this is in scope).
> >
> > Grüße, Carsten
> >
> > _______________________________________________
> > 6tsch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6tsch
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>