[LOOPS] Fwd: [6lo] Last Call: <draft-ietf-6lo-fragment-recovery-08.txt> (6LoWPAN Selective Fragment Recovery) to Proposed Standard

Carsten Bormann <cabo@tzi.org> Thu, 16 January 2020 14:00 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C262120816 for <loops@ietfa.amsl.com>; Thu, 16 Jan 2020 06:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4pHI0IqOCzb6 for <loops@ietfa.amsl.com>; Thu, 16 Jan 2020 06:00:07 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AFE1200CC for <loops@ietf.org>; Thu, 16 Jan 2020 06:00:06 -0800 (PST)
Received: from client-0044.vpn.uni-bremen.de (client-0044.vpn.uni-bremen.de [134.102.107.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47z5Rm5JMZzyR7; Thu, 16 Jan 2020 15:00:04 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ECDD0D59-E916-4FB9-A433-1A32794467C5"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Carsten Bormann <cabo@tzi.org>
Date: Thu, 16 Jan 2020 15:00:03 +0100
Cc: Carsten Bormann <cabo@tzi.org>
X-Mao-Original-Outgoing-Id: 600876003.722854-1d40073c9ecb3cb350bb14747e755527
Message-Id: <1C86A449-11F0-4AD7-AA54-76084F93DCA9@tzi.org>
References: <157918220640.26131.868807962153171240.idtracker@ietfa.amsl.com>
To: loops@ietf.org
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/v_1-ejOYDpU_YULTMgU7oTEqP2M>
Subject: [LOOPS] Fwd: [6lo] Last Call: <draft-ietf-6lo-fragment-recovery-08.txt> (6LoWPAN Selective Fragment Recovery) to Proposed Standard
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 14:00:13 -0000

Fragment recovery is an approach that is somewhat related to LOOPS:
On a challenged segment of the path (a 6LoWPAN mesh where larger packets need to be fragmented and thus are subject to exponentiation of delivery rates), a local recovery scheme is run.
I think it is interesting to see how the various objectives of LOOPS are addressed in this limited context.
(Also, an IETF last call is always a good reason to have a final look at a document that is proposed to progress.)

Grüße, Carsten


> Begin forwarded message:
> 
> From: The IESG <iesg-secretary@ietf.org <mailto:iesg-secretary@ietf.org>>
> Subject: [6lo] Last Call: <draft-ietf-6lo-fragment-recovery-08.txt> (6LoWPAN Selective Fragment Recovery) to Proposed Standard
> Date: 2020-01-16 at 14:43:26 CET
> To: "IETF-Announce" <ietf-announce@ietf.org <mailto:ietf-announce@ietf.org>>
> Cc: draft-ietf-6lo-fragment-recovery@ietf.org <mailto:draft-ietf-6lo-fragment-recovery@ietf.org>, 6lo-chairs@ietf.org <mailto:6lo-chairs@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu <mailto:carlesgo@entel.upc.edu>>, suresh@kaloom.com <mailto:suresh@kaloom.com>, 6lo@ietf.org <mailto:6lo@ietf.org>
> Reply-To: last-call@ietf.org <mailto:last-call@ietf.org>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/4dLWt2sqGGu7bPizyh7nfWsJYCo <https://mailarchive.ietf.org/arch/msg/6lo/4dLWt2sqGGu7bPizyh7nfWsJYCo>>
> 
> 
> The IESG has received a request from the IPv6 over Networks of
> Resource-constrained Nodes WG (6lo) to consider the following document: -
> '6LoWPAN Selective Fragment Recovery'
>  <draft-ietf-6lo-fragment-recovery-08.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org <mailto:last-call@ietf.org> mailing lists by 2020-01-30. Exceptionally, comments may
> be sent to iesg@ietf.org <mailto:iesg@ietf.org> instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This draft updates RFC 4944 with a simple protocol to recover
>   individual fragments across a route-over mesh network, with a minimal
>   flow control to protect the network against bloat.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ <https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/>
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ballot/>
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org <mailto:6lo@ietf.org>
> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>