Re: [6tsch] Finalized charter

[Thomas Watteyne <[e-mail]>]

JP,
Wonderful, thanks for the quick answer and support.
Thomas


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

>  Hi Thomas,
>
>  On Aug 6, 2013, at 1:08 PM, Thomas Watteyne <[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]>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
>>
>
>  _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
>