Re: [6tsch] Finalized charter

["JP Vasseur (jvasseur)" <[e-mail]>]

Hi Thomas,

On Aug 6, 2013, at 1:08 PM, Thomas Watteyne <[e-mail]<mailto:[e-mail]>> wrote:

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.


JP> Perfect.

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.


JP> Thanks because even if the node<->PCE interaction is not yet in the charter, and the same applies to
PCE discovery, ... the fundamental notion of PCE is part of the architecture. I understand that for now the
schedule is static but we still make use of some PCE architecture, that will unavoidably evolve to more
dynamic scenarios.

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.

JP> On that end, the ability for the PCE to "push" states (setup, update, ...) has been part of our rechartering
exercise with statefull PCE.


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.


JP> And this is perfectly fine; we could discuss of where such extensions could be discussed, I would be perfectly
happy with both WG reviews, as long as these items do not "impact" the protocol, in which case I'd rather see the
work in ROLL, reviewed by 6TSCH. But again, I do not see that as an issue, risk of overlap, ...

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.

JP> As far as I am concerned, it does answer the questions, I am VERY supportive !

Thanks.

JP.


Thomas


On Mon, Aug 5, 2013 at 5:18 PM, JP Vasseur (jvasseur) <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:

> On Aug 4, 2013, at 20:04, Ted Lemon <[e-mail]<mailto:[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]<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

_______________________________________________
6tsch mailing list
[e-mail]<http://ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch