Re: [6lo] [SPF:fail] RE: uncompressed form

"Lijo Thomas" <lijo@cdac.in> Thu, 23 May 2019 13:15 UTC

Return-Path: <lijo@cdac.in>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317CC120021; Thu, 23 May 2019 06:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ8RhELAKMdw; Thu, 23 May 2019 06:15:46 -0700 (PDT)
Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D03120019; Thu, 23 May 2019 06:15:43 -0700 (PDT)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.13.8) with ESMTP id x4NDFJnG027097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2019 18:45:24 +0530
Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id x4NDF2Dn019834; Thu, 23 May 2019 18:45:02 +0530
X-AuthUser: lijo
Received: from LijoPC (lijo_new_pc.tvm.cdac.in [10.176.10.234]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id x4NDExpp003920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 May 2019 18:45:02 +0530
From: Lijo Thomas <lijo@cdac.in>
To: "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>
Cc: draft-ietf-6lo-deadline-time@ietf.org, 6lo@ietf.org, 'Abdussalam Baryun' <abdussalambaryun@gmail.com>
References: <MN2PR11MB35653193798C9BA9DD1525A7D8010@MN2PR11MB3565.namprd11.prod.outlook.com> <CADnDZ8_aBKp0yH22K0HiRPPZUrjcqJ2vezKpXjdd+tGwMvobpA@mail.gmail.com> <BYAPR11MB35580DE13386308CD7B2698ED8010@BYAPR11MB3558.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB35580DE13386308CD7B2698ED8010@BYAPR11MB3558.namprd11.prod.outlook.com>
Date: Thu, 23 May 2019 18:46:00 +0530
Message-ID: <000001d51169$ac4048b0$04c0da10$@cdac.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D51197.C5FD8DC0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ6X4Dt4L1y1+q6TSbcNlzZgOwecwJzFhnFAcZGkealDEYf0A==
Content-Language: en-in
X-CDAC-PUNE-MailScanner-ID: x4NDF2Dn019834
X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean
X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1)
X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-2.909, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_05 -1.11, HTML_MESSAGE 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: x4NDFJnG027097
X-CDAC-PUNE-MailScanner-From: lijo@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/TDW6KnNqvmlJSAbPWH-5ediDnjk>
Subject: Re: [6lo] [SPF:fail] RE: uncompressed form
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 13:15:50 -0000

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) <pthubert@cisco.com> 
Sent: 23 May 2019 17:38
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: draft-ietf-6lo-deadline-time@ietf.org; 6lo@ietf.org
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 < <mailto:abdussalambaryun@gmail.com> abdussalambaryun@gmail.com> 
Sent: jeudi 23 mai 2019 13:31
To: Pascal Thubert (pthubert) < <mailto:pthubert@cisco.com> pthubert@cisco.com>
Cc:  <mailto:draft-ietf-6lo-deadline-time@ietf.org> draft-ietf-6lo-deadline-time@ietf.org;  <mailto:6lo@ietf.org> 6lo@ietf.org
Subject: Re: [6lo] uncompressed form

 

 

 

On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) < <mailto:pthubert@cisco.com> pthubert@cisco.com> 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 

 

 

 

 

 

 


------------------------------------------------------------------------------------------------------------
[ 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.
------------------------------------------------------------------------------------------------------------