Subject: [6lo] uncompressed form

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 May 2019 05:53:24 +0000

Dear all:

I was rereading deadline and realized that the draft does not provide an umcompressed form. What of the packet flies beyond the RPL domain? I think the information should be useful there too.
Also we always claimed that RFC8138 is an encoding and that we can always turn a packet to uncompressed and back. Deadline creates an exception to that rule, which changes RFC 8138 into a sub IP protocol as opposed to a compression.
All in all, I think that an IPv6 header (e.g., a new option in a hop-by-hop header) should be provided, even if for now it appears to be for completeness only.

What do others think?

Pascal

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 23 May 2019 13:30:46 +0200

On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all:
>
> *   I was rereading deadline and realized that the draft does not provide
> an umcompressed form. What of the packet flies beyond the RPL domain? I
> think the information should be useful there too. *
>

why useful? could you explain the use case?

> * Also we always claimed that RFC8138 is an encoding and that we can
> always turn a packet to uncompressed and back. Deadline creates an
> exception to that rule, which changes RFC 8138 into a sub IP protocol as
> opposed to a compression. All in all, I think that an IPv6 header (e.g., a
> new option in a hop-by-hop header) should be provided, even if for now it
> appears to be for completeness only.   What do others think?*
>

I need to know the use case.

Best regards,
AB

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 May 2019 12:08:29 +0000

Dear all

The use case is when the data sync is not in the RPL domain or the packet has to fly outside the RPL domain. E.g., A PLC virtualized in a MEC. The root needs to uncompress the packet and forward. The draft is missing the uncompressed form.

All the best,

Pascal

From: Abdussalam Baryun <[email-masked]>
Sent: jeudi 23 mai 2019 13:31
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6lo] uncompressed form

On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

What do others think?

Best regards,
AB

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 23 May 2019 18:46:00 +0530

Hi Pascal,

Thanks for your inputs.

The draft specifies variable length deadline-time representation, only required no. of bits to be carried and no compression methods are followed . The current revision is capable of carrying deadline time in ntp format also. 

We envisaged to use dispatch routing header for transporting deadline time.

We agree your point that once the packet leaves the RPL network, then the deadline information has to be carried in hop-by-hop header. In fact we mentioned required text for calculating deadline time, while traversing  through different time zones.

  Thanks & Regards,

  Lijo Thomas 

From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: 23 May 2019 17:38
To: Abdussalam Baryun <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [SPF:fail] RE: [6lo] uncompressed form

Dear all

All the best,

Pascal

From: Abdussalam Baryun < <mailto:[email-masked]> [email-masked]> 
Sent: jeudi 23 mai 2019 13:31
To: Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]>
Cc:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: [6lo] uncompressed form

On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]> wrote:

Dear all:

What do others think?

Best regards,

AB 

 

------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 May 2019 13:34:59 +0000

Great!

Point is you need to provide the format of the uncompressed form so the root can uncompress and forward.

All the best,

Pascal

From: 6lo <[email-masked]> On Behalf Of Lijo Thomas
Sent: jeudi 23 mai 2019 15:16
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; 'Abdussalam Baryun' <[email-masked]>; [email-masked]
Subject: Re: [6lo] [SPF:fail] RE: uncompressed form

Hi Pascal,

Thanks for your inputs.

  Thanks & Regards,
  Lijo Thomas

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: 23 May 2019 17:38
To: Abdussalam Baryun <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [SPF:fail] RE: [6lo] uncompressed form

Dear all

All the best,

Pascal

From: Abdussalam Baryun <[email-masked]<mailto:[email-masked]>>
Sent: jeudi 23 mai 2019 13:31
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] uncompressed form

What do others think?

Best regards,
AB

[150th Anniversary Mahatma Gandhi]
------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 May 2019 21:19:29 -0400

Lijo Thomas <[email-masked]> wrote:
    > We agree your point that once the packet leaves the RPL network, then the
    > deadline information has to be carried in hop-by-hop header. In fact we
    > mentioned required text for calculating deadline time, while traversing
    > through different time zones.

Sorry to pick nits, but it's about whether the packet leaves an RPL network.
RPL runs across a multitude of layer-2s!
It's when it leaves an RFC8138 compressed LLN!

The difference in terminology leads to a difference in thinking.

    Pascal> Also we always claimed that RFC8138 is an encoding and that we can
    Pascal> always turn a packet to uncompressed and back. Deadline creates an
    Pascal> exception to that rule, which changes RFC 8138 into a sub IP protocol as
    Pascal> opposed to a compression.

To emphasize Pascal's point, and for many people who were not at the IETF
back in 2003, "subIP" was an entire area like Routing and Internet, which
addressed/created things like MPLS, ATM adaption layers, etc.   That's what
we are trying to avoid, because it has political and process issues.

    Pascal> All in all, I think that an IPv6 header (e.g., a new option in a
    Pascal> hop-by-hop header) should be provided, even if for now it appears to be
    Pascal> for completeness only.

I haven't read the deadline draft at this point, so I don't know if a new hop
by hop header makes sense, but it sounds right.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-