Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-rfc6775-update-06 through July 11

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 12 Jul 2017 21:27:04 +0000

Folks,

The WG LC was over yesterday.

There were zero comments on this LC.

Even if you just wish to say: "it's fine and I support it" (already assumed if you're an author), please send your message to the list.

Thanks,

Gabriel

From: 6lo [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Tuesday, June 27, 2017 16:10
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] WG Last Call on draft-ietf-6lo-rfc6775-update-06 through July 11

Hi,

I just initiated a WG last call on:

               https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-06<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-6lo-rfc6775-update-06&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7Cee57e6cb1ec0448835b008d4bdb1aea3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636342018221603649&sdata=grQRxw116Tvzq8zX8Mnxl8OHwXIvPCCa8oGOcttChq8%3D&reserved=0>

The WG last call will finish on July 11.

Thanks in advance for your comments.

Gabriel

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Jul 2017 08:12:26 +0200

> There were zero comments on this LC. 

Right.  I didn’t have the cycles to look at this, and won’t before early August.

More importantly, I believe we need feedback from implementers about this.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Jul 2017 06:22:07 +0000

Hello Gabriel :

Yes, I implicitly support the document in WGLC. I have to raise one issue about it, that we probably have been a bit too efficient in cleaning up references to RPL in the last version to prepare for this LC. As it goes, the text in section 4.2 that mandated the way the TID is computed and incremented (lollipop and all) is now all gone, since it came from a reference to RFC6550. The text would say in 05:

"                                                           The TID essentially obeys the same rules as

   the Path Sequence field in the Transit Information Option (TIO) found

   in the RPL Destination Advertisement Object (DAO) [RFC6550<https://tools.ietf.org/html/rfc6550>].
"

This test is needed otherwise the 6LBR will not be able to compare 2 values of a TID and understand the intension of the sender WRT what's newer/older.

I see 2 possibilities:

-         Restore the reference, so people clearly see that the TID field is meant to contain the same value / same incrementing and wrapping rules as the RPL Path Sequence

-         Copy the text from RFC 6550 so this document is self-contained, and leave it completely to another document to describe the optimizations that can be achieved by coupling ND and RPL.

What do others think?

From: Gabriel Montenegro [mailto:[email-masked]]
Sent: mercredi 28 juin 2017 01:10
To: [email-masked]
Cc: [email-masked]
Subject: WG Last Call on draft-ietf-6lo-rfc6775-update-06 through July 11

Hi,

               https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-06

Gabriel

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Jul 2017 06:37:07 +0000

Good point Carsten:

I think it makes sense to recall that this and the backbone router drafts were implemented, demonstrated and tested during the ETSI 6TiSCH PlugTests. The experience from implementation was retrofitted in the drafts.

I still have a few routers handy with the Cisco implementation of the 6BBR, if people want to test their implementation of the registering node against it, in both bridging and routing proxy modes.

Take care,

Pascal

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: jeudi 13 juillet 2017 08:12
To: Gabriel Montenegro <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-rfc6775-update-06 through July 11

Grüße, Carsten