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 protected]> On Behalf Of Lijo Thomas Sent: jeudi 23 mai 2019 15:16 To: Pascal Thubert (pthubert) <[email protected]> Cc: [email protected]; 'Abdussalam Baryun' <[email protected]>; [email protected] Subject: Re: [6lo] [SPF:fail] RE: uncompressed form 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 protected]<mailto:[email protected]>> Sent: 23 May 2019 17:38 To: Abdussalam Baryun <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [SPF:fail] RE: [6lo] uncompressed form 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 protected]<mailto:[email protected]>> Sent: jeudi 23 mai 2019 13:31 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [6lo] uncompressed form On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> 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 [150th Anniversary Mahatma Gandhi] ------------------------------------------------------------------------------------------------------------ [ 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. ------------------------------------------------------------------------------------------------------------
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
