Subject: [6tisch] comments on latest terminology draft

From: "Turner, Randy" <[email-masked]>
Date: Mon, 18 Apr 2016 18:38:35 +0000

Hi Guys,

I had a couple of comments on the recent -07 terminology draft:

Deterministic Network - "A deterministic network can allocates..." should be "A deterministic network can allocate..."

"6top Data Convey Model" - Model describing how the 6top adaptation layer...<snip>
Is this really an adaptation layer? - In the IETF, the term "adaptation layer" has come to mean something different

6p Transaction - "Part of the 6top Protocol, in consists in" should probably be "...consists of"

"Bundle" - typo "usining" should be "using"

"Link" - When I read this description, it sounds similar to an interference domain - should the difference (if any) be spelled out or distinguished ? Or am I the only one that sees this similarity?

Thanks!
R.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Apr 2016 14:58:34 +0200

Randy,

I'll let Maria Rita comment about the typos, I assume it's just a matter to
spinning the doc.

About "link", I went back to read the draft. The following definition...

------------------
A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IP.  Thus, the IETF parlance for the
term "Link" is adopted, as opposed to the IEEE802.15.4e
terminology.  In the context of the 6TiSCH architecture,
which applies to Low Power Lossy Networks (LLNs), an IPv6
subnet is usually not congruent to a single link and
techniques such as IPv6 Neighbor Discovery Proxying are
used to achieve reachability within the multilink subnet.
A link is distinct from a track.  In fact, link local
addresses are not expected to be used over a track for
end to end communication.  Finally, from the Layer 3
perspective (where the inner complexities of TSCH
operations are hidden to enable classical IP routing and
forwarding), a single radio interface may be seen as a
number of Links with different capabilities for unicast
or multicast services.
---------------

... is confusing, to say the least. IMO, it touches on almost all of the
IETF work (talking about ND proxy, mutiling subnets, tracks in the
definition of link ?!?) , is incredibly confusing, and as a result carries
0 information. What about

A link exists between two nodes when at least one cell is schedule between
them.

Thomas

On Mon, Apr 18, 2016 at 8:38 PM, Turner, Randy <[email-masked]>
wrote:

> Deterministic Network - "A deterministic network can allocates..." should
> be "A deterministic network can allocate..."
>
>
>
> Is this really an adaptation layer? - In the IETF, the term "adaptation
> layer" has come to mean something different
>
>
>
> "Link" – When I read this description, it sounds similar to an
> interference domain - should the difference (if any) be spelled out or
> distinguished ? Or am I the only one that sees this similarity?
>
>
>
> Thanks!
> R.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Apr 2016 13:07:03 +0000

Randy, sorry for my late  answer.
Thomas, thanks for jumping into it.

Sure, the typos will be fixed in the next  version  ;)

About the definition of “link” I have to say this is  a  kind of endless story…
We have been discussed a lot in the past how to define it, how to make  clear that the concept for 6TiSCH is different from classical  IETF  link  definition,  but it seems we created  confusion, by putting  too  much information all together into  it.

Thomas’s suggestion could  simplify the problem.
The  link in fact  exists when the two neighbors have at least  one  cell to exchange pkts.

Thank you.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, April 22, 2016 2:59 PM
To: Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft

Randy,

I'll let Maria Rita comment about the typos, I assume it's just a matter to spinning the doc.

------------------

... is confusing, to say the least. IMO, it touches on almost all of the IETF work (talking about ND proxy, mutiling subnets, tracks in the definition of link ?!?) , is incredibly confusing, and as a result carries 0 information. What about

A link exists between two nodes when at least one cell is schedule between them.

Thomas

On Mon, Apr 18, 2016 at 8:38 PM, Turner, Randy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Guys,

"Link" – When I read this description, it sounds similar to an interference domain - should the difference (if any) be spelled out or distinguished ? Or am I the only one that sees this similarity?

Thanks!
R.

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

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Qin Wang <[email-masked]>
Date: Wed, 27 Apr 2016 14:58:17 +0000 (UTC)

Hi all,
Do we really need the term "Link"? IMO, "Link" in 6TiSCH is same as Bundle. Right?
ThanksQin 

    On Friday, April 22, 2016 9:07 AM, Maria Rita PALATTELLA <[email-masked]> wrote:

 #yiv5085214591 #yiv5085214591 -- _filtered #yiv5085214591 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5085214591 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5085214591 #yiv5085214591 p.yiv5085214591MsoNormal, #yiv5085214591 li.yiv5085214591MsoNormal, #yiv5085214591 div.yiv5085214591MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5085214591 a:link, #yiv5085214591 span.yiv5085214591MsoHyperlink {color:blue;text-decoration:underline;}#yiv5085214591 a:visited, #yiv5085214591 span.yiv5085214591MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5085214591 span.yiv5085214591hoenzb {}#yiv5085214591 span.yiv5085214591EmailStyle18 {color:#1F497D;}#yiv5085214591 .yiv5085214591MsoChpDefault {} _filtered #yiv5085214591 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5085214591 div.yiv5085214591WordSection1 {}#yiv5085214591 Randy, sorry for my late  answer. Thomas, thanks for jumping into it.    Sure, the typos will be fixed in the next  version  ;)    About the definition of “link” I have to say this is  a  kind of endless story… We have been discussed a lot in the past how to define it, how to make  clear that the concept for 6TiSCH is different from classical  IETF  link  definition,  but it seems we created  confusion, by putting  too  much information all together into  it.    Thomas’s suggestion could  simplify the problem. The  link in fact  exists when the two neighbors have at least  one  cell to exchange pkts.    Thank you. Maria Rita       From: 6tisch [mailto:[email-masked]]On Behalf Of Thomas Watteyne
Sent: Friday, April 22, 2016 2:59 PM
To: Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft    Randy,    I'll let Maria Rita comment about the typos, I assume it's just a matter to spinning the doc.    About "link", I went back to read the draft. The following definition...    ------------------ A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP.  Thus, the IETF parlance for the term "Link" is adopted, as opposed to the IEEE802.15.4e terminology.  In the context of the 6TiSCH architecture, which applies to Low Power Lossy Networks (LLNs), an IPv6 subnet is usually not congruent to a single link and techniques such as IPv6 Neighbor Discovery Proxying are used to achieve reachability within the multilink subnet. A link is distinct from a track.  In fact, link local addresses are not expected to be used over a track for end to end communication.  Finally, from the Layer 3 perspective (where the inner complexities of TSCH operations are hidden to enable classical IP routing and forwarding), a single radio interface may be seen as a number of Links with different capabilities for unicast or multicast services. ---------------    ... is confusing, to say the least. IMO, it touches on almost all of the IETF work (talking about ND proxy, mutiling subnets, tracks in the definition of link ?!?) , is incredibly confusing, and as a result carries 0 information. What about    A link exists between two nodes when at least one cell is schedule between them.    Thomas             On Mon, Apr 18, 2016 at 8:38 PM, Turner, Randy <[email-masked]> wrote: 
Hi Guys,   I had a couple of comments on the recent -07 terminology draft:   Deterministic Network - "A deterministic network can allocates..." should be "A deterministic network can allocate..."   "6top Data Convey Model" - Model describing how the 6top adaptation layer...<snip> Is this really an adaptation layer? - In the IETF, the term "adaptation layer" has come to mean something different   6p Transaction - "Part of the 6top Protocol, in consists in" should probably be "...consists of"   "Bundle" - typo "usining" should be "using"   "Link" – When I read this description, it sounds similar to an interference domain - should the difference (if any) be spelled out or distinguished ? Or am I the only one that sees this similarity?   Thanks!
R. 
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch 
   
    --  _______________________________________    Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH    www.thomaswatteyne.com _______________________________________ 
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Apr 2016 15:55:27 +0000

Hello Qin

It takes at least 2 bundles to create what a mote sees as a link, one in each direction.
Now, should we have different bundles for different RPL instance?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mercredi 27 avril 2016 16:58
To: Maria Rita PALATTELLA <[email-masked]>; Thomas Watteyne <[email-masked]>; Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft

Hi all,

Thanks
Qin

On Friday, April 22, 2016 9:07 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:

Thank you.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, April 22, 2016 2:59 PM
To: Turner, Randy <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] comments on latest terminology draft

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com/>
_______________________________________

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 27 Apr 2016 16:10:20 +0000

The way 6tisch has thought about the term link is confusing for folks not steeped in the history and context of this group

R.

On Apr 27, 2016, at 11:55 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Qin

Pascal

To: Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>; Thomas Watteyne <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>

Hi all,

Thanks
Qin

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Apr 2016 16:26:44 +0000

Well, Randy:

IEEE 802.15.4 has a concept of " link"  which we renamed as a cell to avoid that confusion. A 6TiSCH link is an IP link, we do not rename or overload.
Mapping the concept to L2 TSCH requires pointing on a set of cells in and cells out. Which are bundled together, thus the name bundle. Cells in a bundle are equipotent.

The question is whether we share the same bundles for all RPL instances or if we say that these are as many subinterfaces, on which we plug the instances as VRFs.

So far the answer seems to have been yes.

Cheers,

Pascal

From: Turner, Randy [mailto:[email-masked]]
Sent: mercredi 27 avril 2016 18:10
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Qin Wang <[email-masked]>; Maria Rita PALATTELLA <[email-masked]>; Thomas Watteyne <[email-masked]>; [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft

R.

Pascal

Hi all,

Thanks
Qin

About the definition of "link" I have to say this is  a  kind of endless story...
We have been discussed a lot in the past how to define it, how to make  clear that the concept for 6TiSCH is different from classical  IETF  link  definition,  but it seems we created  confusion, by putting  too  much information all together into  it.

Thomas's suggestion could  simplify the problem.
The  link in fact  exists when the two neighbors have at least  one  cell to exchange pkts.

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 27 Apr 2016 18:44:26 +0000

Yes, I think renaming the 15.4 link to a cell was good idea -  our terminology draft restates the definition of "link" from RFC 2460 - maybe we should just stop there, or just refer to RFC 2460 - I think the rest of the text in the terminology draft definition of "link" complicates what we're really trying to say.

R.

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 12:27 PM
To: Turner, Randy
Cc: Qin Wang; Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]
Subject: RE: [6tisch] comments on latest terminology draft

Well, Randy:

Cheers,

Pascal

From: Turner, Randy [mailto:[email-masked]]
Sent: mercredi 27 avril 2016 18:10
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Qin Wang <[email-masked]<mailto:[email-masked]>>; Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>; Thomas Watteyne <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] comments on latest terminology draft

R.

Pascal

Hi all,

Thanks
Qin

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

---

From: "Wang, Chonggang" <[email-masked]>
Date: Wed, 27 Apr 2016 21:12:10 +0000

Hi Pascal,

Would you please elaborate “should we have different bundles for different RPL instance?”? I did not quite get the question.

Thanks,
Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, April 27, 2016 11:55 AM
To: Qin Wang <[email-masked]>; Maria Rita PALATTELLA <[email-masked]>; Thomas Watteyne <[email-masked]>; Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft

Hello Qin

Pascal

Hi all,

Thanks
Qin

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Apr 2016 13:15:07 +0000

Hello Chonggang

Each RPL instance defines a topology in which some routers peer with others. The roots and/or OF may be different.
The question is whether all the L3 traffic goes on the same bundle pair regardless of the instance. At this moment it is.
Now we could hav different bundles for each instance.
There’s value in both ways, sharing saves resources by aggregating, isolating provides protection by isolating different instances in different cells…

Pascal

From: Wang, Chonggang [mailto:[email-masked]]
Sent: mercredi 27 avril 2016 23:12
To: Pascal Thubert (pthubert) <[email-masked]>; Qin Wang <[email-masked]>; Maria Rita PALATTELLA <[email-masked]>; Thomas Watteyne <[email-masked]>; Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: RE: [6tisch] comments on latest terminology draft

Hi Pascal,

Thanks,
Chonggang

<http://idcc.me/1qPHqfv>

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

To: Qin Wang <[email-masked]<mailto:[email-masked]>>; Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>; Thomas Watteyne <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>

Hello Qin

Pascal

Hi all,

Thanks
Qin

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD

---

From: "Wang, Chonggang" <[email-masked]>
Date: Fri, 29 Apr 2016 18:32:24 +0000

Hi Pascal,

Thanks for your explanation.

I agree with what you wrote below “Now we could have different bundles for each instance”.

Best regards,
Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 28, 2016 9:15 AM
To: Wang, Chonggang <[email-masked]>; Qin Wang <[email-masked]>; Maria Rita PALATTELLA <[email-masked]>; Thomas Watteyne <[email-masked]>; Turner, Randy <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] comments on latest terminology draft

Hello Chonggang

Pascal

To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Qin Wang <[email-masked]<mailto:[email-masked]>>; Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>; Thomas Watteyne <[email-masked]<mailto:[email-masked]>>; Turner, Randy <[email-masked]<mailto:[email-masked]>>

Hi Pascal,

Thanks,
Chonggang

<http://idcc.me/1qPHqfv>

Hello Qin

Pascal

Hi all,

Thanks
Qin

Thank you.
Maria Rita

Randy,

------------------

Thomas

Thanks!
R.

Thomas Watteyne, PhD