From nobody Mon Jan 8 13:46:52 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0E120726 for ; Mon, 8 Jan 2018 13:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OjxMBZm1vHek for ; Mon, 8 Jan 2018 13:46:49 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD0712D7F9 for ; Mon, 8 Jan 2018 13:46:49 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id p13so16088381qke.4 for ; Mon, 08 Jan 2018 13:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yu8TQYta3V3FuWllfzUOZCvgMZDDloIACJS1GIPEzeA=; b=T9xazIFmFI5qjW1GbXqAVWQ7QEVvfsOAL1UXMHFXYu3MIzmDVk+rjIyX552N/7dzQh cP5umUJWWVEu3Z1b87Led3IKdez0HZ+6HSSflIpwNnLpKH8ZaOLI3IGsrbR7+bEhQQsM 483vrg/xNOE0jBOaoAE50GZBF0yD4eVG8Lzb7c5YzMHfBwdLTLaxjaidMzBpQsTkLLKW KaMpWuUuZgWZncDoRNMQGazhM1t0zRx1656AuBsYnCIF3NehSN4cC+lxlFPcRXvP15X5 U/kxux42BescVc5N6GWKOg/dfsYHbhH3tH3eFUaz3d9Kps6pwHbrVDqO9PFPolU9wE1J ZlVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yu8TQYta3V3FuWllfzUOZCvgMZDDloIACJS1GIPEzeA=; b=qz459KjX32FJNalHpmiQa374NWvgEj9QVKp5cdcuiAs3WI90JYn1dUMUZv+IBbk1o6 fBJgcjN2Q8CuwPZsXTwDyTY4XtwCKA3r5gEenZPDi3IK1A60Tz+cyoDZDbSUl2UVxlb+ tGkghksgwwJ+dROd5AZt8lq28ts/ngoY+4gOvahc4Q5kvcQFg23BXa7oKnGxc9xqQ9hn NQ5fgHGCKbSMDi/r7qHt/GZgKxVaoblBZvsCuuRONmZdeZ7oOLpGDT2NyZM/NBphT6rc IWs7iQ7ZiTsiYbpdVY42JK8FZRBa4jtmB6xYwxsPOJTO7Edgz3lC7DMYfEc623gqrPDe /jcg== X-Gm-Message-State: AKwxyteNNKMy2MH6TeQE65ldGGmtusmDXmnUIg/+SlWpAjxGmqmzInNf DlKX5AYRySDHAoLIKYbfvi/Oz6p0r82ybUm+nMbcxQ== X-Google-Smtp-Source: ACJfBouSHFlxTjxmtGJUMlAXRi5YOuKNim6qaG1Xf05lj3FP0n8pKqtHhFcmHO+q9Vu7YhXXFUnn5Fk1LghJAffvpaI= X-Received: by 10.55.55.208 with SMTP id e199mr19276329qka.80.1515448008645; Mon, 08 Jan 2018 13:46:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.45.184 with HTTP; Mon, 8 Jan 2018 13:46:48 -0800 (PST) In-Reply-To: References: <151182163087.13335.9898030294539351604@ietfa.amsl.com> From: Justin Dean Date: Mon, 8 Jan 2018 16:46:48 -0500 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary="001a11471ae83b24f305624abc91" Archived-At: Subject: Re: [manet] ready for LC : latency and multi-hop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 21:46:51 -0000 --001a11471ae83b24f305624abc91 Content-Type: text/plain; charset="UTF-8" As discussed during IETF 100 these documents are now in last call. Please review them and post comments to the list. https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01 https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03 --001a11471ae83b24f305624abc91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As discussed during IETF 100 these documents are now = in last call. Please review them and post comments to the list.
<= br>

https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-= extension-01
https://tools.ietf.org/html/draft-ietf-manet= -dlep-multi-hop-extension-03
--001a11471ae83b24f305624abc91-- From nobody Sun Jan 21 10:03:49 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB7126D73 for ; Sun, 21 Jan 2018 10:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DZZunJttw4GO for ; Sun, 21 Jan 2018 10:03:44 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7A112426E for ; Sun, 21 Jan 2018 10:03:44 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id b77so7422622itd.0 for ; Sun, 21 Jan 2018 10:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPwGE6/dLeDBPR2+NtNgkrvTdDNKV0YQKNC83k9nYh4=; b=FTnWi68lbCiBPTbrQ/UMr0HAH/UrerS7bP9BCrMfaEoIBNc6FWPkZ83mIjsnFrNdu8 PiWlrM1FubpmJS/EuDiyCez3PG7AGOUOWffIdraq3gDOGEfnWsRG0XW5sbqHU4u1XQfb L7503q9qBSZQK6zGpCgWXhEfFuFJ6Icetb26eKloPpTlZMrCAhJO+94pQ40Dw1jtA+i0 PB/vQlgETKpNUZaFvQmlhGPDiUIkv/MDFUULS3Wv2v3vJt1GoxQOCGye0FQR8+uVj0Z1 vvrbTCqGZzsW8/9zIkruu5DVw0Fujvk9KPNcElPW/h3RYXFDz6FlzjGw5gU1hPZFrU21 1Zaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TPwGE6/dLeDBPR2+NtNgkrvTdDNKV0YQKNC83k9nYh4=; b=bjRij6sGOe6+MAQDfEs2bbxefFib/IcDMCT3gdSjdc0l9XGkzpywmvlBR4ZDs/pN3X DRppNNwNlIjFA3HtcOy1nkVD74JbJFGFy+meCi+VwKvl97KadmkYlMsgn7J+qI9znNt3 cN9exPMsUDq4MGZ343LmxiVWA8heQzXZVNbLuUN3GJGJxhEaMBBX2F5adLUpVK3sumLB cY2RyfWG1zAG4kJhgMwJ3KPW2u2soga+w9pLRVh/qxI3xl24EEuEevDuGw1Q8T/oIySq IumOJJIo+uf60l4SZxKkRSqgCBInFCqYeWyCBwDjEL5MP/CtZ6MZaa6ebL4KlZel3ybi gb1A== X-Gm-Message-State: AKwxytcsBWjtJ2SKmgBxezcAT9ukeTIJO2Q+SNnBX435AA3T0kXN113F pzYfKHbPeCQ0AUIWRfLQFBW0MvkIIp4K1zio39g= X-Google-Smtp-Source: AH8x2262gUAA6tzWZQop3HdMv89p7OE66OTm3Q2JVeUDD9qVkxxxa1qoJkUhxb2dMLHyfenInlTEnlEgeTA0d+mzd8g= X-Received: by 10.36.83.1 with SMTP id n1mr5392276itb.96.1516557823875; Sun, 21 Jan 2018 10:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.61.10 with HTTP; Sun, 21 Jan 2018 10:03:43 -0800 (PST) In-Reply-To: References: <151182163087.13335.9898030294539351604@ietfa.amsl.com> From: Victoria Pritchard Date: Sun, 21 Jan 2018 18:03:43 +0000 Message-ID: To: Justin Dean Cc: MANET IETF Content-Type: multipart/alternative; boundary="001a1144938c5f9e0705634d229f" Archived-At: Subject: Re: [manet] ready for LC : latency and multi-hop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 18:03:47 -0000 --001a1144938c5f9e0705634d229f Content-Type: text/plain; charset="UTF-8" Hi all, Just a few picky comments on the Latency Range draft. Title Lantency -> Latency Abstract Should you reference the DLEP RFC number here? Or at least expand the acronym? Section 1 It's "Dynamic Link Exchange Protocol" (not "Event Protocol") "provides an average latency" - the definition in RFC8175 actually says "The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing." so not sure it's right to say it provides an average. "one new DLEP Data Items" - unnecessary 's' on Items Section 3 Is it " Latency Range Item " or " Latency Range Data Item "? Makes sense to be consistent Under the Maximum Latency field description: "representing the transmission longest delay" should that be "longest transmission delay"? Similar comment for Minimum Latency Section 5.2 "Data Item Type Values" is the name of the registry in RFC8175. Regards, Vicky On 8 January 2018 at 21:46, Justin Dean wrote: > As discussed during IETF 100 these documents are now in last call. Please > review them and post comments to the list. > > > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01 > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1144938c5f9e0705634d229f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Just a few picky comments on th= e Latency Range draft.

Title
Lanten= cy -> Latency

Abstract
Should you ref= erence the DLEP RFC number here? Or at least expand the acronym?
=
Section 1
It's "Dynamic Link Exchange Pro= tocol" (not "Event Protocol")

"= ;provides an average latency" - the definition in RFC8175 actually say= s "The calculation
=C2=A0 =C2=A0of latency is implementation= dependent.=C2=A0 For example, the latency may
=C2=A0 =C2=A0be a = running average calculated from the internal queuing." so not sure it&= #39;s right to say it provides an average.

"o= ne new DLEP
=C2=A0 =C2=A0Data Items" - unnecessary 's= 9; on Items
=C2=A0 =C2=A0
Section 3
Is it &qu= ot; Latency Range Item " or " Latency Range Data Item "? Mak= es sense to be consistent

Under the Maximum Latenc= y field description:
"representing the transmission longest<= /div>
=C2=A0 =C2=A0 =C2=A0 delay"
should that be "l= ongest transmission delay"?
Similar comment for Minimum Late= ncy

Section 5.2
"Data Item Type Val= ues"=C2=A0 is the name of the registry in RFC8175.

Regards,
Vicky

On 8 January 2018 at 21:4= 6, Justin Dean <bebemaster@gmail.com> wrote:
As discussed during IETF 100 th= ese documents are now in last call. Please review them and post comments to= the list.


https://tools.ietf.org/html/draft-ie= tf-manet-dlep-latency-extension-01
https://tools.ietf.org/html= /draft-ietf-manet-dlep-multi-hop-extension-03

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a1144938c5f9e0705634d229f-- From nobody Sun Jan 21 11:25:04 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02A12D77C for ; Sun, 21 Jan 2018 11:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ti4AwsTIWKVY for ; Sun, 21 Jan 2018 11:25:00 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4E512AF83 for ; Sun, 21 Jan 2018 11:25:00 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id b77so7583037itd.0 for ; Sun, 21 Jan 2018 11:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tH5ZbgE4Oii9alHycsq6TOaQHcX53/2D0LPNZLy/2OY=; b=f1SAJ/6JFcvYhexyBCYk3OujRNOCWCwX/tPt7/RXggw7Em8RHHrHQuCVSjZLtToQ0Y TpiRJLYG1eAeq485v72OSOA0xXYfdAX2uXHEhY5/JFUXax8y2Zi2W/jpvOkUGv/TALC6 LjN/cuwvYFrvNDVvb9Hpavhl8bkAsRItNdpyFx5W5ESka/sFG9XtNzMFum5XKmGpN2zk B9Py3M+eU7RrYWYY1+HseHsrqwAkWy0RNmfSFynbnxIEr85jLHmdQMlE7Zd7Nu/JOC4a wjD0VqfLVZsSNGFS7taxzLkgckuK+20eMfU18dVww/KEuKE5DUtoqLbQ6K9HRusPbV17 6eWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tH5ZbgE4Oii9alHycsq6TOaQHcX53/2D0LPNZLy/2OY=; b=RITj5uI1aIqKPZjNkIa5/B47TOnPjXWvEl1/SuZGAWPy9tv08f2KHgaZAo/DKReKWS 9R5o0AEEOZ++ujNhJp89MHyeEZXZup73psL4CD16Z3PdxYJwze3SGqUaOVA/K/UOuSEF MHPO0gQnkEopg1RhrVRDIFd6keMMPxwU4J5aZWFmup8auqswm7Axcvz1zNQhb8C0m7cF 60EwuTz+nhi+ARzlS2PUVzkQ9Zhbj6vuweYP9m81Pt7H5AIpewjb9Bnabbtk50M10GfT 4X3LUXBh4SfyoAe0KzXbgK2IHXQZGadwovsioLThdd9CTQFnn16myJFBDQCRZYACDsfv 1DIg== X-Gm-Message-State: AKwxytcWEI/Jkkp3I1dS+EOSH4Uzqs12em9ZYa7v/+YF+rTolq+C8tA3 sMS0vy+xERZUM1u8HgnjmPQeYMR28UAoIubUfEY= X-Google-Smtp-Source: AH8x226tkUb909XRoIXfgaVyJ/Bgd5ohq8KKj0F98jNWw+dT7ilA2fwpl1Hu84CoerCFB0F05qvTZIj2bG+c4YxA/KI= X-Received: by 10.36.145.208 with SMTP id i199mr5382160ite.81.1516562699151; Sun, 21 Jan 2018 11:24:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.61.10 with HTTP; Sun, 21 Jan 2018 11:24:58 -0800 (PST) In-Reply-To: References: <151182163087.13335.9898030294539351604@ietfa.amsl.com> From: Victoria Pritchard Date: Sun, 21 Jan 2018 19:24:58 +0000 Message-ID: To: Justin Dean Cc: MANET IETF Content-Type: multipart/alternative; boundary="94eb2c07d5f4f66f5505634e4437" Archived-At: Subject: Re: [manet] ready for LC : latency and multi-hop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 19:25:03 -0000 --94eb2c07d5f4f66f5505634e4437 Content-Type: text/plain; charset="UTF-8" Hi all, Some comments on the multi-hop extension draft... Abstract Should you reference the DLEP RFC number here? Or at least expand the acronym? Section 1 It's "Dynamic Link Exchange Protocol" (not "Event Protocol") Throughout the draft, should "data item" be "Data Item"? Section 3.1 It SHOULD be carried in all those messages - does that mean even if it hasn't changed since the last time it was reported? Under Hop Count field description - "used to indicated" - extra 'd' on "indicated" "a destination no longer being reachable" So this would be sent in a Destination Announce Response message, even if there was no Destination Announce to reply to? Is the Destination Announce Response the reply to the Hop Control action? Also, the destination no longer being reachable would cause a Destination Down according to core DLEP rules, right? So two messages get sent? Section 3.2 "A router can request multi-hop reachable destination be changed to a single hop. " Should that be "request a multi-hop"? If the Hop Control is sent in a Session Update, this section says the result is sent in Destination Down or Destination Update messages. Assuming this means the Hop Count Data Item is used to give the result, Section 3.1 doesn't mention use in Destination Down. Also, on that note - is the Destination Down allowed to include the Hop Count Data Item (I don't think RFC8175 forbids this but usually there's only a MAC address data item in that message)? If the Hop Control is sent in a Link Characteristics Request message, the text says the response is another Link Characteristics Request Message - shouldn't the response be a Link Characteristics Response Message? Also, not sure where the Destination Announce Response Message as stated in Section 3.1 fits? The final 2 sentences in the 4th paragraph - being really picky here, but "any changes in Hop Counts" would include the hop count becoming zero if the destination is no longer reachable, so according to this text there MUST be a Destination Down and there MUST also be a Destination Update? Could make it say "any other changes in Hop Counts"? For other destinations that are affected by a link characteristics request, are the Destination Update and Destination Down messages sent as per core DLEP, or would they include the Hop Count Data Item indicating that this change occurred due to a hop control action? 5th paragraph here repeats "Session Update Message" - but then talks about associated destination MAC - and seems to try to address both session update and link characteristics, which have been explained in the previous 2 paragraphs. Looks like this has been cut and pasted but since it's separated into two earlier paragraphs it could probably be removed? 3.2.1 "Session Update Message message" - extra "message" at the end. Same in 3.2.2, 3.2.3. 3.2.2 Why does this request have no impact for multi-hop destinations? 3.2.3 The text about other destinations being impacted applies to all these actions - and is already explained earlier, so doesn't need to be repeated here. Later sections say "as described above". 3.2.4 The other actions are "SHOULD" and 2 of them also say "attempt" - why is this a MUST? Section 4 Is there meant to be a capital S on Security in the final sentence? 5.2 "Data Item Type Values" rather than "Data Item Values" 5.3 There shouldn't be a full stop after the reference to RFC8126. Kind regards, Vicky. On 21 January 2018 at 18:03, Victoria Pritchard wrote: > Hi all, > > Just a few picky comments on the Latency Range draft. > > Title > Lantency -> Latency > > Abstract > Should you reference the DLEP RFC number here? Or at least expand the > acronym? > > Section 1 > It's "Dynamic Link Exchange Protocol" (not "Event Protocol") > > "provides an average latency" - the definition in RFC8175 actually says > "The calculation > of latency is implementation dependent. For example, the latency may > be a running average calculated from the internal queuing." so not sure > it's right to say it provides an average. > > "one new DLEP > Data Items" - unnecessary 's' on Items > > Section 3 > Is it " Latency Range Item " or " Latency Range Data Item "? Makes sense > to be consistent > > Under the Maximum Latency field description: > "representing the transmission longest > delay" > should that be "longest transmission delay"? > Similar comment for Minimum Latency > > Section 5.2 > "Data Item Type Values" is the name of the registry in RFC8175. > > > Regards, > Vicky > > On 8 January 2018 at 21:46, Justin Dean wrote: > >> As discussed during IETF 100 these documents are now in last call. Please >> review them and post comments to the list. >> >> >> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01 >> https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03 >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > --94eb2c07d5f4f66f5505634e4437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

Some comments on the mult= i-hop extension draft...

Abstract
S= hould you reference the DLEP RFC number here? Or at least expand the acrony= m?

Section 1
It's "Dynamic Link= Exchange Protocol" (not "Event Protocol")

Throughout the draft, should "data item" be "Data It= em"?

Section 3.1
It SHOULD be carri= ed in all those messages - does that mean even if it hasn't changed sin= ce the last time it was reported?

Under Hop Count = field description - "used to indicated" - extra 'd' on &q= uot;indicated"

"a destination no
=C2=A0 =C2=A0 =C2=A0 longer being reachable"
So this woul= d be sent in a Destination Announce Response message, even if there was no = Destination Announce to reply to? Is the Destination Announce Response the = reply to the Hop Control action? Also, the destination no longer being reac= hable would cause a Destination Down according to core DLEP rules, right? S= o two messages get sent?

Section 3.2
&qu= ot;A router can request multi-hop reachable
=C2=A0 =C2=A0destinat= ion be changed to a single hop. "
Should that be "reque= st a multi-hop"?

If the Hop Control is sent i= n a Session Update, this section says the result is sent in Destination Dow= n or Destination Update messages. Assuming this means the Hop Count Data It= em is used to give the result, Section 3.1 doesn't mention use in Desti= nation Down. Also, on that note - is the Destination Down allowed to includ= e the Hop Count Data Item (I don't think RFC8175 forbids this but usual= ly there's only a MAC address data item in that message)?=C2=A0

If the Hop Control is sent in a Link Characteristics Requ= est message, the text says the response is another=C2=A0Link Characteristics Request Message -=C2= =A0shouldn't the response be a Link Characteristics Response Mes= sage? Also, not sure where the Destination Announce Response Message as sta= ted in Section 3.1 fits?

The final 2 sentences= in the 4th paragraph - being really picky here, but "any changes in H= op Counts" would include the hop count becoming zero if the destinatio= n is no longer reachable, so according to this text there MUST be a Destina= tion Down and there MUST also be a Destination Update? Could make it say &q= uot;any other changes in Hop Counts"?

For oth= er destinations that are affected by a link characteristics request, are th= e Destination Update and Destination Down messages sent as per core DLEP, o= r would they include the Hop Count Data Item indicating that this change oc= curred due to a hop control action?

5th paragraph = here repeats "Session Update Message" - but then talks about asso= ciated destination MAC - and seems to try to address both session update an= d link characteristics, which have been explained in the previous 2 paragra= phs. Looks like this has been cut and pasted but since it's separated i= nto two earlier paragraphs it could probably be removed?

3.2.1
"Session Update Message message" - extra &= quot;message" at the end. Same in 3.2.2, 3.2.3.

3.2.2
Why does this request have no impact for multi-hop desti= nations?

3.2.3=C2=A0
The text about othe= r destinations being impacted applies to all these actions - and is already= explained earlier, so doesn't need to be repeated here. Later sections= say "as described above".

3.2.4=C2=A0
The other actions are "SHOULD" and 2 of them also say &q= uot;attempt" - why is this a MUST?

Section 4<= /div>
Is there meant to be a capital S on Security in the final sentenc= e?

5.2
"Data Item Type Values"= rather than "Data Item Values"

5.3=C2= =A0
There shouldn't be a full stop after the reference to RFC= 8126.


Kind regards,
Vicky.

On 21 January 2018 at 18:03, Victoria Pritchard <pritchardv0@gmail.c= om> wrote:
Hi all,

Just a few picky comments on the Latency Range = draft.

Title
Lantency -> Latency=

Abstract
Should you reference the DLEP = RFC number here? Or at least expand the acronym?

S= ection 1
It's "Dynamic Link Exchange Protocol" (not= "Event Protocol")

"provides an ave= rage latency" - the definition in RFC8175 actually says "The calc= ulation
=C2=A0 =C2=A0of latency is implementation dependent.=C2= =A0 For example, the latency may
=C2=A0 =C2=A0be a running averag= e calculated from the internal queuing." so not sure it's right to= say it provides an average.

"one new DLEP
=C2=A0 =C2=A0Data Items" - unnecessary 's' on Items
=C2=A0 =C2=A0
Section 3
Is it " Latency Ra= nge Item " or " Latency Range Data Item "? Makes sense to be= consistent

Under the Maximum Latency field descri= ption:
"representing the transmission longest
=C2= =A0 =C2=A0 =C2=A0 delay"
should that be "longest transm= ission delay"?
Similar comment for Minimum Latency

Section 5.2
"Data Item Type Values"=C2= =A0 is the name of the registry in RFC8175.

=
Regards,
Vicky

On 8 January 2= 018 at 21:46, Justin Dean <bebemaster@gmail.com> wrote:
As discussed during IETF 100 these documents are now in last= call. Please review them and post comments to the list.

_____________________________________= __________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--94eb2c07d5f4f66f5505634e4437-- From nobody Tue Jan 23 08:29:54 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265E51270A0 for ; Tue, 23 Jan 2018 08:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G7kvqDJLXyBh for ; Tue, 23 Jan 2018 08:29:50 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B87112706D for ; Tue, 23 Jan 2018 08:29:50 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id i1so2752913qtj.8 for ; Tue, 23 Jan 2018 08:29:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SChQmYp/asFlih6Tv7UmcTB7CExW1WROWiS5U2c6w9E=; b=dJoS2treZhRjXeC8//LoLCVgjvbMw539lC2vTXttlJbTJtIqonQlDAUbUibHy6ab8y 5kJwUvb0uzkUH/Md7Ih+57U+UheyJ+nWVQULMakVZNnSvqlR+97DUDOSxW/ePsuBZZn5 guZzVWHtb6S7x/LHqqSvmSIYrz/d4Fc7gVHJYqjliLdHORARUi8famOvYjkzjYCbKibr sIbv6YEPv1qMU3KatsdHQ4Y+SmxElkRleyJ4LftoqHOZ5DwJVqTBx5GO2sxrGz5iPpL4 vVH//eM+rcwVHOz5RNHWAe8kaoDZM1fDeVeZ8a9MabvVuOjF1SU5ud2w4yvupVtNkVrl qfrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SChQmYp/asFlih6Tv7UmcTB7CExW1WROWiS5U2c6w9E=; b=YnjDFtT3v2/gJXftoHLaHNrqBvIa00ft3G3VbIN2U53W+IwKAjZ7EbfzcE0ejZMPDS e0Co7EHBPkNnLVQUo7QdFAt8llblqi//bwZ+4Ve4Nelhkl0nJ/old23iH3nwTGhTdf5N 6fhNpM4Q+ctZ/R5IZSsIsEvWu72gzUgpdVgoCp12CN9fQPzeLqZzpioCsqMc1W+bcfvt qTf1Qb+mjtGp9kITL9t4q8//2Vi2W80ykqw1QmrlPfTCNGI92R9AGxekarl6Zle8ZlZU CxF8XQw5qB2L5trwVQzIL40IoOLJ9fWYP+tGj/UU725Wkb79+fvPWowuw1/oD+/gHDE9 EbuA== X-Gm-Message-State: AKwxyte7Ui9z0THsQDWugKmgHJS66rBwfmDXFZ826jEBOnqq6AE1yjiO ye9/RmjNxXWtgJ9YjkamZXqlAjpteHmeGWx7ieQay7WX X-Google-Smtp-Source: AH8x224SN68x5bt9W/8KaxOHd2QgdX3Gd9Z/WxwMKJ5Xv2PMzgFPBjuT8F8D5LcdPtXqr9yRlmZ0LhKXw981cvRLK5I= X-Received: by 10.200.3.150 with SMTP id t22mr4292039qtg.19.1516724988773; Tue, 23 Jan 2018 08:29:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.8.244 with HTTP; Tue, 23 Jan 2018 08:29:48 -0800 (PST) From: Justin Dean Date: Tue, 23 Jan 2018 11:29:48 -0500 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary="f40304352fa42d8f410563740e58" Archived-At: Subject: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 16:29:52 -0000 --f40304352fa42d8f410563740e58 Content-Type: text/plain; charset="UTF-8" Working group last call is ending on both https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ Please get your comments in. Justin Dean --f40304352fa42d8f410563740e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Working group last call is ending on both=C2=A0


Please get your comments in.

Justin Dean<= /div>
--f40304352fa42d8f410563740e58-- From nobody Wed Jan 24 09:13:29 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67A91270AB for ; Wed, 24 Jan 2018 09:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CmR2hsEoaNYy for ; Wed, 24 Jan 2018 09:13:26 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2636F127077 for ; Wed, 24 Jan 2018 09:13:26 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id s11so3320035oih.11 for ; Wed, 24 Jan 2018 09:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=R//XMBFatQbGm/oI/MB/yqzrg3j9NxAh92v1u3kzmJM=; b=SR2/GEvfhHXZ9Ze83GbRsuM9d3vWilVGslWh34dZ2kCIfljRMshq0SUug0cz0IGyCz utsBS+pxrpjWjgzUswGx0bMH0QKSXcRChe7IE0NrIV4NK8TW7WG229g4HoDr60QaKTZG W/Zcwde7juX9T/17sMCbcygNqUfYchmzztHIk2N0doaLvTdmTa6osTXHJw95dc+KctKb 5Gti2mskvVnUEwPYzHAa5fjIuEo67tw5mTCaFVbvNpGSikzHdqXovTjEeaPyMrVPbqK0 /2ZhcF71vx82pDiTCesu/oJYMv2DUQdQP+sYd+Ns5eUzrulEfEtGDS28qVBZS8b928rN AjHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=R//XMBFatQbGm/oI/MB/yqzrg3j9NxAh92v1u3kzmJM=; b=trmEDi+OrgJKvI9NZlFX//BoCzga66kob2g97JSfwwj8DCXApTW+4FUC197Wc8Klv8 pCZ/KFesf1puO7uOpmtKEhoCL9jlL5wAOn/2/cTopfquGNCQTQu+DN4VPAIXCR7mfJqp dFXeSVS4dtZGilxOpBw/1rgVW63MhvXFfOv+z7Nt1ijlNX0tCInzncQMW44MOWzGwR2C AvGyEU2JMBJBjBOknktRGW2oagCHS1q463ZqdmT4HMWcx2wF81iO2a9DSzeASg8v0d7K F/uCGPCsH11ygUcIJiYCREz+F3Spaf1IQl+1VU2AzNiSmebx15y3c8kA2m5mtVUl53MX Qh+w== X-Gm-Message-State: AKwxytelV/bGOzj2VDnsrcOi0sJZERKEdT7yaEvZm5hzf2JIMEcHaJsm ZwbQYBmttaKoTarVjaVuxRYEKqM3JDw2qRR1dZo= X-Google-Smtp-Source: AH8x225n1h105LMx1AZS8PXBmjWU5PqPvvHb5hfZ14vXqkU5OcvauaMlbyHzqABCeNflcNqRBbsQzzznFilKO0LxFaI= X-Received: by 10.202.212.199 with SMTP id l190mr9353790oig.263.1516814005391; Wed, 24 Jan 2018 09:13:25 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jan 2018 09:13:25 -0800 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 24 Jan 2018 09:13:25 -0800 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary="001a113de59afb562a056388c762" Archived-At: Subject: [manet] Fwd: Re: [ipwave] Rechartering X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 17:13:29 -0000 --001a113de59afb562a056388c762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI =E2=80=94 from the ipwave list (aka its@ietf.org). On January 24, 2018 at 12:07:53 PM, Sri Gundavelli (sgundave) ( sgundave@cisco.com) wrote: Hi Carlos, Thanks for initiating the rechartering process. The initial work that the group focussed on around, IPv6 over Requirements / 802.11-OCB is just the enabler, but I tend to think we need to solve number of other problems for Vehicular Connectivity, Road-side infra ..etc. I am very supportive of this work and planning to contribute in the form of writing new proposals. Regards Sri On 1/24/18, 2:25 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos Cano" wrote: >Hi, > >Now that our first document is close to be shipped to the IESG for IETF >LC, the chairs and AD are starting to plan on potential rechartering >(as we anticipated in Singapore). > >There are a number of things people have discussed in the past, >including the time of the BoFs. Now it is time to bring in the >ideas and suggest them on the mailing list. > >Please, keep in mind some important considerations/constraints: > >- We will schedule time on the f2f session in London for rechartering >discussion, _only if_ discussion has taken place on the mailing list. >So please, do not wait for the call for presentations during the >meeting to propose topics. > >- Our current charter includes a "Problem Statement" item, which is >addressed in the document draft-ietf-ipwave-vehicular-networking. >Obviously, potential topics for rechartering should be covered there >(it will not make sense to work on topics that the community has not >agreed to be important and remain unsolved). > >- A rechartering process will always take into account the energy level >of the WG and the completion level of the current milestones. This >means that we need to finish (submit to the IESG) our 2 documents >before we actually start working on the new topics. > >Please, share your thoughts on the mailing list! > >Thanks, > >Carlos and Russs > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --001a113de59afb562a056388c762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FYI =E2=80=94 from the ipwave list (aka its@ietf.org).


On Ja= nuary 24, 2018 at 12:07:53 PM, Sri Gundavelli (sgundave) (sgundave@cisco.com) wrote:

Hi Carlos,

Thanks for initiating the rechartering process. The initial work that t= he
group focussed on around, IPv6 over Requirements / 802.11-OCB is just t= he
enabler, but I tend to think we need to solve number of other problems = for
Vehicular Connectivity, Road-side infra ..etc. I am very supportive of
this work and planning to contribute in the form of writing new proposa= ls.

Regards
Sri








On 1/24/18, 2:25 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos= Cano"
<its-bounces@ietf.org on= behalf of cjbc@it.uc3m.es> wrote= :

>Hi,
>
>Now that our first document is close to be shipped to the IESG for = IETF
>LC, the chairs and AD are starting to plan on potential recharterin= g
>(as we anticipated in Singapore).
>
>There are a number of things people have discussed in the past,
>including the time of the BoFs. Now it is time to bring in the
>ideas and suggest them on the mailing list.
>
>Please, keep in mind some important considerations/constraints:
>
>- We will schedule time on the f2f session in London for recharteri= ng
>discussion, _only if_ discussion has taken place on the mailing lis= t.
>So please, do not wait for the call for presentations during the
>meeting to propose topics.
>
>- Our current charter includes a "Problem Statement" item= , which is
>addressed in the document draft-ietf-ipwave-vehicular-networking.
>Obviously, potential topics for rechartering should be covered ther= e
>(it will not make sense to work on topics that the community has no= t
>agreed to be important and remain unsolved).
>
>- A rechartering process will always take into account the energy l= evel
>of the WG and the completion level of the current milestones. This
>means that we need to finish (submit to the IESG) our 2 documents
>before we actually start working on the new topics.
>
>Please, share your thoughts on the mailing list!
>
>Thanks,
>
>Carlos and Russs
>
>_______________________________________________
>its mailing list
>its@ietf.org
>https://www.i= etf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.= org/mailman/listinfo/its
--001a113de59afb562a056388c762-- From nobody Thu Jan 25 07:07:27 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB912DA53 for ; Thu, 25 Jan 2018 07:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 8mSMsbIiYNFk for ; Thu, 25 Jan 2018 07:07:21 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 47998127241 for ; Thu, 25 Jan 2018 07:07:13 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w0PF7CKW025985; Thu, 25 Jan 2018 10:07:12 -0500 From: "Wiggins, David - 0665 - MITLL" To: Justin Dean , MANET IETF Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44A Date: Thu, 25 Jan 2018 15:07:10 +0000 Message-ID: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3599719634_275014239" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250205 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 15:07:26 -0000 --B_3599719634_275014239 Content-type: multipart/alternative; boundary="B_3599719634_670375707" --B_3599719634_670375707 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I think the latency extension is in reasonable shape.=C2=A0 I agree with all of= Vicky=E2=80=99s recent comments. =20 Here are some comments on the Multi-Hop extension. =20 Section 3.1 =E2=80=9C=E2=80=A6each hop represents a transmission and the number of hops is equal to the number of transmissions required to go from a router connected modem to the destination's connected modem.=E2=80=9D =20 So hops are counted starting at the modem that is the DLEP peer of the rout= er.=C2=A0 But then: =20 =E2=80=9CThe minimum number of hops is 1, which represents the router's locally c= onnected modem.=E2=80=9D =20 If counting starts at that modem, wouldn=E2=80=99t hop count be 0 for the modem?=C2= =A0 If it=E2=80=99s 1, this seems to mean that the (typically) wired link between th= e router and the modem is being counted.=C2=A0 I think the two quotes above are = inconsistent about whether this first link counts as a hop.=C2=A0 If the hop cou= nt was meant to convey over-the-air hops, then the router=E2=80=99s locally connec= ted modem should have a hop count of 0. =20 =E2=80=9CA value of zero (0) is used to indicated that processing of a Hop Control action, see Section 3.2, has resulted in a destination no longer being reachable.=E2=80=9D =20 I would rather not have this special case.=C2=A0 Just leave it to Destination D= own to convey loss of reachability.=C2=A0 I=E2=80=99ve worked on systems that had mult= iple different ways of indicating a node was down, and it leads to bugs, esp= ecially when the down indications are not closely synchronized.=C2=A0 Part of th= e system thinks a node is up, part thinks it=E2=80=99s down, and chaos ensues. =20 Section 3.2 paragraph 4 =E2=80=9COnce the change is made, or fails or is rejected, the modem MUST respond with a Link Characteristics Request Message=E2=80=A6=E2=80=9D =20 Should this have said Response Message? =20 Section 3.2 paragraph 5 I think a Session Update message should be replied to with a Session Update= Response, and a Link Characteristics Request message with a Link Characteri= stics Response.=C2=A0 The text has both of these being replied to with a Link Ch= aracteristics Request message. =20 Sections 3.2.2 Terminate and 3.2.3 Direct Connection These seem to be a way for the router to tell the modem how important it is= to be able to communicate with specific destinations.=C2=A0 If that was the mot= ivation, perhaps a more direct expression of that information would be bette= r.=C2=A0 For example, the router could provide a list of destinations, ordered b= y importance.=C2=A0 I worry that the router giving low-level directions to the m= odem about which links to maintain might be difficult or suboptimal for some= radios. =20 Section 3.2.4 Suppress Forwarding What exactly is meant by suppressing multi-hop forwarding here?=C2=A0 Is it: a) If the router sends data (over the data plane) to a destination, and tha= t destination has a hop count > 1, the directly connected modem should drop = the data. b) The modem should discontinue forwarding of all data whose destination is= more than one hop away, regardless of where the data came from.=C2=A0 E.g., the= modem might be running a manet protocol, and the data could come over-the-a= ir from another modem. c) something else? =20 I think it=E2=80=99s probably a), but if so, couldn=E2=80=99t the router arrange its fo= rwarding tables to drop such packets itself instead of asking the modem to d= o it? =20 Thanks, David =20 =20 From: manet on behalf of Justin Dean Date: Tuesday, January 23, 2018 at 11:30 AM To: MANET IETF Subject: [manet] Last call ending =20 Working group last call is ending on both =20 =20 https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ =20 Please get your comments in. =20 Justin Dean --B_3599719634_670375707 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I think the latency extension is in = reasonable shape.=C2=A0 I agree with all of Vicky=E2=80=99s recent comments.

 

Here are som= e comments on the Multi-Hop extension.

 

Section 3.1

=E2=80=9C=E2=80=A6each hop represents a transmission and the number of hops is=

equal to the number of transmissions required t= o go from a router

connected modem to the d= estination's connected modem.=E2=80=9D

 = ;

So hops are counted starting at the modem that= is the DLEP peer of the router.=C2=A0 But then:

 

=E2=80=9CThe minimum number of hops is 1= , which represents the router's locally connected modem.=E2=80=9D

 

If counting starts = at that modem, wouldn=E2=80=99t hop count be 0 for the modem?=C2=A0 If it=E2=80=99s 1, this = seems to mean that the (typically) wired link between the router and the mod= em is being counted.=C2=A0 I think the two quotes above are inconsistent about w= hether this first link counts as a hop.=C2=A0 If the hop count was meant to conv= ey over-the-air hops, then the router=E2=80=99s locally connected modem should hav= e a hop count of 0.

 

=E2=80=9CA value of zero (0) is used to indicated that processing= of a Hop

Control action, see Section 3.2, = has resulted in a destination no

longer bei= ng reachable.=E2=80=9D

 

I would rather not have this special case.=C2=A0 Just leave it to = Destination Down to convey loss of reachability.=C2=A0 I=E2=80=99ve worked on systems = that had multiple different ways of indicating a node was down, and it leads= to bugs, especially when the down indications are not closely synchronized.= =C2=A0 Part of the system thinks a node is up, part thinks it=E2=80=99s down, and chao= s ensues.

 

Section 3.2 paragraph 4

=E2=80=9COnce the = change is made, or fails or is rejected, the modem

MUST respond with a Link Characteristics Request Message=E2=80=A6=E2=80=9D<= /o:p>

 

Should t= his have said Response Message?

 =

Section 3.2 paragraph 5

I think a Session Update message should be replied to with a Sessi= on Update Response, and a Link Characteristics Request message with a Link C= haracteristics Response.=C2=A0 The text has both of these being replied to with = a Link Characteristics Request message.

 

Sections 3.2.2 Terminate and 3.2.3 Dire= ct Connection

These seem to be a way for th= e router to tell the modem how important it is to be able to communicate wit= h specific destinations.=C2=A0 If that was the motivation, perhaps a more direct= expression of that information would be better.=C2=A0 For example, the router c= ould provide a list of destinations, ordered by importance.=C2=A0 I worry that t= he router giving low-level directions to the modem about which links to main= tain might be difficult or suboptimal for some radios.

 

Section 3.2.4 Suppress F= orwarding

What exactly is meant by suppress= ing multi-hop forwarding here?=C2=A0 Is it:

a) = If the router sends data (over the data plane) to a destination, and that de= stination has a hop count > 1, the directly connected modem should drop t= he data.

b) The modem should discontinue fo= rwarding of all data whose destination is more than one hop away, regardless= of where the data came from.=C2=A0 E.g., the modem might be running a manet pro= tocol, and the data could come over-the-air from another modem.

c) something else?

 

I think it=E2=80=99s probably a), but if so, = couldn=E2=80=99t the router arrange its forwarding tables to drop such packets its= elf instead of asking the modem to do it?

<= o:p> 

Thanks,

David

 

 

From: manet <manet-bounces@ietf.org> on beha= lf of Justin Dean <bebemaster@gmail.com>
Date: Tuesday, Janu= ary 23, 2018 at 11:30 AM
To: MANET IETF <manet@ietf.org>
= Subject: [manet] Last call ending

 

--B_3599719634_670375707-- --B_3599719634_275014239 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBRJHWiM810tUuJHAsDLNuVz1cGe0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAxMjUxNTA3MTRaMA0GCSqGSIb3DQEBAQUABIIBAFOHs+zQ6A7gZnRH YUVa95VFpR7+q6Q7C3Guokf2OC5qtTDjNLytgfNCrOcjAatlZwFxJjlmXZyyUnf0qFkzucIu tKJM8XGNInj87BHmfiqe8Q6q0se+tK2TCmoPwkITJ9xxjoyIcVnb7XpPzbBSLqYjcZHvtP/Y NHMN6hfAnU2xTyJoTUwLKSZgKkQvnnCXK1m8yIbkW8nc1QDsBh0xJswSBwe9c8WJEMgJr1CH ULXk//Bn00qLYG+YI94Snf8hGxY4TUC3fMkI6NUKRyG61C1W1gLb1FhbIuqlL2Z5QmOXWHWx bSNHnC6I4RCjZnytVSKTUu2+CbW1AMrO4gKtX7k= --B_3599719634_275014239-- From nobody Thu Jan 25 07:54:00 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D3126C89 for ; Thu, 25 Jan 2018 07:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 QrGjDsj0YvD5 for ; Thu, 25 Jan 2018 07:53:56 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3DC126BF7 for ; Thu, 25 Jan 2018 07:53:56 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Thu, 25 Jan 2018 15:53:48 +0000 From: Rick Taylor To: "David.Wiggins@ll.mit.edu" , "bebemaster@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGdo2JPTi3esRkioCkw1NygE6qOEs4kAgAANAwA= Date: Thu, 25 Jan 2018 15:53:44 +0000 Message-ID: <1516895624.4203.10.camel@tropicalstormsoftware.com> References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> In-Reply-To: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <91dfcfb6-148e-4d5d-8a34-56ddcaf717f2> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 15:53:59 -0000 SSBhZ3JlZSB3aXRoIFZpY2t5IGFuZCBEYXZpZCAtIEJvdGggZHJhZnRzIGFyZSBpbiBwcmV0dHkg Z29vZCBzaGFwZSwNCmJhciBzb21lIHR5cG9zLCBhbmQgdGhlIGhvcCBjb3VudC4NCg0KSSdtIHdp dGggRGF2aWQgb24gaG9wIGNvdW50IGlzc3Vlcy4gSSdtIG5vdCBzdXJlIHRoZSBsb2NhbCBsaW5r IGJldHdlZW4NCnJvdXRlciBhbmQgbW9kZW0gc2hvdWxkIGNvdW50IGFzIGEgaG9wLCBpZiBpdCBk b2VzIHRoZW4gdGhlIHNpbXBsZXN0DQpuZXR3b3JrIHN0YXJ0cyB3aXRoIDMgaG9wcy4gIEkgd291 bGQgb25seSBjb3VudCBob3BzICpiZXR3ZWVuKiBtb2RlbXMsDQphcyBETEVQIGlzIHJlYWxseSBv bmx5IGFib3V0IHdoYXQgaGFwcGVucyBiZXR3ZWVuIG1vZGVtcy4gIEkgZG9uJ3Qgc2VlDQpiZW5l Zml0IGluIGNvdW50aW5nIHRoZSBsb2NhbCBzd2l0Y2hlcyBiZXR3ZWVuIHRoZSByb3V0ZXIgYW5k IHRoZQ0KbW9kZW0uDQoNClJpY2sNCg0KT24gVGh1LCAyMDE4LTAxLTI1IGF0IDE1OjA3ICswMDAw LCBXaWdnaW5zLCBEYXZpZCAtIDA2NjUgLSBNSVRMTCB3cm90ZToNCj4gSSB0aGluayB0aGUgbGF0 ZW5jeSBleHRlbnNpb24gaXMgaW4gcmVhc29uYWJsZSBzaGFwZS4gIEkgYWdyZWUgd2l0aA0KPiBh bGwgb2YgVmlja3nigJlzIHJlY2VudCBjb21tZW50cy4NCj4gIA0KPiBIZXJlIGFyZSBzb21lIGNv bW1lbnRzIG9uIHRoZSBNdWx0aS1Ib3AgZXh0ZW5zaW9uLg0KPiAgDQo+IFNlY3Rpb24gMy4xDQo+ IOKAnOKApmVhY2ggaG9wIHJlcHJlc2VudHMgYSB0cmFuc21pc3Npb24gYW5kIHRoZSBudW1iZXIg b2YgaG9wcyBpcw0KPiBlcXVhbCB0byB0aGUgbnVtYmVyIG9mIHRyYW5zbWlzc2lvbnMgcmVxdWly ZWQgdG8gZ28gZnJvbSBhIHJvdXRlcg0KPiBjb25uZWN0ZWQgbW9kZW0gdG8gdGhlIGRlc3RpbmF0 aW9uJ3MgY29ubmVjdGVkIG1vZGVtLuKAnQ0KPiAgDQo+IFNvIGhvcHMgYXJlIGNvdW50ZWQgc3Rh cnRpbmcgYXQgdGhlIG1vZGVtIHRoYXQgaXMgdGhlIERMRVAgcGVlciBvZg0KPiB0aGUgcm91dGVy LiAgQnV0IHRoZW46DQo+ICANCj4g4oCcVGhlIG1pbmltdW0gbnVtYmVyIG9mIGhvcHMgaXMgMSwg d2hpY2ggcmVwcmVzZW50cyB0aGUgcm91dGVyJ3MNCj4gbG9jYWxseSBjb25uZWN0ZWQgbW9kZW0u 4oCdDQo+ICANCj4gSWYgY291bnRpbmcgc3RhcnRzIGF0IHRoYXQgbW9kZW0sIHdvdWxkbuKAmXQg aG9wIGNvdW50IGJlIDAgZm9yIHRoZQ0KPiBtb2RlbT8gIElmIGl04oCZcyAxLCB0aGlzIHNlZW1z IHRvIG1lYW4gdGhhdCB0aGUgKHR5cGljYWxseSkgd2lyZWQgbGluaw0KPiBiZXR3ZWVuIHRoZSBy b3V0ZXIgYW5kIHRoZSBtb2RlbSBpcyBiZWluZyBjb3VudGVkLiAgSSB0aGluayB0aGUgdHdvDQo+ IHF1b3RlcyBhYm92ZSBhcmUgaW5jb25zaXN0ZW50IGFib3V0IHdoZXRoZXIgdGhpcyBmaXJzdCBs aW5rIGNvdW50cyBhcw0KPiBhIGhvcC4gIElmIHRoZSBob3AgY291bnQgd2FzIG1lYW50IHRvIGNv bnZleSBvdmVyLXRoZS1haXIgaG9wcywgdGhlbg0KPiB0aGUgcm91dGVy4oCZcyBsb2NhbGx5IGNv bm5lY3RlZCBtb2RlbSBzaG91bGQgaGF2ZSBhIGhvcCBjb3VudCBvZiAwLg0KPiAgDQo+IOKAnEEg dmFsdWUgb2YgemVybyAoMCkgaXMgdXNlZCB0byBpbmRpY2F0ZWQgdGhhdCBwcm9jZXNzaW5nIG9m IGEgSG9wDQo+IENvbnRyb2wgYWN0aW9uLCBzZWUgU2VjdGlvbiAzLjIsIGhhcyByZXN1bHRlZCBp biBhIGRlc3RpbmF0aW9uIG5vDQo+IGxvbmdlciBiZWluZyByZWFjaGFibGUu4oCdDQo+ICANCj4g SSB3b3VsZCByYXRoZXIgbm90IGhhdmUgdGhpcyBzcGVjaWFsIGNhc2UuICBKdXN0IGxlYXZlIGl0 IHRvDQo+IERlc3RpbmF0aW9uIERvd24gdG8gY29udmV5IGxvc3Mgb2YgcmVhY2hhYmlsaXR5LiAg SeKAmXZlIHdvcmtlZCBvbg0KPiBzeXN0ZW1zIHRoYXQgaGFkIG11bHRpcGxlIGRpZmZlcmVudCB3 YXlzIG9mIGluZGljYXRpbmcgYSBub2RlIHdhcw0KPiBkb3duLCBhbmQgaXQgbGVhZHMgdG8gYnVn cywgZXNwZWNpYWxseSB3aGVuIHRoZSBkb3duIGluZGljYXRpb25zIGFyZQ0KPiBub3QgY2xvc2Vs eSBzeW5jaHJvbml6ZWQuICBQYXJ0IG9mIHRoZSBzeXN0ZW0gdGhpbmtzIGEgbm9kZSBpcyB1cCwN Cj4gcGFydCB0aGlua3MgaXTigJlzIGRvd24sIGFuZCBjaGFvcyBlbnN1ZXMuDQo+ICANCj4gU2Vj dGlvbiAzLjIgcGFyYWdyYXBoIDQNCj4g4oCcT25jZSB0aGUgY2hhbmdlIGlzIG1hZGUsIG9yIGZh aWxzIG9yIGlzIHJlamVjdGVkLCB0aGUgbW9kZW0NCj4gTVVTVCByZXNwb25kIHdpdGggYSBMaW5r IENoYXJhY3RlcmlzdGljcyBSZXF1ZXN0IE1lc3NhZ2XigKbigJ0NCj4gIA0KPiBTaG91bGQgdGhp cyBoYXZlIHNhaWQgUmVzcG9uc2UgTWVzc2FnZT8NCj4gIA0KPiBTZWN0aW9uIDMuMiBwYXJhZ3Jh cGggNQ0KPiBJIHRoaW5rIGEgU2Vzc2lvbiBVcGRhdGUgbWVzc2FnZSBzaG91bGQgYmUgcmVwbGll ZCB0byB3aXRoIGEgU2Vzc2lvbg0KPiBVcGRhdGUgUmVzcG9uc2UsIGFuZCBhIExpbmsgQ2hhcmFj dGVyaXN0aWNzIFJlcXVlc3QgbWVzc2FnZSB3aXRoIGENCj4gTGluayBDaGFyYWN0ZXJpc3RpY3Mg UmVzcG9uc2UuICBUaGUgdGV4dCBoYXMgYm90aCBvZiB0aGVzZSBiZWluZw0KPiByZXBsaWVkIHRv IHdpdGggYSBMaW5rIENoYXJhY3RlcmlzdGljcyBSZXF1ZXN0IG1lc3NhZ2UuDQo+ICANCj4gU2Vj dGlvbnMgMy4yLjIgVGVybWluYXRlIGFuZCAzLjIuMyBEaXJlY3QgQ29ubmVjdGlvbg0KPiBUaGVz ZSBzZWVtIHRvIGJlIGEgd2F5IGZvciB0aGUgcm91dGVyIHRvIHRlbGwgdGhlIG1vZGVtIGhvdyBp bXBvcnRhbnQNCj4gaXQgaXMgdG8gYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRoIHNwZWNpZmlj IGRlc3RpbmF0aW9ucy4gIElmIHRoYXQNCj4gd2FzIHRoZSBtb3RpdmF0aW9uLCBwZXJoYXBzIGEg bW9yZSBkaXJlY3QgZXhwcmVzc2lvbiBvZiB0aGF0DQo+IGluZm9ybWF0aW9uIHdvdWxkIGJlIGJl dHRlci4gIEZvciBleGFtcGxlLCB0aGUgcm91dGVyIGNvdWxkIHByb3ZpZGUgYQ0KPiBsaXN0IG9m IGRlc3RpbmF0aW9ucywgb3JkZXJlZCBieSBpbXBvcnRhbmNlLiAgSSB3b3JyeSB0aGF0IHRoZSBy b3V0ZXINCj4gZ2l2aW5nIGxvdy1sZXZlbCBkaXJlY3Rpb25zIHRvIHRoZSBtb2RlbSBhYm91dCB3 aGljaCBsaW5rcyB0bw0KPiBtYWludGFpbiBtaWdodCBiZSBkaWZmaWN1bHQgb3Igc3Vib3B0aW1h bCBmb3Igc29tZSByYWRpb3MuDQo+ICANCj4gU2VjdGlvbiAzLjIuNCBTdXBwcmVzcyBGb3J3YXJk aW5nDQo+IFdoYXQgZXhhY3RseSBpcyBtZWFudCBieSBzdXBwcmVzc2luZyBtdWx0aS1ob3AgZm9y d2FyZGluZyBoZXJlPyAgSXMNCj4gaXQ6DQo+IGEpIElmIHRoZSByb3V0ZXIgc2VuZHMgZGF0YSAo b3ZlciB0aGUgZGF0YSBwbGFuZSkgdG8gYSBkZXN0aW5hdGlvbiwNCj4gYW5kIHRoYXQgZGVzdGlu YXRpb24gaGFzIGEgaG9wIGNvdW50ID4gMSwgdGhlIGRpcmVjdGx5IGNvbm5lY3RlZA0KPiBtb2Rl bSBzaG91bGQgZHJvcCB0aGUgZGF0YS4NCj4gYikgVGhlIG1vZGVtIHNob3VsZCBkaXNjb250aW51 ZSBmb3J3YXJkaW5nIG9mIGFsbCBkYXRhIHdob3NlDQo+IGRlc3RpbmF0aW9uIGlzIG1vcmUgdGhh biBvbmUgaG9wIGF3YXksIHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgdGhlIGRhdGENCj4gY2FtZSBmcm9t LiAgRS5nLiwgdGhlIG1vZGVtIG1pZ2h0IGJlIHJ1bm5pbmcgYSBtYW5ldCBwcm90b2NvbCwgYW5k DQo+IHRoZSBkYXRhIGNvdWxkIGNvbWUgb3Zlci10aGUtYWlyIGZyb20gYW5vdGhlciBtb2RlbS4N Cj4gYykgc29tZXRoaW5nIGVsc2U/DQo+ICANCj4gSSB0aGluayBpdOKAmXMgcHJvYmFibHkgYSks IGJ1dCBpZiBzbywgY291bGRu4oCZdCB0aGUgcm91dGVyIGFycmFuZ2UgaXRzDQo+IGZvcndhcmRp bmcgdGFibGVzIHRvIGRyb3Agc3VjaCBwYWNrZXRzIGl0c2VsZiBpbnN0ZWFkIG9mIGFza2luZyB0 aGUNCj4gbW9kZW0gdG8gZG8gaXQ/DQo+ICANCj4gVGhhbmtzLA0KPiBEYXZpZA0KPiAgDQo+ICAN Cj4gRnJvbTogbWFuZXQgPG1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKdXN0 aW4gRGVhbiA8YmViZW1hDQo+IHN0ZXJAZ21haWwuY29tPg0KPiBEYXRlOiBUdWVzZGF5LCBKYW51 YXJ5IDIzLCAyMDE4IGF0IDExOjMwIEFNDQo+IFRvOiBNQU5FVCBJRVRGIDxtYW5ldEBpZXRmLm9y Zz4NCj4gU3ViamVjdDogW21hbmV0XSBMYXN0IGNhbGwgZW5kaW5nDQo+ICANCj4gV29ya2luZyBn cm91cCBsYXN0IGNhbGwgaXMgZW5kaW5nIG9uIGJvdGggDQo+ICANCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLWxhdGVuY3ktZXh0ZW5zDQo+ IGlvbi8NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5l dC1kbGVwLW11bHRpLWhvcC1leHRlDQo+IG5zaW9uLw0KPiAgDQo+IFBsZWFzZSBnZXQgeW91ciBj b21tZW50cyBpbi4NCj4gIA0KPiBKdXN0aW4gRGVhbg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA== From nobody Thu Jan 25 08:12:09 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57D126B6D for ; Thu, 25 Jan 2018 08:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sXRhNbVgq9ep for ; Thu, 25 Jan 2018 08:12:01 -0800 (PST) Received: from isabel.astrium.eads.net (isabel.astrium.eads.net [194.62.210.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F02120727 for ; Thu, 25 Jan 2018 08:12:00 -0800 (PST) Received: from rosout.astrium.eads.net ([10.222.0.6]) by isabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id w0PGBv7d028065; Thu, 25 Jan 2018 16:11:57 GMT Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E47C020806D; Thu, 25 Jan 2018 16:11:57 +0000 (GMT) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id D9BC8208063; Thu, 25 Jan 2018 16:11:57 +0000 (GMT) X-IMSS-HAND-OFF-DIRECTIVE: 127.0.0.1:10026 Received: from AUK52839.UKN.UKNROOT.ASTRIUM.CORP (unknown [10.221.1.32]) by rosout.astrium.eads.net (Postfix) with ESMTPS id F1B102080D0; Thu, 25 Jan 2018 16:11:47 +0000 (GMT) Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52839.UKN.UKNROOT.ASTRIUM.CORP ([fe80::cdf2:d214:a3a9:7510%15]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 16:11:47 +0000 From: "MATTY, Steven [UK]" To: "'Rick Taylor'" , "David.Wiggins@ll.mit.edu" , "bebemaster@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGdokQQGhhED7EOftJ199yj3v6OEs4kAgAANAwCAAARSAA== Date: Thu, 25 Jan 2018 16:11:46 +0000 Message-ID: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <26401_1516895646_5A69FD9D_26401_12571_4_1516895624.4203.10.camel@tropicalstormsoftware.com> In-Reply-To: <26401_1516895646_5A69FD9D_26401_12571_4_1516895624.4203.10.camel@tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-9.0.0.1549-8.2.0.1013-23620.000 X-TM-AS-Result: No--2.509-5.0-31-10 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-imss-scan-details: No--2.509-5.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1549-8.2.1013-23620.000 X-TMASE-Result: 10--2.508900-10.000000 X-TMASE-MatchedRID: 7ySqCuYCpfg4HKI/yaqRm521GZGE81yGkjzeBMkH274wplGJ7NxS01+j /FHr72r/UhZh3gmmvoTW94uaWqno1rsl8Gv1eXkKcoieJFjVCFzYt94bS4N+VCfO9H6Y/dy+Kk6 C52OIvQPmj+ti9Uv6J5GTpe1iiCJq0u+wqOGzSV07qnMAZEGUXNmzcdRxL+xwKrauXd3MZDUal5 68aygjl1piTupTjGn5FeG+sqbjhX6UDUVyRtF6tgCb/w+jGO87T9o5/Ic8180WIJR2gwHg5/EWx FRuVzkJxSbYCvm7DBBSUeYGMDpB0q41ycoS4GiPX9LS5J2a9IqM/R8zlu8uIg7cNPEVHiCDftwZ 3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0,39:0-0 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 16:12:08 -0000 PkknbSB3aXRoIERhdmlkIG9uIGhvcCBjb3VudCBpc3N1ZXMuIEknbSBub3Qgc3VyZSB0aGUgbG9j YWwgbGluayBiZXR3ZWVuDQo+cm91dGVyIGFuZCBtb2RlbSBzaG91bGQgY291bnQgYXMgYSBob3As IGlmIGl0IGRvZXMgdGhlbiB0aGUgc2ltcGxlc3QNCj5uZXR3b3JrIHN0YXJ0cyB3aXRoIDMgaG9w cy4gIEkgd291bGQgb25seSBjb3VudCBob3BzICpiZXR3ZWVuKiBtb2RlbXMsDQo+YXMgRExFUCBp cyByZWFsbHkgb25seSBhYm91dCB3aGF0IGhhcHBlbnMgYmV0d2VlbiBtb2RlbXMuICBJIGRvbid0 IHNlZQ0KPmJlbmVmaXQgaW4gY291bnRpbmcgdGhlIGxvY2FsIHN3aXRjaGVzIGJldHdlZW4gdGhl IHJvdXRlciBhbmQgdGhlDQo+bW9kZW0uDQo+DQo+Umljaw0KDQpUaGVyZSBpcyB0aGUgcG9zc2li aWxpdHkgdGhhdCBhIERMRVAgcm91dGVyICYgbW9kZW0gY291bGQgZXhpc3QgaW4gdGhlDQpzYW1l IHBsYXRmb3JtIHdpdGggbm8gd2lyZXMgYmV0d2VlbiB0aGVtIGF0IGFsbCAoYnV0IG1lcmVseSBk aWZmZXJlbnQgbG9naWNhbCBpbnRlcmZhY2VzLCBpZiB0aGF0KQ0Kd2hpY2ggY291bGQgb25seSBh ZGQgdG8gdGhlIGNvbmZ1c2lvbi4uLg0KDQpTdGV2ZQ0KDQpUaGlzIGVtYWlsIChpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gb3IgaW5mb3JtYXRpb24gb3RoZXJ3aXNlIHByb3RlY3RlZCBmcm9tIGRp c2Nsb3N1cmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZG8gbm90IGNvcHkgdGhpcyBtZXNzYWdlIG9y IGFueSBhdHRhY2htZW50cyBhbmQgZG8gbm90IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugb3IgZGlz Y2xvc2UgaXRzIGNvbnRlbnQgdG8gYW55IHBlcnNvbiwgYnV0IGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGFueSBhdHRhY2htZW50cyBmcm9tIHlvdXIgc3lzdGVtLiBBaXJidXMgRGVmZW5jZSBhbmQg U3BhY2UgTGltaXRlZCBkaXNjbGFpbXMgYW55IGFuZCBhbGwgbGlhYmlsaXR5IGlmIHRoaXMgZW1h aWwgdHJhbnNtaXNzaW9uIHdhcyB2aXJ1cyBjb3JydXB0ZWQsIGFsdGVyZWQgb3IgZmFsc2lmaWVk Lg0KLW8tDQpFbWFpbHMgdG8gQWlyYnVzIERlZmVuY2UgYW5kIFNwYWNlIExpbWl0ZWQgbWF5IGJl IHByb2Nlc3NlZCwgcmVjb3JkZWQgYW5kIG1vbml0b3JlZCBvdXRzaWRlIHRoZSBVSy4NCi1vLQ0K QWlyYnVzIERlZmVuY2UgYW5kIFNwYWNlIExpbWl0ZWQsIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBh bmQgV2FsZXMgTm8uIDI0NDkyNTkNClJlZ2lzdGVyZWQgT2ZmaWNlOiBHdW5uZWxzIFdvb2QgUm9h ZCwgU3RldmVuYWdlLCBIZXJ0Zm9yZHNoaXJlLCBTRzEgMkFTLCBFbmdsYW5k From nobody Thu Jan 25 10:32:04 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4374127275 for ; Thu, 25 Jan 2018 10:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jLKLlcqXM-Zk for ; Thu, 25 Jan 2018 10:31:59 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681F612711D for ; Thu, 25 Jan 2018 10:31:59 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id d13so9618576iog.5 for ; Thu, 25 Jan 2018 10:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FThHgTptr7EvkMm+xNhjkdgOFdVN5PqjDWHTgPlr/XI=; b=QEm5O6G5UOo+GEwazBSO6/tqhBOxAa4hxBLulwZj9I8zdoTV2B/QCzusLp14oIwX3M DGs6BZSmTBWgx3gxxG3Xj1Y/l0U4+zygO4Oixo1UvdbHwNrKvwlJYMTd05kW/BBff4rp FKJ0C4lszIxxi5jx30IEyGCmdbMpS9tOS0Rox6ftd8/VCpfiGtVNhcWMM78DU0pw0z5B EDPuXlp2QRT3jSZZue32xBm2DnbixHEAGfOJKTcCECaTuy29/e3o5FahV+X5oqHCoK6s uStuZa9wwK2LcTAhiWP/hoxzOObel3wwJEBD14K1RqGbX7sgskNoXUS9y+ufdfHAYWFR DHlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FThHgTptr7EvkMm+xNhjkdgOFdVN5PqjDWHTgPlr/XI=; b=SYspAs8v2g7nt4q/Hu5tqYD1YwEeCBrgfe4fAnUaXuFUCOOF67tMPOTKGdUcDmnuGV mVEgkowznVQFFhEnk3ti7mfjqidr9gzRY5jFmWQN9ytrHMNE7k3qLM7zG1j7omYNbruj lfLYPpQHI0kvocJfcRh89OOiaWLm2qq3GYE2p7l9PXxPcgitb6v1AWztTrgbHOZyNvR4 TGBtYffrsGEd1ci+DCBGWCEgP0r/QrUqOc40fQH7wqsPO1aeOYHIR3u7kbr0TllpfOBV JnAOGdgHeT+WYKQNyJbkQj+2ax7dzKqAoN5dvWOAIhs/1H7Lc48Dn+eYVqip6+bhXIlf G/Tw== X-Gm-Message-State: AKwxytdmXEjbytGADKdDroLW6Kd2pToZQ6+QIy50mQQrTmBw68eQ8GeO HwL1N3xFH4XAzPL1G7yOx7DZBNXOizEvnzC8Mfc= X-Google-Smtp-Source: AH8x224g85p/NxzGeT/b4S0Rhpocd82ZuUFJU2gsXsNy0nC+N7mQVma4oWx1A1OJ53ma3FlXjwKuxt85HjIdcSB9Sz4= X-Received: by 10.107.5.18 with SMTP id 18mr14861853iof.153.1516905118439; Thu, 25 Jan 2018 10:31:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.109.87 with HTTP; Thu, 25 Jan 2018 10:31:58 -0800 (PST) In-Reply-To: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> From: Stan Ratliff Date: Thu, 25 Jan 2018 13:31:58 -0500 Message-ID: To: "Wiggins, David - 0665 - MITLL" Cc: Justin Dean , MANET IETF Content-Type: multipart/alternative; boundary="001a113ee9eebe1e7905639dfed5" Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 18:32:03 -0000 --001a113ee9eebe1e7905639dfed5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! One question/issue inline: On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL < David.Wiggins@ll.mit.edu> wrote: > I think the latency extension is in reasonable shape. I agree with all o= f > Vicky=E2=80=99s recent comments. > > > > Here are some comments on the Multi-Hop extension. > > > > Section 3.1 > > =E2=80=9C=E2=80=A6each hop represents a transmission and the number of ho= ps is > > equal to the number of transmissions required to go from a router > > connected modem to the destination's connected modem.=E2=80=9D > > > > So hops are counted starting at the modem that is the DLEP peer of the > router. But then: > > > > =E2=80=9CThe minimum number of hops is 1, which represents the router's l= ocally > connected modem.=E2=80=9D > > > > If counting starts at that modem, wouldn=E2=80=99t hop count be 0 for the= modem? > If it=E2=80=99s 1, this seems to mean that the (typically) wired link bet= ween the > router and the modem is being counted. I think the two quotes above are > inconsistent about whether this first link counts as a hop. If the hop > count was meant to convey over-the-air hops, then the router=E2=80=99s lo= cally > connected modem should have a hop count of 0. > > > > =E2=80=9CA value of zero (0) is used to indicated that processing of a Ho= p > > Control action, see Section 3.2, has resulted in a destination no > > longer being reachable.=E2=80=9D > > > > I would rather not have this special case. Just leave it to Destination > Down to convey loss of reachability. I=E2=80=99ve worked on systems that= had > multiple different ways of indicating a node was down, and it leads to > bugs, especially when the down indications are not closely synchronized. > Part of the system thinks a node is up, part thinks it=E2=80=99s down, an= d chaos > ensues. > > > > Section 3.2 paragraph 4 > > =E2=80=9COnce the change is made, or fails or is rejected, the modem > > MUST respond with a Link Characteristics Request Message=E2=80=A6=E2=80= =9D > > > > Should this have said Response Message? > > > > Section 3.2 paragraph 5 > > I think a Session Update message should be replied to with a Session > Update Response, and a Link Characteristics Request message with a Link > Characteristics Response. The text has both of these being replied to wi= th > a Link Characteristics Request message. > > > > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > These seem to be a way for the router to tell the modem how important it > is to be able to communicate with specific destinations. If that was the > motivation, perhaps a more direct expression of that information would be > better. For example, the router could provide a list of destinations, > ordered by importance. I worry that the router giving low-level directio= ns > to the modem about which links to maintain might be difficult or suboptim= al > for some radios. > > > > Section 3.2.4 Suppress Forwarding > > What exactly is meant by suppressing multi-hop forwarding here? Is it: > > a) If the router sends data (over the data plane) to a destination, and > that destination has a hop count > 1, the directly connected modem should > drop the data. > > b) The modem should discontinue forwarding of all data whose destination > is more than one hop away, regardless of where the data came from. E.g., > the modem might be running a manet protocol, and the data could come > over-the-air from another modem. > > c) something else? > If the answer is "a", then isn't that really "Destination Down"? What is the use case for suppressing multi-hop forwarding in the first place? It almost seems counter to the basic appeal of mesh radios. Regards, Stan > > > I think it=E2=80=99s probably a), but if so, couldn=E2=80=99t the router = arrange its > forwarding tables to drop such packets itself instead of asking the modem > to do it? > > > > Thanks, > > David > > > > > > *From: *manet on behalf of Justin Dean < > bebemaster@gmail.com> > *Date: *Tuesday, January 23, 2018 at 11:30 AM > *To: *MANET IETF > *Subject: *[manet] Last call ending > > > > Working group last call is ending on both > > > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep- > multi-hop-extension/ > > > > Please get your comments in. > > > > Justin Dean > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113ee9eebe1e7905639dfed5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

One question/issue inline:=C2=A0

On Thu, Jan 25= , 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL <David.Wiggins@ll= .mit.edu> wrote:

I think the late= ncy extension is in reasonable shape.=C2=A0 I agree with all of Vicky=E2=80= =99s recent comments.

=C2=A0=

Here are some comments on the Multi-Hop e= xtension.

=C2=A0

<= p class=3D"MsoNormal">Section 3.1

= =E2=80=9C=E2=80=A6each hop represents a transmission and the number of hops= is

equal to the number of transmis= sions required to go from a router

= connected modem to the destination's connected modem.=E2=80=9D

=C2=A0

So hops are counted starting at the modem that is the DLEP peer of the = router.=C2=A0 But then:

=C2= =A0

=E2=80=9CThe minimum number of hops is= 1, which represents the router's locally connected modem.=E2=80=9D<= /u>

=C2=A0

If counting starts at that modem, wouldn=E2=80=99t hop count be 0 = for the modem?=C2=A0 If it=E2=80=99s 1, this seems to mean that the (typica= lly) wired link between the router and the modem is being counted.=C2=A0 I = think the two quotes above are inconsistent about whether this first link c= ounts as a hop.=C2=A0 If the hop count was meant to convey over-the-air hop= s, then the router=E2=80=99s locally connected modem should have a hop coun= t of 0.

=C2=A0

=E2=80=9CA value of zero (0) is used to indicated that = processing of a Hop

Control action,= see Section 3.2, has resulted in a destination no

longer being reachable.=E2=80=9D

=C2=A0

I would rathe= r not have this special case.=C2=A0 Just leave it to Destination Down to co= nvey loss of reachability.=C2=A0 I=E2=80=99ve worked on systems that had mu= ltiple different ways of indicating a node was down, and it leads to bugs, = especially when the down indications are not closely synchronized.=C2=A0 Pa= rt of the system thinks a node is up, part thinks it=E2=80=99s down, and ch= aos ensues.

=C2=A0

Section 3.2 paragraph 4

=E2=80=9COnce the change is made, or fails or is rejected, t= he modem

MUST respond with a Link C= haracteristics Request Message=E2=80=A6=E2=80=9D

=C2=A0

Should this h= ave said Response Message?

= =C2=A0

Section 3.2 paragraph 5

I think a Session Update message should be rep= lied to with a Session Update Response, and a Link Characteristics Request = message with a Link Characteristics Response.=C2=A0 The text has both of th= ese being replied to with a Link Characteristics Request message.=

=C2=A0

Sections 3.2.2 Terminate and 3.2.3 Direct Connection

These seem to be a way for the router to tell the mode= m how important it is to be able to communicate with specific destinations.= =C2=A0 If that was the motivation, perhaps a more direct expression of that= information would be better.=C2=A0 For example, the router could provide a= list of destinations, ordered by importance.=C2=A0 I worry that the router= giving low-level directions to the modem about which links to maintain mig= ht be difficult or suboptimal for some radios.

=C2=A0

Section 3.2.4 Su= ppress Forwarding

What exactly is m= eant by suppressing multi-hop forwarding here?=C2=A0 Is it:

a) If the router sends data (over the data plane) = to a destination, and that destination has a hop count > 1, the directly= connected modem should drop the data.

b) The modem should discontinue forwarding of all data whose destinatio= n is more than one hop away, regardless of where the data came from.=C2=A0 = E.g., the modem might be running a manet protocol, and the data could come = over-the-air from another modem.

c)= something else?


If the ans= wer is "a", then isn't that really "Destination Down&quo= t;? What is the use case for suppressing multi-hop forwarding in the first = place? It almost seems counter to the basic appeal of mesh radios.

Regards,
Stan

=C2=A0

= =C2=A0

I think it=E2=80=99s probably a), b= ut if so, couldn=E2=80=99t the router arrange its forwarding tables to drop= such packets itself instead of asking the modem to do it?

=C2=A0

Than= ks,

David

=C2=A0

=C2=A0=

From: manet <manet-bounces@ietf.org> on behalf of Justin= Dean <bebemas= ter@gmail.com>
Date: Tuesday, January 23, 2018 at 11:30 AM=
To: MANET IETF <manet@ietf.org>
Subject: [manet] Last call ending

=C2=A0

Working group last call is ending on both=C2=A0 <= u>

=C2= =A0

=C2=A0

Please get your comments in.

=

=C2=A0<= u>

Just= in Dean


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a113ee9eebe1e7905639dfed5-- From nobody Thu Jan 25 15:51:04 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7B12EB15 for ; Thu, 25 Jan 2018 15:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 yYTxZttUjX3T for ; Thu, 25 Jan 2018 15:50:58 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382D912EB11 for ; Thu, 25 Jan 2018 15:50:57 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id E728E175DFC for ; Thu, 25 Jan 2018 16:50:56 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 2nqt1x0042SSUrH01nqwx6; Thu, 25 Jan 2018 16:50:56 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=jnqYjTZluhsXpHKFDVMA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WgzIManUCwf2coDL4ypujFAUCscyehmFbm4K58dP++E=; b=E2m0Gk0Zzo7Ha3y+2vdcfxJXLH 8wvXVDJYHBXOEvSkFwPFX8s4aqBdxumBbzBmfQ0VxDAEXyi8lC9CS7lOshoO4ZZivEqrLxqZdF8Fu RYO+eEpw9CCADi0dMZ8uWOWqZ; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44688 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eerIC-001vHj-T7; Thu, 25 Jan 2018 16:50:52 -0700 To: Victoria Pritchard , Justin Dean Cc: MANET IETF References: <151182163087.13335.9898030294539351604@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Thu, 25 Jan 2018 18:50:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1eerIC-001vHj-T7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:44688 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] ready for LC : latency and multi-hop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 23:51:01 -0000 Vicky,     Thank you for the comments! On 1/21/2018 1:03 PM, Victoria Pritchard wrote: > Hi all, > > Just a few picky comments on the Latency Range draft. > > Title > Lantency -> Latency > thanks. > Abstract > Should you reference the DLEP RFC number here? Or at least expand the > acronym? > > Section 1 > It's "Dynamic Link Exchange Protocol" (not "Event Protocol") > Well that's embarrassing! Fixed in all extensions. > "provides an average latency" - the definition in RFC8175 actually > says "The calculation >    of latency is implementation dependent.  For example, the latency may >    be a running average calculated from the internal queuing." so not > sure it's right to say it provides an average. > how about:    The base DLEP specification includes the Latency metric which provides -  an average latency on a link.  This document adds the ability to relay +  a single latency value on a link, which is implementation dependent. +  This document adds the ability to relay > "one new DLEP >    Data Items" - unnecessary 's' on Items > Section 3 > Is it " Latency Range Item " or " Latency Range Data Item "? Makes > sense to be consistent > agreed. > Under the Maximum Latency field description: > "representing the transmission longest >       delay" > should that be "longest transmission delay"? > Similar comment for Minimum Latency > thanks! > Section 5.2 > "Data Item Type Values"  is the name of the registry in RFC8175. > fixed in all drafts! > > Regards, > Vicky > Thank you - changes have been pushed to the repo... > On 8 January 2018 at 21:46, Justin Dean > wrote: > > As discussed during IETF 100 these documents are now in last call. > Please review them and post comments to the list. > > > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01 > > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jan 25 16:33:09 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE83412D838 for ; Thu, 25 Jan 2018 16:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 6h_bm3u9ynhE for ; Thu, 25 Jan 2018 16:33:05 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1696912D832 for ; Thu, 25 Jan 2018 16:33:05 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 852DA1E06CA for ; Thu, 25 Jan 2018 17:33:01 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 2oYx1x00V2SSUrH01oZ0VR; Thu, 25 Jan 2018 17:33:01 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=B5tPVyTTY1-nc6APauUA:9 a=UrZQH8nvgS2ObaNg:21 a=ApypdAytk2UcYvS6:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QSGBUVwFBXPh6mrPe7MoPsBt/5ySQJT0elJCOakQiXQ=; b=DxqIBF6qZ4H+2lLj96npf+t8mC QBmyS3wQuJqveWysYHzdI5WMWEIqobUD1s/NBU71JcC2IxRqZTaOxNykUsXbz26Jh6Gp+sk+Cuhts Mjr6740JpwvsELa418HnXCzr4; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49946 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eerwv-002F8R-LT; Thu, 25 Jan 2018 17:32:57 -0700 To: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> From: Lou Berger Message-ID: Date: Thu, 25 Jan 2018 19:32:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1eerwv-002F8R-LT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:49946 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 00:33:08 -0000 On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote: > > I think the latency extension is in reasonable shape.  I agree with > all of Vicky’s recent comments. > > Here are some comments on the Multi-Hop extension. > > Section 3.1 > > “…each hop represents a transmission and the number of hops is > > equal to the number of transmissions required to go from a router > > connected modem to the destination's connected modem.” > > So hops are counted starting at the modem that is the DLEP peer of the > router. > yes, that's the intent. > But then: > > “The minimum number of hops is 1, which represents the router's > locally connected modem.” > how about "which represents the *transmission* by the router's locally connected modem."? > If counting starts at that modem, wouldn’t hop count be 0 for the modem? > I don't understand this.  Perhaps you mean for the hop between the router and the modem?  This extensions isn't intended to count router to modem hops. >   If it’s 1, this seems to mean that the (typically) wired link > between the router and the modem is being counted. > How so?  1 means a single transmission over the modem attached media (RF) channel . > I think the two quotes above are inconsistent about whether this first > link counts as a hop. If the hop count was meant to convey > over-the-air hops, then the router’s locally connected modem should > have a hop count of 0. > There is no destination for the locally connected modem, so zero would never be reported.  In what case do you see zero being reported? > “A value of zero (0) is used to indicated that processing of a Hop > > Control action, see Section 3.2, has resulted in a destination no > > longer being reachable.” > > I would rather not have this special case. Just leave it to > Destination Down to convey loss of reachability.  I’ve worked on > systems that had multiple different ways of indicating a node was > down, and it leads to bugs, especially when the down indications are > not closely synchronized.  Part of the system thinks a node is up, > part thinks it’s down, and chaos ensues. > I'd actually expect both a Destination Down, per normal processing which is not modified by this document, and a  Link Characteristics Request Message.  This is so there is consistent processing of  the Hop Control Data Item on both router and modem.  Otherwise there how will a router know that a particular Hop Control request has completed.  Having just a Destination Down would mean that the router would have to infer that this was due to the hop control when in fact it may be due to just some transitory affect.  In my experience leaving things to inference is a bad transaction model and leads to race condition bugs. So I'd prefer to leave as is. I've added a note to make it clear that the Destination Down is still sent. specifically:   Note that   normal DLEP processing is not otherwise modified by this document, this   includes the generation of Destination Down messages. > Section 3.2 paragraph 4 > > “Once the change is made, or fails or is rejected, the modem > > MUST respond with a Link Characteristics Request Message…” > > Should this have said Response Message? > yes > Section 3.2 paragraph 5 > > I think a Session Update message should be replied to with a Session > Update Response, and a Link Characteristics Request message with a > Link Characteristics Response.  The text has both of these being > replied to with a Link Characteristics Request message. > What information would you like carried in the Session Update Response message?  Note that a reset may result in a destination specific change. > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > These seem to be a way for the router to tell the modem how important > it is to be able to communicate with specific destinations. > I see this as the way to reverse/undo a 'Direct Connection'. > > If that was the motivation, perhaps a more direct expression of that > information would be better.  For example, the router could provide a > list of destinations, ordered by importance.  I worry that the router > giving low-level directions to the modem about which links to maintain > might be difficult or suboptimal for some radios. > How about: OLD    It indicates     that the modem SHOULD attempt to terminate communication     with the destination identified in the message. NEW    It indicates that a direct connection is no longer needed with the    the destination identified in the message. > > Section 3.2.4 Suppress Forwarding > > What exactly is meant by suppressing multi-hop forwarding here?  Is it: > > a) If the router sends data (over the data plane) to a destination, > and that destination has a hop count > 1, the directly connected modem > should drop the data. > > b) The modem should discontinue forwarding of all data whose > destination is more than one hop away, regardless of where the data > came from.  E.g., the modem might be running a manet protocol, and the > data could come over-the-air from another modem. > > c) something else? > > I think it’s probably a), > I read it as (a) and (b).  This does imply that the modem in a manet may need to alter it's route advertisement in that manet. > but if so, couldn’t the router arrange its forwarding tables to drop > such packets itself instead of asking the modem to do it? > That doesn't cover race conditions in case (a) or case (b) at all. Thank you for the comments! Lou > > Thanks, > > David > > *From: *manet on behalf of Justin Dean > > *Date: *Tuesday, January 23, 2018 at 11:30 AM > *To: *MANET IETF > *Subject: *[manet] Last call ending > > Working group last call is ending on both > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ > > Please get your comments in. > > Justin Dean > From nobody Thu Jan 25 16:36:39 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC96512D832 for ; Thu, 25 Jan 2018 16:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 AYdegK11LoRP for ; Thu, 25 Jan 2018 16:36:35 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B784C127078 for ; Thu, 25 Jan 2018 16:36:35 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 301DA215D23 for ; Thu, 25 Jan 2018 17:36:33 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 2ocV1x0082SSUrH01ocYMx; Thu, 25 Jan 2018 17:36:33 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=Wksqjl0uMja0SXiEeQYA:9 a=_UYe1Xzrnm7GKNQL:21 a=KkbdQf7KavUwMvve:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GgAOFa//N9p8NeKSuFXXoeaIUOn0ujoMD1j1vLlxBnQ=; b=ZmgrkPHYWzrrGtC83RY2ly3pop H3ivEvTBfDAe5dJqjbwPCyEAa2NUr7Fpi5J9lMnYDEk1fdKr+2ShlH5IsH7JzO3bk2GJhM2cbr62Z 1vPkYkndVykfo0x5B8AwbhkeC; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50430 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ees0L-002HYw-6F; Thu, 25 Jan 2018 17:36:29 -0700 To: Rick Taylor , "David.Wiggins@ll.mit.edu" , "bebemaster@gmail.com" , "manet@ietf.org" References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <1516895624.4203.10.camel@tropicalstormsoftware.com> From: Lou Berger Message-ID: Date: Thu, 25 Jan 2018 19:36:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516895624.4203.10.camel@tropicalstormsoftware.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1ees0L-002HYw-6F X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:50430 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 00:36:38 -0000 On 1/25/2018 10:53 AM, Rick Taylor wrote: > I agree with Vicky and David - Both drafts are in pretty good shape, > bar some typos, and the hop count. > > I'm with David on hop count issues. I'm not sure the local link between > router and modem should count as a hop, if it does then the simplest > network starts with 3 hops. I agree it should not and this was not the intent. > I would only count hops *between* modems, > as DLEP is really only about what happens between modems. I don't see > benefit in counting the local switches between the router and the > modem. 100% agree.  any suggestions on wording changes to improve clarity would be most appreciated! PS latest text can be found at: https://github.com/louberger/dlep-extensions Thanks, Lou > > Rick > > On Thu, 2018-01-25 at 15:07 +0000, Wiggins, David - 0665 - MITLL wrote: >> I think the latency extension is in reasonable shape. I agree with >> all of Vicky’s recent comments. >> >> Here are some comments on the Multi-Hop extension. >> >> Section 3.1 >> “…each hop represents a transmission and the number of hops is >> equal to the number of transmissions required to go from a router >> connected modem to the destination's connected modem.” >> >> So hops are counted starting at the modem that is the DLEP peer of >> the router. But then: >> >> “The minimum number of hops is 1, which represents the router's >> locally connected modem.” >> >> If counting starts at that modem, wouldn’t hop count be 0 for the >> modem? If it’s 1, this seems to mean that the (typically) wired link >> between the router and the modem is being counted. I think the two >> quotes above are inconsistent about whether this first link counts as >> a hop. If the hop count was meant to convey over-the-air hops, then >> the router’s locally connected modem should have a hop count of 0. >> >> “A value of zero (0) is used to indicated that processing of a Hop >> Control action, see Section 3.2, has resulted in a destination no >> longer being reachable.” >> >> I would rather not have this special case. Just leave it to >> Destination Down to convey loss of reachability. I’ve worked on >> systems that had multiple different ways of indicating a node was >> down, and it leads to bugs, especially when the down indications are >> not closely synchronized. Part of the system thinks a node is up, >> part thinks it’s down, and chaos ensues. >> >> Section 3.2 paragraph 4 >> “Once the change is made, or fails or is rejected, the modem >> MUST respond with a Link Characteristics Request Message…” >> >> Should this have said Response Message? >> >> Section 3.2 paragraph 5 >> I think a Session Update message should be replied to with a Session >> Update Response, and a Link Characteristics Request message with a >> Link Characteristics Response. The text has both of these being >> replied to with a Link Characteristics Request message. >> >> Sections 3.2.2 Terminate and 3.2.3 Direct Connection >> These seem to be a way for the router to tell the modem how important >> it is to be able to communicate with specific destinations. If that >> was the motivation, perhaps a more direct expression of that >> information would be better. For example, the router could provide a >> list of destinations, ordered by importance. I worry that the router >> giving low-level directions to the modem about which links to >> maintain might be difficult or suboptimal for some radios. >> >> Section 3.2.4 Suppress Forwarding >> What exactly is meant by suppressing multi-hop forwarding here? Is >> it: >> a) If the router sends data (over the data plane) to a destination, >> and that destination has a hop count > 1, the directly connected >> modem should drop the data. >> b) The modem should discontinue forwarding of all data whose >> destination is more than one hop away, regardless of where the data >> came from. E.g., the modem might be running a manet protocol, and >> the data could come over-the-air from another modem. >> c) something else? >> >> I think it’s probably a), but if so, couldn’t the router arrange its >> forwarding tables to drop such packets itself instead of asking the >> modem to do it? >> >> Thanks, >> David >> >> >> From: manet on behalf of Justin Dean > ster@gmail.com> >> Date: Tuesday, January 23, 2018 at 11:30 AM >> To: MANET IETF >> Subject: [manet] Last call ending >> >> Working group last call is ending on both >> >> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extens >> ion/ >> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-exte >> nsion/ >> >> Please get your comments in. >> >> Justin Dean >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jan 25 16:39:31 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9F12EB04 for ; Thu, 25 Jan 2018 16:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 wRa--jYE2ize for ; Thu, 25 Jan 2018 16:39:26 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA94D12D832 for ; Thu, 25 Jan 2018 16:39:26 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id A99CC175DC7 for ; Thu, 25 Jan 2018 17:39:25 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 2ofM1x00d2SSUrH01ofQAk; Thu, 25 Jan 2018 17:39:25 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=5olbDlwkQvwXValz-tsA:9 a=YJSQckDMhUCFIw8P:21 a=vwgv1SBIccn7TLuh:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ato0Ysj5rjCsSPetg94vSEXz4tFF1rB+ou4oy40NAns=; b=oiiOnCor+WKZuHaD+LG8Ycn5RH 0jcgtWoHyhrp3F+DX15oOJLLWaJTBZ21kTr/wd8mbzciKZ+VxxW9DtVOkrd5oYIx0gSp7uPsY+tHe nhnMo33FNdh2wlQsYGYWvzNl3; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50644 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ees37-002JJV-QV; Thu, 25 Jan 2018 17:39:21 -0700 To: Stan Ratliff , "Wiggins, David - 0665 - MITLL" Cc: MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> From: Lou Berger Message-ID: <3a16c241-189d-7b66-d808-9b45bbe141bd@labn.net> Date: Thu, 25 Jan 2018 19:39:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1ees37-002JJV-QV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:50644 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 00:39:29 -0000 On 1/25/2018 1:31 PM, Stan Ratliff wrote: > Hi! > > One question/issue inline: > > On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL > > wrote: > > I think the latency extension is in reasonable shape.  I agree > with all of Vicky’s recent comments. > > Here are some comments on the Multi-Hop extension. > > Section 3.1 > > “…each hop represents a transmission and the number of hops is > > equal to the number of transmissions required to go from a router > > connected modem to the destination's connected modem.” > > So hops are counted starting at the modem that is the DLEP peer of > the router.  But then: > > “The minimum number of hops is 1, which represents the router's > locally connected modem.” > > If counting starts at that modem, wouldn’t hop count be 0 for the > modem?  If it’s 1, this seems to mean that the (typically) wired > link between the router and the modem is being counted. I think > the two quotes above are inconsistent about whether this first > link counts as a hop.  If the hop count was meant to convey > over-the-air hops, then the router’s locally connected modem > should have a hop count of 0. > > “A value of zero (0) is used to indicated that processing of a Hop > > Control action, see Section 3.2, has resulted in a destination no > > longer being reachable.” > > I would rather not have this special case.  Just leave it to > Destination Down to convey loss of reachability.  I’ve worked on > systems that had multiple different ways of indicating a node was > down, and it leads to bugs, especially when the down indications > are not closely synchronized. Part of the system thinks a node is > up, part thinks it’s down, and chaos ensues. > > Section 3.2 paragraph 4 > > “Once the change is made, or fails or is rejected, the modem > > MUST respond with a Link Characteristics Request Message…” > > Should this have said Response Message? > > Section 3.2 paragraph 5 > > I think a Session Update message should be replied to with a > Session Update Response, and a Link Characteristics Request > message with a Link Characteristics Response.  The text has both > of these being replied to with a Link Characteristics Request message. > > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > These seem to be a way for the router to tell the modem how > important it is to be able to communicate with specific > destinations.  If that was the motivation, perhaps a more direct > expression of that information would be better.  For example, the > router could provide a list of destinations, ordered by > importance.  I worry that the router giving low-level directions > to the modem about which links to maintain might be difficult or > suboptimal for some radios. > > Section 3.2.4 Suppress Forwarding > > What exactly is meant by suppressing multi-hop forwarding here?  > Is it: > > a) If the router sends data (over the data plane) to a > destination, and that destination has a hop count > 1, the > directly connected modem should drop the data. > > b) The modem should discontinue forwarding of all data whose > destination is more than one hop away, regardless of where the > data came from.  E.g., the modem might be running a manet > protocol, and the data could come over-the-air from another modem. > > c) something else? > > > If the answer is "a", then isn't that really "Destination Down"? Only to multi hop destinations... > What is the use case for suppressing multi-hop forwarding in the first > place? It almost seems counter to the basic appeal of mesh radios. The basic use case is to have all forwarding done by the routers. This would only be useful in networks where routers are attached to all radios.  So this is a user deployment choice... Lou > > Regards, > Stan > > I think it’s probably a), but if so, couldn’t the router arrange > its forwarding tables to drop such packets itself instead of > asking the modem to do it? > > Thanks, > > David > > *From: *manet > on behalf of Justin Dean > > > *Date: *Tuesday, January 23, 2018 at 11:30 AM > *To: *MANET IETF > > *Subject: *[manet] Last call ending > > Working group last call is ending on both > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ > > > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ > > > Please get your comments in. > > Justin Dean > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Jan 25 20:36:16 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEC12D94F for ; Thu, 25 Jan 2018 20:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ymrRkNiHNmRU for ; Thu, 25 Jan 2018 20:36:12 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A506212422F for ; Thu, 25 Jan 2018 20:36:12 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id u62so577246ita.2 for ; Thu, 25 Jan 2018 20:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=24zIy7PjeSivIgA+5JJbJ0YKzdFZYt+q8eG56gEJ28c=; b=OjrN/rwwrMsFlLRSMnnlIJ6tIYEjM2CD4cie/d8xee4+592rGoHS2qzc0todvqr2Pm gBkeOVWcnkwALioUL6p7b6GDoOVW++UU+akOn4WUfxw7USho83p7e+IzmlwaEbBffAWW a8Z2nUxkHVjmFnmxWBkOHfTnNe13R1MeiUvKsjfHbddoPuIxy5AQhmDHMBLNt/4X6cMw SGgmLa9lUvzZn4Oy7JGATyg6OVGJH7voMZrPVcous9NiQl0mL6gfFuVgnMCUNTgF+hWK hdMKInznXxdP4vYIoG4UErs8CPoGLc5SGKr9gMWQe/oLjJDqgXjC3/XqEAVsKLoj0vvc D0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=24zIy7PjeSivIgA+5JJbJ0YKzdFZYt+q8eG56gEJ28c=; b=nhSz6BPLTczFk5ZhlxHdw8l2d+gBwBfGZlt1vOJvfjnefTCkIUkOwKnVwuSx/zbaoV 7DTGEd4lX2xWimH65IT6v0XpDdYKnN9shE3GBY9kAl00Bk7YCS87mjAZ73rQWqbcVTOU jafgUdaEyC/4B/leJA4xr4Y5VNvxuwg2GGghK+4oRxYb4O7VtXlkX61Fv0N8I0wtRdND lhDBiXJRM9BYnNtXOTLrohm11hcie4s6+hULgT/Uiadvan4CjuyMwjPyg69XNag6ukC4 4wHPNr4dkvqk8XXvlXIxQCgczzMAMcgqgcha5cS8CNX8BYQH8TT2fkjGcxezgmY4W7pH ApkQ== X-Gm-Message-State: AKwxytezHCA5lD5TjUzJmobvratAu9z9rwOxeZDp8WN6AldSLRiaiAKM apT81uqbF4ojq0EIp7OxPFYpg4QxtMnAuVD0tuQ= X-Google-Smtp-Source: AH8x226Alwqiq71hXfo97HLQAZPBuHb1uEyTcjShFxhfbwe6JhPBFSMP5z5wJza7tOBawVdCFB78gYA+0sD5+D1VM4Q= X-Received: by 10.36.145.208 with SMTP id i199mr14959914ite.81.1516941371984; Thu, 25 Jan 2018 20:36:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.61.10 with HTTP; Thu, 25 Jan 2018 20:36:11 -0800 (PST) Received: by 10.2.61.10 with HTTP; Thu, 25 Jan 2018 20:36:11 -0800 (PST) In-Reply-To: References: <151182163087.13335.9898030294539351604@ietfa.amsl.com> From: Victoria Pritchard Date: Fri, 26 Jan 2018 04:36:11 +0000 Message-ID: To: Lou Berger Cc: Justin Dean , MANET IETF Content-Type: multipart/alternative; boundary="94eb2c07d5f49f50f50563a66fcb" Archived-At: Subject: Re: [manet] ready for LC : latency and multi-hop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 04:36:15 -0000 --94eb2c07d5f49f50f50563a66fcb Content-Type: text/plain; charset="UTF-8" Hi Lou, Thanks for the response... On 25 Jan 2018 23:50, "Lou Berger" wrote: Vicky, Thank you for the comments! On 1/21/2018 1:03 PM, Victoria Pritchard wrote: > Hi all, > > Just a few picky comments on the Latency Range draft. > > Title > Lantency -> Latency > > thanks. Abstract > Should you reference the DLEP RFC number here? Or at least expand the > acronym? > > Section 1 > It's "Dynamic Link Exchange Protocol" (not "Event Protocol") > > Well that's embarrassing! Fixed in all extensions. I think DLEP itself was confused for a little while too ;) "provides an average latency" - the definition in RFC8175 actually says > "The calculation > of latency is implementation dependent. For example, the latency may > be a running average calculated from the internal queuing." so not sure > it's right to say it provides an average. > > how about: The base DLEP specification includes the Latency metric which provides - an average latency on a link. This document adds the ability to relay + a single latency value on a link, which is implementation dependent. + This document adds the ability to relay Looks good to me "one new DLEP > Data Items" - unnecessary 's' on Items > Section 3 > Is it " Latency Range Item " or " Latency Range Data Item "? Makes sense > to be consistent > > agreed. Under the Maximum Latency field description: > "representing the transmission longest > delay" > should that be "longest transmission delay"? > Similar comment for Minimum Latency > > thanks! Section 5.2 > "Data Item Type Values" is the name of the registry in RFC8175. > > fixed in all drafts! > Regards, > Vicky > > Thank you - changes have been pushed to the repo... Brilliant :) thanks Lou. On 8 January 2018 at 21:46, Justin Dean bebemaster@gmail.com>> wrote: > > As discussed during IETF 100 these documents are now in last call. > Please review them and post comments to the list. > > > https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01 > xtension-01> > https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop- > extension-03 > > -extension-03> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --94eb2c07d5f49f50f50563a66fcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lou,

Thanks for the response...


On 25 Jan 2018 23:50, "Lou Berger" <lberger@labn.net> wrote:
Vicky,

=C2=A0=C2=A0=C2=A0 Thank you for the comments!


On 1/21/2018 1:03 PM, Victoria Pritchard wrote:
Hi all,

Just a few picky comments on the Latency Range draft.

Title
Lantency -> Latency

thanks.


Abstract
Should you reference the DLEP RFC number here? Or at least expand the acron= ym?

Section 1
It's "Dynamic Link Exchange Protocol" (not "Event Protoc= ol")


Well that's embarrassing! Fixed in all extensions.

I think DLEP itself was confused for a little while too ;)



"provides an average latency" - the definition in RFC8175 actuall= y says "The calculation
=C2=A0 =C2=A0of latency is implementation dependent.=C2=A0 For example, the= latency may
=C2=A0 =C2=A0be a running average calculated from the internal queuing.&quo= t; so not sure it's right to say it provides an average.

how about:
=C2=A0=C2=A0 The base DLEP specification includes the Latency metric which = provides
-=C2=A0 an average latency on a link.=C2=A0 This document adds the ability = to relay
+=C2=A0 a single latency value on a link, which is implementation dependent= .
+=C2=A0 This document adds the ability to relay
<= /div>

Looks good to me

=



"one new DLEP
=C2=A0 =C2=A0Data Items" - unnecessary 's' on Items
Section 3
Is it " Latency Range Item " or " Latency Range Data Item &q= uot;? Makes sense to be consistent

agreed.


Under the Maximum Latency field description:
"representing the transmission longest
=C2=A0 =C2=A0 =C2=A0 delay"
should that be "longest transmission delay"?
Similar comment for Minimum Latency

thanks!


Section 5.2
"Data Item Type Values"=C2=A0 is the name of the registry in RFC8= 175.

fixed in all drafts!


Regards,
Vicky


Thank you - changes have been pushed to the repo...
<= /div>

Brilliant :) thank= s Lou.


On 8 January 2018 at 21:46, Justin Dean <bebemaster@gmail.com <mailto:bebemaster@gmail.com>&= gt; wrote:

=C2=A0 =C2=A0 As discussed during IETF 100 these documents are now in last = call.
=C2=A0 =C2=A0 Please review them and post comments to the list.


=C2=A0 =C2=A0 https://tools.ie= tf.org/html/draft-ietf-manet-dlep-latency-extension-01
=C2=A0 =C2=A0 <https://tool= s.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01>= ;
=C2=A0 =C2=A0 https://tools.= ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03
=C2=A0 =C2=A0 <https://to= ols.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03>

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 manet mailing list
=C2=A0 =C2=A0 manet@iet= f.org <mailto:ma= net@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/manet
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/manet>





_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--94eb2c07d5f49f50f50563a66fcb-- From nobody Fri Jan 26 12:41:07 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45DF12DA3E for ; Fri, 26 Jan 2018 12:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 287Q-MfBm6_2 for ; Fri, 26 Jan 2018 12:41:03 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8512778D for ; Fri, 26 Jan 2018 12:41:02 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w0QKf1aL009211; Fri, 26 Jan 2018 15:41:01 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , Justin Dean , "MANET IETF" Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44AgADx3oCAAP27gA== Date: Fri, 26 Jan 2018 20:41:00 +0000 Message-ID: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3599826063_332822552" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801260270 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 20:41:06 -0000 --B_3599826063_332822552 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Comments inline=E2=80=A6 sorry if outlook mangles stuff On 1/25/18, 7:33 PM, "Lou Berger" wrote: On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote: > > I think the latency extension is in reasonable shape. I agree with=20 > all of Vicky=E2=80=99s recent comments. > > Here are some comments on the Multi-Hop extension. > > Section 3.1 > > =E2=80=9C=E2=80=A6each hop represents a transmission and the number of hops is > equal to the number of transmissions required to go from a router > connected modem to the destination's connected modem.=E2=80=9D > So hops are counted starting at the modem that is the DLEP peer of th= e=20 > router. > yes, that's the intent. =20 > But then: > > =E2=80=9CThe minimum number of hops is 1, which represents the router's=20 > locally connected modem.=E2=80=9D > how about "which represents the *transmission* by the router's locally=20 connected modem."? I like this better: =E2=80=9Cwhich represents transmission to destinations that a= re directly reachable from the router=E2=80=99s locally connected modem.=E2=80=9D > If counting starts at that modem, wouldn=E2=80=99t hop count be 0 for the m= odem? > I don't understand this. Perhaps you mean for the hop between the=20 router and the modem? This extensions isn't intended to count router t= o=20 modem hops. No, I mean the modem. If the hop count from the modem to one of its direct= ly reachable destinations is 1, and assuming each hop increments the count b= y 1, then the modem=E2=80=99s hop count has to be zero for that math to work ( No= w, we may expect a hop count of zero to never be reported, but that is a sep= arate issue; more below. > If it=E2=80=99s 1, this seems to mean that the (typically) wired link=20 > between the router and the modem is being counted. > How so? 1 means a single transmission over the modem attached media=20 (RF) channel . It doesn=E2=80=99t matter now=E2=80=A6 I was just trying to reason through what it woul= d mean if the modem=E2=80=99s hop count was 1, because it was ambiguous before. N= ow it=E2=80=99s not. > I think the two quotes above are inconsistent about whether this firs= t=20 > link counts as a hop. If the hop count was meant to convey=20 > over-the-air hops, then the router=E2=80=99s locally connected modem should= =20 > have a hop count of 0. > There is no destination for the locally connected modem, so zero would=20 never be reported. In what case do you see zero being reported? I=E2=80=99ve been assuming that the locally connected modem could indeed announce= a destination for itself, though admittedly this seems unusual. However, I= =E2=80=99m probably wrong; in 8175 section 2.1: =E2=80=9CDestinations can be identified by either the router or the modem and rep= resent a specific, addressable location that can be reached via the link(s) = managed by the modem.=E2=80=9D Unless we imagine an implied link from the modem to itself, which seems lik= e a stretch, this means that the destinations are on the other end of a link= from the modem. So I accept that the modem itself won=E2=80=99t be a destination= , and thus there won=E2=80=99t ever be a zero hop count. > =E2=80=9CA value of zero (0) is used to indicated that processing of a Hop > Control action, see Section 3.2, has resulted in a destination no > longer being reachable.=E2=80=9D > > I would rather not have this special case. Just leave it to=20 > Destination Down to convey loss of reachability. I=E2=80=99ve worked on=20 > systems that had multiple different ways of indicating a node was=20 > down, and it leads to bugs, especially when the down indications are=20 > not closely synchronized. Part of the system thinks a node is up,=20 > part thinks it=E2=80=99s down, and chaos ensues. > I'd actually expect both a Destination Down, per normal processing whic= h=20 is not modified by this document, and a Link Characteristics Request=20 Message. This is so there is consistent processing of the Hop Control= =20 Data Item on both router and modem. Otherwise there how will a router=20 know that a particular Hop Control request has completed. Having just = a=20 Destination Down would mean that the router would have to infer that=20 this was due to the hop control when in fact it may be due to just some= =20 transitory affect. In my experience leaving things to inference is a=20 bad transaction model and leads to race condition bugs. So I'd prefer t= o=20 leave as is. I've added a note to make it clear that the Destination=20 Down is still sent. specifically: Note that normal DLEP processing is not otherwise modified by this document, t= his includes the generation of Destination Down messages. The router would know that the Hop Control request has completed when it re= ceives a Link Characteristics Response. The status code would be used to in= dicate whether it succeeded or not. If it did succeed, a Destination Down w= ould come along soon after (if the action was Terminate). This is almost wh= at you have now, except I=E2=80=99m suggesting to use the status code data item ra= ther than the hop count data item to indicate success. > Section 3.2 paragraph 5 > > I think a Session Update message should be replied to with a Session=20 > Update Response, and a Link Characteristics Request message with a=20 > Link Characteristics Response. The text has both of these being=20 > replied to with a Link Characteristics Request message. > What information would you like carried in the Session Update Response=20 message? Note that a reset may result in a destination specific change= . A Hop Control Reset sent in a Session Update would be answered with a Sessi= on Update Response with an appropriate status code, followed by Destination = Updates with appropriate Hop Count data items for any that changed. Please, please don=E2=80=99t make a Session Update message be replied to with a L= ink Characteristics Request message. That contorts my implementation in unn= atural ways. > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > These seem to be a way for the router to tell the modem how important= =20 > it is to be able to communicate with specific destinations. > I see this as the way to reverse/undo a 'Direct Connection'. I=E2=80=99m talking about both Terminate and Direct Connection. > > If that was the motivation, perhaps a more direct expression of that=20 > information would be better. For example, the router could provide a= =20 > list of destinations, ordered by importance. I worry that the router= =20 > giving low-level directions to the modem about which links to maintai= n=20 > might be difficult or suboptimal for some radios. > How about: OLD It indicates that the modem SHOULD attempt to terminate communication with the destination identified in the message. NEW It indicates that a direct connection is no longer needed with the the destination identified in the message. My concern is deeper than this. The modem may be running a sophisticated t= opology control algorithm to decide which neighbors to maintain links to. I= t may be juggling multiple beams, multiple frequencies, considering the loca= l network density and traffic load, factoring in connectivity goals (e.g., b= iconnectedness), etc. Having an external party (router) insert its own wish= es for links into the mix could be untenable. The probability is good that = the router=E2=80=99s wishes will contradict the modem=E2=80=99s topology choices. Also, there seems to be an unstated assumption that a direct connection (1 = hop) to a destination is better in some sense that a non-direct connection. = Why else would the router ask for a direct connection? Two short hops are = often more reliable than one long hop, though. Forcing a single hop could m= ake communication worse. Giving the router this control is too low-level; i= t doesn=E2=80=99t have enough information to do it right. That=E2=80=99s why I was suggesting a radically different mechanism for the route= r to express its wishes, e.g., by ordering the destinations in terms of impo= rtance, and letting the modem work that information into its topology contro= l scheme however it can. The router=E2=80=99s most important destination may be b= est reached over a 3-hop link. > > Section 3.2.4 Suppress Forwarding > > What exactly is meant by suppressing multi-hop forwarding here? Is i= t: Borrowing text from a different message in this thread, Lou said: The basic use case is to have all forwarding done by the routers. This=20 would only be useful in networks where routers are attached to all radios. So this is a user deployment choice... Ah, I see. This clarifies the intent significantly. This motivation shoul= d be stated in the draft. I=E2=80=99ve definitely heard the desire to turn off al= l of the radio=E2=80=99s routing and use it as a single-hop device. Thanks, David =20 --B_3599826063_332822552 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBT2BYBJVnhCuMRKG1M9vlAcjhOrHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAxMjYyMDQxMDNaMA0GCSqGSIb3DQEBAQUABIIBAC0yzI99kXUZiGIa U9mb0JIeunBknoo9Hg5zlyJ/CeHje/IKTK4Xern1IXd0JgXycU2mK/WR3Vp/Kdeeaj//V3Os Wik35/UbhDxgdHGMZ0aKuaVrOtZOzDwv1GV1BOPfDZpBoI5I/JerZ2kM7YTQtsdeZ9axYKzS LLmIMGfhs1mBiGNdRi6Ejd3yfzrZSAH3psWmsoMWnuZiSUxQBewNFxU4+7U3dSVJQNBXd5hf kOUH27jqWn7O8k+8MVK3dv9Ca/qtxohjUvt+1zi+e5rsoUqDbQsBhHRtKy75AcS+3csoaWEP MC94KyI93hDqeESLs32pTFNI/LdZUjzRIoc1oyQ= --B_3599826063_332822552-- From nobody Fri Jan 26 14:46:12 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818512895E for ; Fri, 26 Jan 2018 14:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 it1BskyT0fqL for ; Fri, 26 Jan 2018 14:43:53 -0800 (PST) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4AF127876 for ; Fri, 26 Jan 2018 14:43:53 -0800 (PST) Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 0A8BE175F5F for ; Fri, 26 Jan 2018 15:43:14 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 3AjA1x00B2SSUrH01AjDc7; Fri, 26 Jan 2018 15:43:14 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=wU2YTnxGAAAA:8 a=16br8Lss9Y2Peg8xkVcA:9 a=_oD4VMLJxqHe1AGp:21 a=hBSRbkwpd4e6LIS6:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=i18nq9sBLvaBKUMrK69yEB76hwHsLFmrPTZYQpkriEQ=; b=OMWf009a+bx8lc5vmzCpaMRu45 PRyHFDaSgawVuEb3+wshGoDpY7bXOj1IJjRXv2/ddO5jD9pOyc+uVO8RFQON94YgJojYppfl12dTR 33DsAMQiEBjs7Rdq/GydYRQtd; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:38232 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1efCiD-003EWg-T8; Fri, 26 Jan 2018 15:43:10 -0700 From: Lou Berger To: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF Date: Fri, 26 Jan 2018 17:43:07 -0500 Message-ID: <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1efCiD-003EWg-T8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:38232 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Fri, 26 Jan 2018 14:46:12 -0800 Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 22:43:56 -0000 On January 26, 2018 3:41:30 PM "Wiggins, David - 0665 - MITLL" wrote: > Comments inline… sorry if outlook mangles stuff > > On 1/25/18, 7:33 PM, "Lou Berger" wrote: > On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote: > > > > I think the latency extension is in reasonable shape. I agree with > > all of Vicky’s recent comments. > > > > Here are some comments on the Multi-Hop extension. > > > > Section 3.1 > > > > “…each hop represents a transmission and the number of hops is > > equal to the number of transmissions required to go from a router > > connected modem to the destination's connected modem.” > > So hops are counted starting at the modem that is the DLEP peer of the > > router. > > > yes, that's the intent. > > > But then: > > > > “The minimum number of hops is 1, which represents the router's > > locally connected modem.” > > > how about "which represents the *transmission* by the router's locally > connected modem."? > > I like this better: “which represents transmission to destinations that are > directly reachable from the router’s locally connected modem.” > How about s/from/via ? > > If counting starts at that modem, wouldn’t hop count be 0 for the modem? > > > I don't understand this. Perhaps you mean for the hop between the > router and the modem? This extensions isn't intended to count router to > modem hops. > > No, I mean the modem. If the hop count from the modem to one of its > directly reachable destinations is 1, and assuming each hop increments the > count by 1, then the modem’s hop count has to be zero for that math to work > ( Now, we may expect a hop count of zero to never be reported, but that is > a separate issue; more below. > Right- I think we agree that this is a non issue/case. > > If it’s 1, this seems to mean that the (typically) wired link > > between the router and the modem is being counted. > > > How so? 1 means a single transmission over the modem attached media > (RF) channel . > > It doesn’t matter now… I was just trying to reason through what it would > mean if the modem’s hop count was 1, because it was ambiguous before. Now > it’s not. > Okay. > > I think the two quotes above are inconsistent about whether this first > > link counts as a hop. If the hop count was meant to convey > > over-the-air hops, then the router’s locally connected modem should > > have a hop count of 0. > > > There is no destination for the locally connected modem, so zero would > never be reported. In what case do you see zero being reported? > > I’ve been assuming that the locally connected modem could indeed announce a > destination for itself, though admittedly this seems unusual. However, I’m > probably wrong; in 8175 section 2.1: > > “Destinations can be identified by either the router or the modem and > represent a specific, addressable location that can be reached via the > link(s) managed by the modem.” > > Unless we imagine an implied link from the modem to itself, which seems > like a stretch, this means that the destinations are on the other end of a > link from the modem. So I accept that the modem itself won’t be a > destination, and thus there won’t ever be a zero hop count. > Great. > > “A value of zero (0) is used to indicated that processing of a Hop > > Control action, see Section 3.2, has resulted in a destination no > > longer being reachable.” > > > > I would rather not have this special case. Just leave it to > > Destination Down to convey loss of reachability. I’ve worked on > > systems that had multiple different ways of indicating a node was > > down, and it leads to bugs, especially when the down indications are > > not closely synchronized. Part of the system thinks a node is up, > > part thinks it’s down, and chaos ensues. > > > I'd actually expect both a Destination Down, per normal processing which > is not modified by this document, and a Link Characteristics Request > Message. This is so there is consistent processing of the Hop Control > Data Item on both router and modem. Otherwise there how will a router > know that a particular Hop Control request has completed. Having just a > Destination Down would mean that the router would have to infer that > this was due to the hop control when in fact it may be due to just some > transitory affect. In my experience leaving things to inference is a > bad transaction model and leads to race condition bugs. So I'd prefer to > leave as is. I've added a note to make it clear that the Destination > Down is still sent. specifically: > Note that > normal DLEP processing is not otherwise modified by this document, this > includes the generation of Destination Down messages. > > The router would know that the Hop Control request has completed when it > receives a Link Characteristics Response. The status code would be used to > indicate whether it succeeded or not. If it did succeed, a Destination > Down would come along soon after (if the action was Terminate). This is > almost what you have now, except I’m suggesting to use the status code data > item rather than the hop count data item to indicate success. > Hmm. A successful transaction does not necessarily Translate to a loss of connection, so I think being explicit here makes the most sense. We should certainly ensure that the text is clear either way. > > Section 3.2 paragraph 5 > > > > I think a Session Update message should be replied to with a Session > > Update Response, and a Link Characteristics Request message with a > > Link Characteristics Response. The text has both of these being > > replied to with a Link Characteristics Request message. > > > What information would you like carried in the Session Update Response > message? Note that a reset may result in a destination specific change. > > A Hop Control Reset sent in a Session Update would be answered with a > Session Update Response with an appropriate status code, followed by > Destination Updates with appropriate Hop Count data items for any that changed. > This works for me and seems sensible. I thought you were suggesting something different. I'll propose some text to this effect. > Please, please don’t make a Session Update message be replied to with a > Link Characteristics Request message. That contorts my implementation in > unnatural ways. > Understood. > > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > > > These seem to be a way for the router to tell the modem how important > > it is to be able to communicate with specific destinations. > > > I see this as the way to reverse/undo a 'Direct Connection'. > > I’m talking about both Terminate and Direct Connection. > > > > > If that was the motivation, perhaps a more direct expression of that > > information would be better. For example, the router could provide a > > list of destinations, ordered by importance. I worry that the router > > giving low-level directions to the modem about which links to maintain > > might be difficult or suboptimal for some radios. > > > How about: > OLD > It indicates > that the modem SHOULD attempt to terminate communication > with the destination identified in the message. > NEW > It indicates that a direct connection is no longer needed with the > the destination identified in the message. > > My concern is deeper than this. The modem may be running a sophisticated > topology control algorithm to decide which neighbors to maintain links to. > It may be juggling multiple beams, multiple frequencies, considering the > local network density and traffic load, factoring in connectivity goals > (e.g., biconnectedness), etc. Having an external party (router) insert its > own wishes for links into the mix could be untenable. The probability is > good that the router’s wishes will contradict the modem’s topology choices. > Well certainly this extension is about a router in forming a modem about its wishes/preferenes. > Also, there seems to be an unstated assumption that a direct connection (1 > hop) to a destination is better in some sense that a non-direct connection. > Why else would the router ask for a direct connection? Two short hops are > often more reliable than one long hop, though. Forcing a single hop could > make communication worse. Giving the router this control is too low-level; > it doesn’t have enough information to do it right. > I think the router has access to sufficient information through other metrics. Certainly A system that doesn't care to provide this capability to a router doesn't have to implement it. > That’s why I was suggesting a radically different mechanism for the router > to express its wishes, e.g., by ordering the destinations in terms of > importance, and letting the modem work that information into its topology > control scheme however it can. The router’s most important destination may > be best reached over a 3-hop link. > To me this is a different extension with different objectives. I certainly would be interested in reading that extension. > > > > Section 3.2.4 Suppress Forwarding > > > > What exactly is meant by suppressing multi-hop forwarding here? Is it: > > Borrowing text from a different message in this thread, Lou said: > > The basic use case is to have all forwarding done by the routers. This > would only be useful in networks where routers are attached to all > radios. So this is a user deployment choice... > > Ah, I see. This clarifies the intent significantly. This motivation > should be stated in the draft. I’ve definitely heard the desire to turn > off all of the radio’s routing and use it as a single-hop device. > I'll look at providing some text on this in the intro. Thanks, Lou > Thanks, > David > From nobody Mon Jan 29 06:39:18 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1388131951 for ; Mon, 29 Jan 2018 06:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 r0zeLSjuNWb2 for ; Mon, 29 Jan 2018 06:39:14 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D87D7131834 for ; Mon, 29 Jan 2018 06:36:40 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w0TEacbS035981; Mon, 29 Jan 2018 09:36:38 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , Justin Dean , "MANET IETF" Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44AgADx3oCAAP27gIAAdeyAgAPbQIA= Date: Mon, 29 Jan 2018 14:36:37 +0000 Message-ID: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3600063397_491907421" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-29_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290194 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 14:39:17 -0000 --B_3600063397_491907421 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 1/26/18, 5:43 PM, "Lou Berger" wrote: On January 26, 2018 3:41:30 PM "Wiggins, David - 0665 - MITLL"=20 wrote: =20 > I like this better: =E2=80=9Cwhich represents transmission to destinations = that are=20 > directly reachable from the router=E2=80=99s locally connected modem.=E2=80=9D > =20 How about s/from/via ? That=E2=80=99s fine. =20 > > =E2=80=9CA value of zero (0) is used to indicated that processing of a Ho= p > > Control action, see Section 3.2, has resulted in a destination = no > > longer being reachable.=E2=80=9D > > > > I would rather not have this special case. Just leave it to > > Destination Down to convey loss of reachability. I=E2=80=99ve worked= on > > systems that had multiple different ways of indicating a node w= as > > down, and it leads to bugs, especially when the down indication= s are > > not closely synchronized. Part of the system thinks a node is = up, > > part thinks it=E2=80=99s down, and chaos ensues. > > > I'd actually expect both a Destination Down, per normal processin= g which > is not modified by this document, and a Link Characteristics Req= uest > Message. This is so there is consistent processing of the Hop C= ontrol > Data Item on both router and modem. Otherwise there how will a r= outer > know that a particular Hop Control request has completed. Having= just a > Destination Down would mean that the router would have to infer t= hat > this was due to the hop control when in fact it may be due to jus= t some > transitory affect. In my experience leaving things to inference = is a > bad transaction model and leads to race condition bugs. So I'd pr= efer to > leave as is. I've added a note to make it clear that the Destinat= ion > Down is still sent. specifically: > Note that > normal DLEP processing is not otherwise modified by this docum= ent, this > includes the generation of Destination Down messages. > > The router would know that the Hop Control request has completed when= it=20 > receives a Link Characteristics Response. The status code would be u= sed to=20 > indicate whether it succeeded or not. If it did succeed, a Destinati= on=20 > Down would come along soon after (if the action was Terminate). This= is=20 > almost what you have now, except I=E2=80=99m suggesting to use the status c= ode data=20 > item rather than the hop count data item to indicate success. > =20 Hmm. A successful transaction does not necessarily Translate to a loss = of=20 connection, so I think being explicit here makes the most sense. We sho= uld=20 certainly ensure that the text is clear either way. OK. Mainly what I hope to avoid is having Destination Down be expressed in= two different ways by different messages that come at different times. > > Sections 3.2.2 Terminate and 3.2.3 Direct Connection > > > > These seem to be a way for the router to tell the modem how imp= ortant > > it is to be able to communicate with specific destinations. > > > I see this as the way to reverse/undo a 'Direct Connection'. > > I=E2=80=99m talking about both Terminate and Direct Connection. > > > > > If that was the motivation, perhaps a more direct expression of= that > > information would be better. For example, the router could pro= vide a > > list of destinations, ordered by importance. I worry that the = router > > giving low-level directions to the modem about which links to m= aintain > > might be difficult or suboptimal for some radios. > > > How about: > OLD > It indicates > that the modem SHOULD attempt to terminate communication > with the destination identified in the message. > NEW > It indicates that a direct connection is no longer needed wit= h the > the destination identified in the message. > > My concern is deeper than this. The modem may be running a sophistic= ated=20 > topology control algorithm to decide which neighbors to maintain link= s to. =20 > It may be juggling multiple beams, multiple frequencies, considering = the=20 > local network density and traffic load, factoring in connectivity goa= ls=20 > (e.g., biconnectedness), etc. Having an external party (router) inse= rt its=20 > own wishes for links into the mix could be untenable. The probabilit= y is=20 > good that the router=E2=80=99s wishes will contradict the modem=E2=80=99s topolog= y choices. > Well certainly this extension is about a router in forming a modem abou= t=20 its wishes/preferenes. > Also, there seems to be an unstated assumption that a direct connectio= n (1=20 > hop) to a destination is better in some sense that a non-direct conne= ction.=20 > Why else would the router ask for a direct connection? Two short ho= ps are=20 > often more reliable than one long hop, though. Forcing a single hop = could=20 > make communication worse. Giving the router this control is too low-= level;=20 > it doesn=E2=80=99t have enough information to do it right. > =20 I think the router has access to sufficient information through other=20 metrics. Certainly A system that doesn't care to provide this capabilit= y to=20 a router doesn't have to implement it. I think whether the router has enough knowledge to make good decisions is v= ery system dependent. Point taken though, if the modem knows that allowing = the router to choose links is going to be bad news, the modem can simply not= offer this extension. =20 =20 > That=E2=80=99s why I was suggesting a radically different mechanism for the= router=20 > to express its wishes, e.g., by ordering the destinations in terms of= =20 > importance, and letting the modem work that information into its topo= logy=20 > control scheme however it can. The router=E2=80=99s most important destina= tion may=20 > be best reached over a 3-hop link. > =20 To me this is a different extension with different objectives. I certai= nly=20 would be interested in reading that extension. It has very similar objectives to the Direct Connection/Terminate part of t= his extension, but I agree that it doesn=E2=80=99t fit well in this extension. Thanks, =20 Lou =20 > Thanks, > David --B_3600063397_491907421 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBR7ClRpLEZKs0HrNqNK0KJl3O2WqzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAxMjkxNDM2MzdaMA0GCSqGSIb3DQEBAQUABIIBAFskK5o7ZJVQdT5T G8UrznKbYbay8wuaoSB5695peBKTxEyjHqV1IYE4QiLcfuw0nO8FLIAsJHdBQwsX07LBH4i6 vRdxWbZmQAU4+E/gCzWNr2Dc197lBfzgX0201RhCFWfRX0iHC+392P/KsXsRaYDD1icqeupW fatEZd3LTkkadXWlujBARsoVWyrmluSWxISBC7F4S82+obMN0u2S5xR99h4ghQLK2NiVzsFR 2MDd+1Sm+BquKAcqlfRnfoMdOwUBLoBz3ww3OevOcNuFeGh/QmtHdP+Zmb/go6jMX6rlOwvn JfziCSWz4FI5yZ5qJQvROHyuhh1y89T5h8elwrs= --B_3600063397_491907421-- From nobody Mon Jan 29 10:36:54 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E422512EB67 for ; Mon, 29 Jan 2018 10:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 rrKuXZJIUwPO for ; Mon, 29 Jan 2018 10:36:45 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB461242EA for ; Mon, 29 Jan 2018 10:36:45 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 820A31E06A2 for ; Mon, 29 Jan 2018 11:36:45 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 4Jci1x0072SSUrH01JclJA; Mon, 29 Jan 2018 11:36:45 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=NEAV23lmAAAA:8 a=wU2YTnxGAAAA:8 a=8t0eNmiW52ZPi4Zq9AUA:9 a=OBGvEosdR8gcr34V:21 a=OMOqeJie0cNhSUh1:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:To:Subject:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qQa41oLbPfkKnPYxOYjYMLNDqrWw3yoas79RDnC9opU=; b=UBvWHJXiAjvj8dhqSYArO5vBjB GH+8Z/RhQRKBP+3HiNsIHpfhXBAD0c/GJQTQEF8v/uwoBqqdKkeopoJcL0BJtpjVQMfglxZGMISa6 R2sntAgjyFjsGwUfLL03F8lNW; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:41304 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1egEIL-002oqL-T8; Mon, 29 Jan 2018 11:36:42 -0700 From: Lou Berger To: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Message-ID: Date: Mon, 29 Jan 2018 13:36:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1egEIL-002oqL-T8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:41304 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 18:36:53 -0000 ... David, (all) I think I've addressed all comments in the latest push to the repo. I'm enclosing below a specific diff of the commit that addresses your comments, please take a look and let me know if you see any issues remaining. Note I have clarified processing when hop control is in a characteristics change message and changed/simplified in the Session request massage case - to improve processing consistency as you requested. Please see the specific changes below and let me know what you think. I also have one comment in response to your comment below. On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: > > That’s why I was suggesting a radically different mechanism for the router > > to express its wishes, e.g., by ordering the destinations in terms of > > importance, and letting the modem work that information into its topology > > control scheme however it can. The router’s most important destination may > > be best reached over a 3-hop link. > > > > To me this is a different extension with different objectives. I certainly > would be interested in reading that extension. > > It has very similar objectives to the Direct Connection/Terminate part of this extension, but I agree that it doesn’t fit well in this extension. I think an extension that does this as well as let's a router understand some of the resource impacts of a manet topology (with out exposing the full topology ala ospf/isis-te) would be very interesting. I actually had some related discussion on this in singapore. If you have a proposal on this or are interested in collaborating on such, I'm very interested in this! Thanks, Lou Changes from: https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f commit 100217f5a8a3e35c6608b4a88428b20b14854f8f Author: Lou Berger Date: Mon Jan 29 13:20:09 2018 -0500 Multi-hop: Address remainder of Dave W. comments - Clean up Hop Behavior processing. Send only one message when link characteristic change results in a change/unreachable requested destination Destination impact due to Hop Control Data Item in a Session Update Message always provided via a Destination Down or Destination Update Message. diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml index 5fc2845..f81e3be 100644 --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml @@ -110,7 +110,8 @@ words, each hop represents a transmission and the number of hops is equal to the number of transmissions required to go from a router connected modem to the destination's connected modem. The minimum - number of hops is 1, which represents the transmission by the router's + number of hops is 1, which represents transmission to destinations + that are directly reachable via the router's locally connected modem. @@ -176,7 +177,7 @@ A value of zero (0) is used to indicated that processing of a Hop Control action, see , has resulted in a destination no longer being reachable. A zero value MUST NOT - be used in any message other then a Destination Announce Response + be used in any message other then a Link Characteristics Response Message. @@ -189,7 +190,8 @@ connectivity to a particular destination, or in multi-hop processing on a device wide basis. A router can request multi-hop reachable destination be changed to a single hop. A router can also indicate - that the modem terminate connectivity to a particular destination. + that the modem terminates a previous direct connectivity request to a + particular destination. The Hop Control Data Item MAY be carried in a Session Update Message @@ -218,20 +220,19 @@ notify the router of each destination that is no longer reachable via a Destination Down Message. The modem MUST notify the router of any changes in Hop Counts via Destination Update Messages. Note that - normal DLEP processing is not otherwise modified by this document, this - includes the generation of Destination Down messages. + neither Destination Down or Update Message SHOULD NOT be sent for the + destination MAC address contained in the Link Characteristics + Response Message. A modem that receives the Hop Control Data Item in a Session Update Message SHOULD attempt to make the change indicated by the data item - for the associated destination MAC address, when carried in a Link - Characteristics Request Message, or all destinations, when carried in - a Session Update Message. Once the change is made, - or fails or is rejected, the modem MUST respond with a Link Characteristics - Request Message containing an updated Hop Count Data Item. Note that - other destinations can be impacted as a result of the change and such - changes are reported in + for all known destinations. Once the change is made, or fails or is + rejected, the modem MUST respond with a Session Update Response + Message with an appropriate Status Code. Destination specific + impact resulting from the processing of a Hop Control Data Item in a + Session Update Message is provided via Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is no longer reachable via a Destination Down Message. The modem MUST notify the router of any From nobody Mon Jan 29 13:39:47 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5F12D86D for ; Mon, 29 Jan 2018 13:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 4wmu9wtKL-D5 for ; Mon, 29 Jan 2018 13:39:43 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5897A131450 for ; Mon, 29 Jan 2018 13:39:28 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 31BFC14068C for ; Mon, 29 Jan 2018 14:39:27 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 4MfQ1x00G2SSUrH01MfTWk; Mon, 29 Jan 2018 14:39:27 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=NEAV23lmAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=R0nUE1uuQPiDySEA3u8A:9 a=FxTItS7SkTk9cR0o:21 a=LpqQUmy-mjNvlJoP:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:To:From:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=b9mbhGPKU/g/ypzcPJ4vZ4Pj4bg/vZUQWEOjJWjIrTk=; b=oRhY7j3tDCpOI4lf8gllbXqc8T gm7xDAR/j6/+7UPxmYL7AdSfCgDutqpxX47g1kkD5/Nr/DRHYtVwAdgIeKP8PokK/CkgZRyn5DkLs hbEas7Ax5LPvmKRXiuX4SIgBq; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49574 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1egH99-003tdB-SU; Mon, 29 Jan 2018 14:39:24 -0700 From: Lou Berger To: "Wiggins, David - 0665 - MITLL" , Justin Dean , MANET IETF References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Message-ID: <3b324229-dfb2-0b82-3b02-7f709de71767@labn.net> Date: Mon, 29 Jan 2018 16:39:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1egH99-003tdB-SU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:49574 X-Source-Auth: lberger@labn.net X-Email-Count: 24 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 21:39:46 -0000 FYI - I just pushed an updated - David noticed some vestigial (and now illegal) case being described - I removed the paragraph and pushed the change... Lou On 01/29/2018 01:36 PM, Lou Berger wrote: > ... > David, (all) > I think I've addressed all comments in the latest push to the repo.  I'm > enclosing below a specific diff of the commit that addresses your > comments, please take a look and let me know if you see any issues > remaining. > > Note I have clarified processing when hop control is in a > characteristics change message and changed/simplified in the Session > request massage case - to improve processing consistency as you > requested.  Please see the specific changes below and let me know what > you think. > > I also have one comment in response to your comment below. > > On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: >>     > That’s why I was suggesting a radically different mechanism for >> the router     > to express its wishes, e.g., by ordering the >> destinations in terms of     > importance, and letting the modem work >> that information into its topology     > control scheme however it >> can.  The router’s most important destination may     > be best >> reached over a 3-hop link. >>     > >>         To me this is a different extension with different objectives. >> I certainly     would be interested in reading that extension. >> >> It has very similar objectives to the Direct Connection/Terminate part >> of this extension, but I agree that it doesn’t fit well in this >> extension. > > I think an extension that does this as well as let's a router understand > some of the resource impacts of a manet topology (with out exposing the > full topology ala ospf/isis-te) would be very interesting.  I actually > had some related discussion on this in singapore.  If you have a > proposal on this or are interested in collaborating on such, I'm very > interested in this! > > Thanks, > > Lou > > Changes from: > https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f > > commit 100217f5a8a3e35c6608b4a88428b20b14854f8f > Author: Lou Berger > Date:   Mon Jan 29 13:20:09 2018 -0500 > >     Multi-hop: Address remainder of Dave W. comments >         - Clean up Hop Behavior processing. >           Send only one message when link characteristic change results in >                a change/unreachable requested destination >           Destination impact due to Hop Control Data Item in a Session >                Update Message always provided via a Destination Down or >                Destination Update Message. > > diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > index 5fc2845..f81e3be 100644 > --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > @@ -110,7 +110,8 @@ >    words, each hop represents a transmission and the number of hops is >    equal to the number of transmissions required to go from a router >    connected modem to the destination's connected modem.  The minimum > -  number of hops is 1, which represents the transmission by the router's > +  number of hops is 1, which represents transmission to destinations > +  that are directly reachable via the router's >    locally connected >    modem. >   > @@ -176,7 +177,7 @@ >        A value of zero (0) is used to indicated that processing of a Hop >        Control action, see , has resulted >        in a destination no longer being reachable.  A zero value MUST NOT > -      be used in any message other then a Destination Announce Response > +      be used in any message other then a Link Characteristics Response >        Message. >      >    > @@ -189,7 +190,8 @@ >    connectivity to a particular destination, or in multi-hop processing >    on a device wide basis. A router can request multi-hop reachable >    destination be changed to a single hop.  A router can also indicate > -  that the modem terminate connectivity to a particular destination. > +  that the modem terminates a previous direct connectivity request to a > +  particular destination. >   >   >    The Hop Control Data Item MAY be carried in a Session Update Message > @@ -218,20 +220,19 @@ >    notify the router of each destination that is no longer reachable via >    a Destination Down Message. The modem MUST notify the router of any >    changes in Hop Counts via Destination Update Messages.  Note that > -  normal DLEP processing is not otherwise modified by this document, this > -  includes the generation of Destination Down messages. > +  neither Destination Down or Update Message SHOULD NOT be sent for the > +  destination MAC address contained in the Link Characteristics > +  Response Message. >   >   >    A modem that receives the Hop Control Data Item in >    a Session Update Message >    SHOULD attempt to make the change indicated by the data item > -  for the associated destination MAC address, when carried in a Link > -  Characteristics Request Message, or all destinations, when carried in > -  a Session Update Message. Once the change is made, > -  or fails or is rejected, the modem MUST respond with a Link > Characteristics > -  Request Message containing an updated Hop Count Data Item.  Note that > -  other destinations can be impacted as a result of the change and such > -  changes are reported in > +  for all known destinations.  Once the change is made, or fails or is > +  rejected, the modem MUST respond with a Session Update Response > +  Message with an appropriate Status Code.  Destination specific > +  impact resulting from the processing of a Hop Control Data Item in a > +  Session Update Message is provided via >    Destination Down and Destination Update Messages.  The modem MUST >    notify the router of each destination that is no longer reachable via >    a Destination Down Message. The modem MUST notify the router of any > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Jan 29 14:26:09 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBF1201F8 for ; Mon, 29 Jan 2018 14:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 htJzsdx7o4CK for ; Mon, 29 Jan 2018 14:26:05 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8B126E3A for ; Mon, 29 Jan 2018 14:26:04 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w0TMQ3Ne028550; Mon, 29 Jan 2018 17:26:03 -0500 From: "Wiggins, David - 0665 - MITLL" To: Lou Berger , Justin Dean , "MANET IETF" Thread-Topic: [manet] Last call ending Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44AgADx3oCAAP27gIAAdeyAgAPbQICAAJbjAP//7EOA Date: Mon, 29 Jan 2018 22:26:01 +0000 Message-ID: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.118] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3600091561_1507085430" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290286 Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 22:26:08 -0000 --B_3600091561_1507085430 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I tried to clarify Suppress Forwarding: The Suppress Forwarding Action is used by a router to indicate to its peer that multi-hop forwarding performed by the modem is to be suppressed. A router may request that multi-hop forwarding may be suppressed on a device wide or destination specific basis. A modem which receives the Suppress Forwarding Data Item in a Session Update Message MUST suppress multi-hop forwarding on a device wide basis. For data traffic originating from the modem's peer router, the modem MUST only send such traffic to destinations that are one hop away. Any data traffic received from the modem MUST NOT be resent to another modem. Impact to destination hop counts are provided to the router by the modem as described above. A modem which receives the Suppress Forwarding Data Item in a Link Characteristics Request Message MUST suppress multi-hop forwarding for only the destination indicated in the message. Sending of traffic by the modem is modified as described in the previous paragraph, except that the suppression only applies to the specific destination given in the Link Characteristics Request Message. Results are provided as described above. Does that fit what was meant? Thanks, David On 1/29/18, 1:37 PM, "Lou Berger" wrote: ... David, (all) I think I've addressed all comments in the latest push to the repo. I'= m enclosing below a specific diff of the commit that addresses your comments, please take a look and let me know if you see any issues remaining. =20 Note I have clarified processing when hop control is in a=20 characteristics change message and changed/simplified in the Session=20 request massage case - to improve processing consistency as you=20 requested. Please see the specific changes below and let me know what=20 you think. =20 I also have one comment in response to your comment below. =20 On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: > > That=E2=80=99s why I was suggesting a radically different mechanism f= or the router=20 > > to express its wishes, e.g., by ordering the destinations in te= rms of=20 > > importance, and letting the modem work that information into it= s topology=20 > > control scheme however it can. The router=E2=80=99s most important d= estination may=20 > > be best reached over a 3-hop link. > > > =20 > To me this is a different extension with different objectives. I = certainly=20 > would be interested in reading that extension. >=20 > It has very similar objectives to the Direct Connection/Terminate par= t of this extension, but I agree that it doesn=E2=80=99t fit well in this extensio= n. =20 I think an extension that does this as well as let's a router understan= d some of the resource impacts of a manet topology (with out exposing the full topology ala ospf/isis-te) would be very interesting. I actually had some related discussion on this in singapore. If you have a proposal on this or are interested in collaborating on such, I'm very interested in this! =20 Thanks, =20 Lou =20 Changes from:=20 https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c660= 8b4a88428b20b14854f8f commit 100217f5a8a3e35c6608b4a88428b20b14854f8f Author: Lou Berger Date: Mon Jan 29 13:20:09 2018 -0500 =20 Multi-hop: Address remainder of Dave W. comments - Clean up Hop Behavior processing. Send only one message when link characteristic change result= s in a change/unreachable requested destination Destination impact due to Hop Control Data Item in a Session Update Message always provided via a Destination Down o= r Destination Update Message. =20 diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml=20 b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml index 5fc2845..f81e3be 100644 --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml @@ -110,7 +110,8 @@ words, each hop represents a transmission and the number of hops is equal to the number of transmissions required to go from a router connected modem to the destination's connected modem. The minimum - number of hops is 1, which represents the transmission by the router= 's + number of hops is 1, which represents transmission to destinations + that are directly reachable via the router's locally connected modem. @@ -176,7 +177,7 @@ A value of zero (0) is used to indicated that processing of a H= op Control action, see , has resul= ted in a destination no longer being reachable. A zero value MUST = NOT - be used in any message other then a Destination Announce Respons= e + be used in any message other then a Link Characteristics Respons= e Message. @@ -189,7 +190,8 @@ connectivity to a particular destination, or in multi-hop processin= g on a device wide basis. A router can request multi-hop reachable destination be changed to a single hop. A router can also indicate - that the modem terminate connectivity to a particular destination. + that the modem terminates a previous direct connectivity request to = a + particular destination. The Hop Control Data Item MAY be carried in a Session Update Messag= e @@ -218,20 +220,19 @@ notify the router of each destination that is no longer reachable v= ia a Destination Down Message. The modem MUST notify the router of any changes in Hop Counts via Destination Update Messages. Note that - normal DLEP processing is not otherwise modified by this document, t= his - includes the generation of Destination Down messages. + neither Destination Down or Update Message SHOULD NOT be sent for th= e + destination MAC address contained in the Link Characteristics + Response Message. A modem that receives the Hop Control Data Item in a Session Update Message SHOULD attempt to make the change indicated by the data item - for the associated destination MAC address, when carried in a Link - Characteristics Request Message, or all destinations, when carried i= n - a Session Update Message. Once the change is made, - or fails or is rejected, the modem MUST respond with a Link=20 Characteristics - Request Message containing an updated Hop Count Data Item. Note tha= t - other destinations can be impacted as a result of the change and suc= h - changes are reported in + for all known destinations. Once the change is made, or fails or is + rejected, the modem MUST respond with a Session Update Response + Message with an appropriate Status Code. Destination specific + impact resulting from the processing of a Hop Control Data Item in a + Session Update Message is provided via Destination Down and Destination Update Messages. The modem MUST notify the router of each destination that is no longer reachable v= ia a Destination Down Message. The modem MUST notify the router of any =20 =20 --B_3600091561_1507085430 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUWQYJKoZIhvcNAQcCoIIUSjCCFEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EjwwggT1MIID3aADAgECAgplPFVEAAAAAH4VMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwNDA0MTI0ODMyWhcNMTkwNDA0MTI0ODMyWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDJAb/lYMuBBR+S5pd/D61TZUVFI0iUnE1lDC0JOx9zyPDH inu2X2wN8x3uIO6/2xV9RjnuoORnzTv95Se/rhE7D4AfVZaj/i6oreCoLItIGph0E6Sl3SuA ALy9vHS0G9fCUm72xdOTkc2PqzIHHg8A9uN/pB8OTbktXgQMN/0TLarDF6u2LAswTQ2CxBWJ Hr9u78KA3QOkLWzQeua5aqINaHzYVrih5LTmAxI0B+h6Ug40hEViLRBfjN8jAJg4GF3dr42b GL4oDIS5eKFwSpbUR/jUKWNwoF1eG+jhAWdnUfHo7akVYxajXii9vqLmrsactqPZGu29HnO+ A6aoMM8PAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQU0xCKedODZWIHRzv1PlQPu4wdGwUwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQB8VMg24SrD vmqbj2l36MyBV02CV/ItcmUxfR8p+oGEGnm1veofenM7m9l3ZR3PHcM8lMQgCUmJrbNvF07G tRkehlflC8nujwv5szRG1lUv8UjYdYr9dFCBnEHGVY/FwQSV7Bz6tVyibQFlqZOnbyTKNmSm phroRbIulo971T4L3a9+2FX8n7PvjqG5Rn4yXNuPqVerQTcZN4pFbbo1lpuOK4wTVKlIvVoW NTfZPTxjbtNwfJYThlFyijTEur3XA1UL6+UoA9230Oz3+qL856RzJKOOBFoxZapor6nzjPDX 1ubAmBcwAlrXWNSzN0euX8wbPiOLSJvQ1LRpZsmJMxtfMIIEvDCCA6SgAwIBAgIBKTANBgkq hkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3Jh dG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAw MDAwMFoXDTIwMTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5j b2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANowUnVtfLbltbTcRuofAdJKnJBWUAALaBwp L1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7OlDOaL7wjn14NmyYA2JQQvSQ3CwR SJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCsN8PJYoVIsXj28VmndZu2TCim oL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8WvG8vsg8/Cc5OrD/YopY D94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+InwwCGjPXbW9OXMtYFw BUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDD Q+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6 Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xIC AQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsq hkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMB EDANBgkqhkiG9w0BAQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkk NA4bcyFfy0wsalC4znfh/h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSS O8lwQNg5GXBBIDlgvWx3KxJc1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqR lZ7tcUh204h3uw6n1kNrVTC1H9t12ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2Hizp I5cykbO+6/2jLDwCsepzGjr0S+wstD46edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5 LYzLDTrD3zCCA4MwggJroAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNTUlUTEwgUm9vdCBDQTAeFw0wODA5MjMxMjAwMDBaFw0yOTEyMzEyMzU5NTlaMFQxCzAJ BgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDFTikXWLImsvmtir9cEAqD3eQJMBMbsHDQ0YWkQnUDdeyvpQgir3/VUkE6ALAOqtWw ArWVHDL+WSsfM+ShuIyvXDONDbxJH/2yDmQByasyoFhtzfTaq3AIYpnF012ECHadQ4I7XQAy lSwI12mKQ9j26RPyWwD56iszhDWtz8vQnoAdGm05Tsi4MF1mP6101vuC/4YqSevrCP2baxUZ rChobsACqGxa9BQz+riH8fkWliXCdUASHYDOGqIb1vCXq4kkjMn/y5RaV02RXDPUjl9H+8Jr GItchbihTJ0G5EpMb56QSjEca4PvfLHkm2xJyJLwdAvagQzy2/5UAL5qVuqDAgMBAAGjYDBe MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFGeqes/0Cqa5crWKoNKd8hDDQ+0pMB8GA1Ud IwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0pMAsGA1UdDwQEAwIBhjANBgkqhkiG9w0BAQUF AAOCAQEAPhttBWDQeHjYSlhfj8k+Q1Lc5QARZH9iDNlRjVAaL2tBnil9yNTX9Nqg1Pxjth/R E75702Ib34EOFAf+RCJk5Cj2u/01RvzEO0oJgJp3vMRC1Wxixa68rZcvD8mLWbZ4G+g4HhFL /ksBZ83Cztb4Na3ZrLN5MLKstKvHtlWAGPM06bRM8iRt+ml3CDG6jsVkvy2z4zbj3YCXzt3d Vqx69RLWmmtEES6kKGY9O3WGO1qORA6lPgFADM/WVURitbOW/47+Vs/2K6MqlhZx9ipDcUZ/ ftgK+4N656zjGb6eqbKto2w14jwaHdcMjCp/MecuHLhjzRXKo38mPx1/dIr0ADCCBPgwggPg oAMCAQICCmVBPb8AAAAAfhkwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMzAeFw0xNjA0MDQxMjUzNTdaFw0xOTA0MDQxMjUzNTdaMGIxCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxITAf BgNVBAMTGFdpZ2dpbnMuRGF2aWQuUC41MDAxNTIwNzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxLr6lj3p6xTBv4hIMClz+oodyhI36yILLxw3lpNWMLMRgicN0xp5qE/TYq eA9JovmLQKXi5zy2NoOHo5I4xT7rgctVStlMoub/Cu+yU4AbQFY/TPUoeTcnPE8sSIdaZ8ya ZrRpzRMbZe4U6tbqhRMfoIZ8wwVoddo13wFhTd3tuKnBN/3KSowHy5rlBNmPz4rl6kjbr+l+ bLwqwnDu0LkgLXIe0s+pS+VhMpAegi4Glt7VBblvpk8gkZ2WLLb6F2V5Osdrk5auCLOwziIe TkysfpH/OJ8fwXw9spgHH8xvSzxv09mcLe+c6RyAcfCclemgVAwm5BioBvEdyFImbK8CAwEA AaOCAb8wggG7MB0GA1UdDgQWBBTK35v8BBqQXPD5Ewd/My8jOgtQ1TAOBgNVHQ8BAf8EBAMC BSAwHwYDVR0jBBgwFoAU12BmDntJjXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYI KwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcw AYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQB gjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0gAgFkAgEFMCUGA1UdJQQeMBwGBFUd JQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwIwYD VR0RBBwwGoEYRGF2aWQuV2lnZ2luc0BsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAE0UyFocglrX8UuUfV+S 6s4dgmpdkLuTDkrcdrhVY2X0jQZpqoL0sS6HrgFMto92VizlP0TRlmkcuONlX7KhJaP9/HCr yrylnV/fJ+ZbCGIaT6DOiQZNCYrjTpPgolXfNYjLwOwOev8l3ORSU7Oj7/R4RTVPDlUg+2KS RyVh/AumAw1dHwffTMtuAYXo5GtDKWzO9i1Q/QDRksiBhUtf1LoXLDskwf5hatrLav1AVIR2 BtD0pIi2NWsT2+zWFO5qkzqh81aVhHxRAs2Fry80eiH/pMkLvo6rR/4OdqsGFyvPxOgq33c0 wKHMaERy/bxTVLUD166IUvJIfE55/PwFTYIxggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMCCmU8VUQAAAAAfhUwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBTX/tHKXGkA/3mM6AhMW+sG0eyqzTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODAxMjkyMjI2MDFaMA0GCSqGSIb3DQEBAQUABIIBAFhpAS7SwJ/6S4I5 WHN5bCbY3kEmfNUUYf6aNvZhwGBqaKQKLRKUoHke7h6wL4WNT2VVvuwWAJgtMn1CZ+svCNL5 AobyC0I8byQLCMiZ0+POQZDndIz6QiN0m7DucCLFUGXU660szPkqwQIRgWrSCoYwyrwh0RI0 hjKx9XWNzz6eDzGjFJvHQHdKh61zPC8Z9YprIX7AN23QguXNMqKtIEANWHoCV+I0iHE4PabY ZOExA1weDUbz2AR8htzlY5tE+3rx6eBvSBlYshaQYkfoJR7DDBZSUbsfAyjAZ10lMTDY+mms 1ZzrrGgS/rI4F0HDDurFGNRP3NE754xUz02QFyw= --B_3600091561_1507085430-- From nobody Mon Jan 29 14:39:25 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6613193B for ; Mon, 29 Jan 2018 14:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ntawuptzro75 for ; Mon, 29 Jan 2018 14:39:20 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3047A1270B4 for ; Mon, 29 Jan 2018 14:39:20 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id d21so7724307qkj.3 for ; Mon, 29 Jan 2018 14:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2hl29O09TClwr7pLo9dE0zdtZh+/dO+ZO8bzNt9GrIA=; b=aeQ9VLIib6ju3dZfj4vCBtQHs/+xGaGjH/j6fGm6vAZ8xbwfm3yqg/LScy5yb62sjh p/R+HZmVi0dVcktphrl5i3dghUhHp+oPI5UopwoYoS0ZjHg+/cPmpAMo6FV+x6bYeJJd D8ZzegJFRX/TO3Hql+0l5SNDjcCMspqm4/UX2/Df7SAKUqe4bauacwb8RZQoMvY0Jl3C FGf1wifn7HEf0QH3bvieBc2/AeKRvRLZQB0b2EMm2JbzgTINpOi+r5kEjYQa9EVL7Dhe AfhTimLJ2hwBMLE3PpZtnJRmOLrS1wa9NCPFedXAJZWurHh7bZvs4IEW+GDDAlPwKEPz qTjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2hl29O09TClwr7pLo9dE0zdtZh+/dO+ZO8bzNt9GrIA=; b=AlVjphYaMuh0lVJC7DY0QQsNkT6zdNEo7KmljsR2uqe6nDyBMuSw0fadnex5mn9LaK mzljLjnYN+7ePAdlx0TI9sId79zw18quePSEk5heE0I5FPBpe/8e1q9oX7A+ySVtnvaE zXiPnb8hZ7zsU2pMDZ3uyc/Ga1ul0u1w+Wnt60pTvqDCZO0pZthsA2n7O4aoFyeKLXq8 QLuZaEup/o8dbjx6jJDpcSmezKJ+aqK5G2Ar9wXcvohLRTAZ+vMgKWwCL2bcfCjbGc3k nQdBDxQY7NK2ylMd+EMixOnCfgeV6EKtnr7WmksdhS+Mnh6Fgl6tAPrYBR7KJIuw7WNZ Nhaw== X-Gm-Message-State: AKwxytf3Wq4jXzJm7EutZoVQsFxFw+t/O0AsU6DKtmhG2GF4QQfwMPZ/ 2l2qmhKNhPLKW8WzmqYXwWs= X-Google-Smtp-Source: AH8x226MPAuwNQ+J9MIM7W0hNPdJpjhaCwhZxb53Pk3mOUiSg38dbT+PdOpkIE+GKBcI26dr9N3trA== X-Received: by 10.55.20.139 with SMTP id 11mr37326032qku.66.1517265559239; Mon, 29 Jan 2018 14:39:19 -0800 (PST) Received: from [172.25.6.122] ([152.16.191.33]) by smtp.gmail.com with ESMTPSA id k21sm11035657qta.12.2018.01.29.14.39.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 14:39:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Stan Ratliff X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Mon, 29 Jan 2018 17:39:18 -0500 Cc: Lou Berger , Justin Dean , MANET IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: "Wiggins, David - 0665 - MITLL" Archived-At: Subject: Re: [manet] Last call ending X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 22:39:23 -0000 Sent from my iPhone > On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL wrote: >=20 > I tried to clarify Suppress Forwarding: >=20 > The Suppress Forwarding Action is used by a router to indicate to its > peer that multi-hop forwarding performed by the modem is to be > suppressed. A router may request that multi-hop forwarding may be > suppressed on a device wide or destination specific basis. >=20 > A modem which receives the Suppress Forwarding Data Item in a Session > Update Message MUST suppress multi-hop forwarding on a device wide > basis. This concerns me. Should the modem a) silently drop traffic unless/until the multi-hop destination(s) become si= ngle-hop again? (Bad plan, IMO) Or, b) issue Destination Down for multi-hop destination(s), and re-issue Destina= tion Up If/when the dest is single-hop? Regards,=20 Stan > For data traffic originating from the modem's peer router, the > modem MUST only send such traffic to destinations that are one hop > away. Any data traffic received from the modem MUST NOT be resent to > another modem. Impact to destination hop counts are provided to the > router by the modem as described above. >=20 > A modem which receives the Suppress Forwarding Data Item in a Link > Characteristics Request Message MUST suppress multi-hop forwarding for > only the destination indicated in the message. Sending of traffic by > the modem is modified as described in the previous paragraph, except > that the suppression only applies to the specific destination given in > the Link Characteristics Request Message. Results are provided as > described above. >=20 > Does that fit what was meant? >=20 > Thanks, > David >=20 >=20 >=20 > On 1/29/18, 1:37 PM, "Lou Berger" wrote: >=20 > ... > David, (all) > I think I've addressed all comments in the latest push to the repo. I'= m > enclosing below a specific diff of the commit that addresses your > comments, please take a look and let me know if you see any issues > remaining. >=20 > Note I have clarified processing when hop control is in a=20 > characteristics change message and changed/simplified in the Session=20= > request massage case - to improve processing consistency as you=20 > requested. Please see the specific changes below and let me know what=20= > you think. >=20 > I also have one comment in response to your comment below. >=20 > On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote: >>> That=E2=80=99s why I was suggesting a radically different mechanism for t= he router=20 >>> to express its wishes, e.g., by ordering the destinations in terms of=20= >>> importance, and letting the modem work that information into its topolog= y=20 >>> control scheme however it can. The router=E2=80=99s most important dest= ination may=20 >>> be best reached over a 3-hop link. >>>=20 >>=20 >> To me this is a different extension with different objectives. I certa= inly=20 >> would be interested in reading that extension. >>=20 >> It has very similar objectives to the Direct Connection/Terminate part of= this extension, but I agree that it doesn=E2=80=99t fit well in this extens= ion. >=20 > I think an extension that does this as well as let's a router understan= d > some of the resource impacts of a manet topology (with out exposing the= > full topology ala ospf/isis-te) would be very interesting. I actually > had some related discussion on this in singapore. If you have a > proposal on this or are interested in collaborating on such, I'm very > interested in this! >=20 > Thanks, >=20 > Lou >=20 > Changes from:=20 > https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c660= 8b4a88428b20b14854f8f > commit 100217f5a8a3e35c6608b4a88428b20b14854f8f > Author: Lou Berger > Date: Mon Jan 29 13:20:09 2018 -0500 >=20 > Multi-hop: Address remainder of Dave W. comments > - Clean up Hop Behavior processing. > Send only one message when link characteristic change result= s in > a change/unreachable requested destination > Destination impact due to Hop Control Data Item in a Session= > Update Message always provided via a Destination Down o= r > Destination Update Message. >=20 > diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml=20= > b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > index 5fc2845..f81e3be 100644 > --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml > @@ -110,7 +110,8 @@ > words, each hop represents a transmission and the number of hops is= > equal to the number of transmissions required to go from a router > connected modem to the destination's connected modem. The minimum > - number of hops is 1, which represents the transmission by the router= 's > + number of hops is 1, which represents transmission to destinations > + that are directly reachable via the router's > locally connected > modem. > > @@ -176,7 +177,7 @@ > A value of zero (0) is used to indicated that processing of a H= op > Control action, see , has res= ulted > in a destination no longer being reachable. A zero value MUST N= OT > - be used in any message other then a Destination Announce Respons= e > + be used in any message other then a Link Characteristics Respons= e > Message. > > > @@ -189,7 +190,8 @@ > connectivity to a particular destination, or in multi-hop processin= g > on a device wide basis. A router can request multi-hop reachable > destination be changed to a single hop. A router can also indicate= > - that the modem terminate connectivity to a particular destination. > + that the modem terminates a previous direct connectivity request to a= > + particular destination. > > > The Hop Control Data Item MAY be carried in a Session Update Messag= e > @@ -218,20 +220,19 @@ > notify the router of each destination that is no longer reachable v= ia > a Destination Down Message. The modem MUST notify the router of any= > changes in Hop Counts via Destination Update Messages. Note that > - normal DLEP processing is not otherwise modified by this document, t= his > - includes the generation of Destination Down messages. > + neither Destination Down or Update Message SHOULD NOT be sent for th= e > + destination MAC address contained in the Link Characteristics > + Response Message. > > > A modem that receives the Hop Control Data Item in > a Session Update Message > SHOULD attempt to make the change indicated by the data item > - for the associated destination MAC address, when carried in a Link > - Characteristics Request Message, or all destinations, when carried i= n > - a Session Update Message. Once the change is made, > - or fails or is rejected, the modem MUST respond with a Link=20 > Characteristics > - Request Message containing an updated Hop Count Data Item. Note tha= t > - other destinations can be impacted as a result of the change and suc= h > - changes are reported in > + for all known destinations. Once the change is made, or fails or is= > + rejected, the modem MUST respond with a Session Update Response > + Message with an appropriate Status Code. Destination specific > + impact resulting from the processing of a Hop Control Data Item in a= > + Session Update Message is provided via > Destination Down and Destination Update Messages. The modem MUST > notify the router of each destination that is no longer reachable v= ia > a Destination Down Message. The modem MUST notify the router of any= >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Jan 30 06:06:46 2018 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 840AF13192A; Tue, 30 Jan 2018 06:06:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151732120050.27516.9349844420176741896@ietfa.amsl.com> Date: Tue, 30 Jan 2018 06:06:40 -0800 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:06:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : Link Identifier Extension to DLEP Authors : Rick Taylor Stan Ratliff Filename : draft-ietf-manet-dlep-lid-extension-01.txt Pages : 8 Date : 2018-01-30 Abstract: There exists a class of modems that wish to support the Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a single Layer 2 network domain as required by DLEP. Such devices may be: o Modems that maintain a varying link to some upstream backbone network infrastructure, where the ability to announce link state and DLEP metrics is desired, but the concept of a DLEP destination router for the backbone does not apply. Examples of such devices can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, and some satellite terminals. o Modems that provide Layer 3 wide area network connectivity between devices, where individual DLEP destinations do exist, but are not directly reachable by MAC address. This document introduces an optional extension to the core DLEP specification, allowing DLEP to be used between routers and modems that operate in this way. Note: o This document is intended as an extension to the core DLEP specification, and readers are expected to be fully conversant with the operation of core DLEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-lid-extension-01 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-lid-extension-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-lid-extension-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 30 12:52:44 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7C12EA91; Tue, 30 Jan 2018 12:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bjS3WGej90-Y; Tue, 30 Jan 2018 12:52:39 -0800 (PST) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4246B120227; Tue, 30 Jan 2018 12:52:38 -0800 (PST) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 30 Jan 2018 20:52:35 +0000 From: Rick Taylor To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Thread-Index: AQHTmdOgPD5qpa5rD0Sntsrb0M70f6OM5Np8 Date: Tue, 30 Jan 2018 20:52:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D32E95D5@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801D32E95D5tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 20:52:41 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801D32E95D5tssserver1hom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All I have pushed out a new version of the link is draft. This version has some= minor text improvements hopefully clarifying some behavior. Any reviews gratefully received, as I'd like to push for last call as I kno= w people are looking to implement Cheers Rick (Sent from my phone) ----- Reply message ----- From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Cc: "manet@ietf.org" Subject: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt Date: Tue, Jan 30, 2018 14:07 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. Title : Link Identifier Extension to DLEP Authors : Rick Taylor Stan Ratliff Filename : draft-ietf-manet-dlep-lid-extension-01.txt Pages : 8 Date : 2018-01-30 Abstract: There exists a class of modems that wish to support the Dynamic Link Exchange Protocol (DLEP) [RFC8175] but do not present a single Layer 2 network domain as required by DLEP. Such devices may be: o Modems that maintain a varying link to some upstream backbone network infrastructure, where the ability to announce link state and DLEP metrics is desired, but the concept of a DLEP destination router for the backbone does not apply. Examples of such devices can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, and some satellite terminals. o Modems that provide Layer 3 wide area network connectivity between devices, where individual DLEP destinations do exist, but are not directly reachable by MAC address. This document introduces an optional extension to the core DLEP specification, allowing DLEP to be used between routers and modems that operate in this way. Note: o This document is intended as an extension to the core DLEP specification, and readers are expected to be fully conversant with the operation of core DLEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-lid-extension-01 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-lid-extension-0= 1 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-lid-extension-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_38A5475DE83986499AEACD2CFAFC3F9801D32E95D5tssserver1hom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All

I have pushed out a new version of the link is draft. This version has s= ome minor text improvements hopefully clarifying some behavior. 
=

Any reviews gratefully received= , as I'd like to push for last call as I know people are looking to impleme= nt

Cheers

Rick

(Sent from my phone)

----- Reply message -----
From: "internet-draf= ts@ietf.org" <internet-drafts@ietf.org>
To: "i-d-announc= e@ietf.org" <i-d-announce@ietf.org>
Cc: "manet@ietf.org&= quot; <manet@ietf.org>
Subject: [manet] I-D Action: draft-ietf-man= et-dlep-lid-extension-01.txt
Date: Tue, Jan 30, 2018 14:07
<= br> A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

        Title    &nb= sp;      : Link Identifier Extension to DLEP
        Authors    &= nbsp;    : Rick Taylor
            &nb= sp;            = Stan Ratliff
        Filename    =     : draft-ietf-manet-dlep-lid-extension-01.txt
        Pages    &nb= sp;      : 8
        Date    &nbs= p;       : 2018-01-30

Abstract:
   There exists a class of modems that wish to support the Dynami= c Link
   Exchange Protocol (DLEP) [RFC8175] but do not present a single= Layer
   2 network domain as required by DLEP.  Such devices may b= e:

   o  Modems that maintain a varying link to some upstream b= ackbone
      network infrastructure, where the ability to= announce link state
      and DLEP metrics is desired, but the concept= of a DLEP destination
      router for the backbone does not apply. = ; Examples of such devices
      can include LTE modems, IEEE 802.11 stations= not in ad-hoc mode,
      and some satellite terminals.

   o  Modems that provide Layer 3 wide area network connecti= vity between
      devices, where individual DLEP destinations = do exist, but are not
      directly reachable by MAC address.

   This document introduces an optional extension to the core DLE= P
   specification, allowing DLEP to be used between routers and mo= dems
   that operate in this way.

   Note:

   o  This document is intended as an extension to the core = DLEP
      specification, and readers are expected to b= e fully conversant
      with the operation of core DLEP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension= /

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-dlep-lid-extension-01<= br> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-l= id-extension-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-lid-e= xtension-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet
 --_000_38A5475DE83986499AEACD2CFAFC3F9801D32E95D5tssserver1hom_-- From nobody Wed Jan 31 14:02:55 2018 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5712FA81 for ; Wed, 31 Jan 2018 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YWkuErYFJJNM for ; Wed, 31 Jan 2018 14:02:51 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E203D126CC7 for ; Wed, 31 Jan 2018 14:02:50 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id m11so16892117iob.2 for ; Wed, 31 Jan 2018 14:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aEfL0oWHsVlngbuRYqDQVAqkaW9qnz6v4QlGffTek2Q=; b=j05/1ZvL24M916b096GH1WWWr2GqKV1osmc0IrH5baHuKV2wEvc271tXOfOJQV3fKY KbynLwzf8/GM0j2NsCXFnRQ2Ub1fQjNehZCXPEAkCQsB225Ub9CjlJ0lvVks2d8ky875 Jb+8alffEdFYoVwIHD83AryNz+Uet7Sq1UHgmtCkCD4xu0efwc2j8wBIy1nxo+GTcEfj Iib7ZkHx7z7tnDVroEs7r2NgVw9AhoFKkPuAiSEn+KlxstR/oZFjk1yLmagpHlrdBDF2 05SdAJp1iuWVOwFaRBqWdkUEyLzfl7gD5ikg8DWtrdzd1XZsIT7OwVXWprj8iul0XXqK G5OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aEfL0oWHsVlngbuRYqDQVAqkaW9qnz6v4QlGffTek2Q=; b=lPXgmKyBqzgH/fnqFXbbfp/F6P3TVtHC4HZzqQVrEUp3xARibfccFsNyfOCkC2UJ63 Ki4Ab11p0ydvdv31iomeolCBL2yr0DVc67EDPqwCAGoIWFgHYvJPzWb4qaiUuI5ZQOhx xu3f+KmsPx0z4prKY/F5C8JnGwDlBwvwlbEkgmdiIB0daEIa/z5S25a4wHW70WGxFyGj KZH5O54QKDEmr41U+bmiR00M8T9HRaEvdMYlEHw4MLvDFmCP/VHV6BsNNdxPCS+lgIzA XzQZ3JW8GH/9ko+q2zPsDe/bgK77bg2gEzi9tJ8y8faZXLoHm4Za2rHdpDGOKG7+DLU4 3DQQ== X-Gm-Message-State: AKwxytck1SUJhfsxHEECjuYGzh2x1hvlS2FZ3NpLdBtg7WtLd9zxXs/c 0HqA+iDFh5W8PnH+k708yzDPA85/JYLZJdbwWFmBYg== X-Google-Smtp-Source: AH8x225hv2dEWHmYGI3oNkQj6/GuZAevUS5uk077XXtAjTzWSITLEZ6ZjHUtNa9YbWZS3Fk1Ucc2lN6u7H91pQbdmfE= X-Received: by 10.107.139.78 with SMTP id n75mr36988323iod.252.1517436170232; Wed, 31 Jan 2018 14:02:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.61.10 with HTTP; Wed, 31 Jan 2018 14:02:49 -0800 (PST) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801D32E95D5@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F9801D32E95D5@tss-server1.home.tropicalstormsoftware.com> From: Victoria Pritchard Date: Wed, 31 Jan 2018 22:02:49 +0000 Message-ID: To: Rick Taylor Cc: "manet@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05b62ce56a89056419a3e5" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 22:02:54 -0000 --94eb2c05b62ce56a89056419a3e5 Content-Type: text/plain; charset="UTF-8" Hi Rick, The new text is good, this is a well written draft, clear and easy to read. Only issue I can see is "it does not with to use" in section 3.1 - do you mean "it does not wish to use"? Regards, Vicky. On 30 January 2018 at 20:52, Rick Taylor wrote: > Hi All > > I have pushed out a new version of the link is draft. This version has > some minor text improvements hopefully clarifying some behavior. > > Any reviews gratefully received, as I'd like to push for last call as I > know people are looking to implement > > Cheers > > Rick > > (Sent from my phone) > > ----- Reply message ----- > From: "internet-drafts@ietf.org" > To: "i-d-announce@ietf.org" > Cc: "manet@ietf.org" > Subject: [manet] I-D Action: draft-ietf-manet-dlep-lid-extension-01.txt > Date: Tue, Jan 30, 2018 14:07 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF. > > Title : Link Identifier Extension to DLEP > Authors : Rick Taylor > Stan Ratliff > Filename : draft-ietf-manet-dlep-lid-extension-01.txt > Pages : 8 > Date : 2018-01-30 > > Abstract: > There exists a class of modems that wish to support the Dynamic Link > Exchange Protocol (DLEP) [RFC8175] but do not present a single Layer > 2 network domain as required by DLEP. Such devices may be: > > o Modems that maintain a varying link to some upstream backbone > network infrastructure, where the ability to announce link state > and DLEP metrics is desired, but the concept of a DLEP destination > router for the backbone does not apply. Examples of such devices > can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, > and some satellite terminals. > > o Modems that provide Layer 3 wide area network connectivity between > devices, where individual DLEP destinations do exist, but are not > directly reachable by MAC address. > > This document introduces an optional extension to the core DLEP > specification, allowing DLEP to be used between routers and modems > that operate in this way. > > Note: > > o This document is intended as an extension to the core DLEP > specification, and readers are expected to be fully conversant > with the operation of core DLEP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-lid-extension-01 > https://datatracker.ietf.org/doc/html/draft-ietf-manet- > dlep-lid-extension-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-lid-extension-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --94eb2c05b62ce56a89056419a3e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rick,

The new text is good, this is a well writt= en draft, clear and easy to read.

Only issue I can see is "it d= oes not with to use" in section 3.1 - do you mean "it does not wi= sh to use"?

Regards,
Vicky.


On 30 January 2018 at 20:52= , Rick Taylor <rick@tropicalstormsoftware.com> = wrote:
Hi All

I have pushed out a new version of the link is draft. This versi= on has some minor text improvements hopefully clarifying some behavior.=C2= =A0

Any reviews gratefully= received, as I'd like to push for last call as I know people are looki= ng to implement



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Link Identifier Extension to DLEP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 : Rick Taylor
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Stan Ratliff
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 : draft-ietf-manet-dlep-lid-extension-01.txt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 8
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2018-01-30

Abstract:
=C2=A0=C2=A0 There exists a class of modems that wish to support the Dynami= c Link
=C2=A0=C2=A0 Exchange Protocol (DLEP) [RFC8175] but do not present a single= Layer
=C2=A0=C2=A0 2 network domain as required by DLEP.=C2=A0 Such devices may b= e:

=C2=A0=C2=A0 o=C2=A0 Modems that maintain a varying link to some upstream b= ackbone
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 network infrastructure, where the ability to= announce link state
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and DLEP metrics is desired, but the concept= of a DLEP destination
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 router for the backbone does not apply.=C2= =A0 Examples of such devices
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can include LTE modems, IEEE 802.11 stations= not in ad-hoc mode,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and some satellite terminals.

=C2=A0=C2=A0 o=C2=A0 Modems that provide Layer 3 wide area network connecti= vity between
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 devices, where individual DLEP destinations = do exist, but are not
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directly reachable by MAC address.

=C2=A0=C2=A0 This document introduces an optional extension to the core DLE= P
=C2=A0=C2=A0 specification, allowing DLEP to be used between routers and mo= dems
=C2=A0=C2=A0 that operate in this way.

=C2=A0=C2=A0 Note:

=C2=A0=C2=A0 o=C2=A0 This document is intended as an extension to the core = DLEP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specification, and readers are expected to b= e fully conversant
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the operation of core DLEP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-m= anet-dlep-lid-extension/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-dle= p-lid-extension-01
https://datatracker.ietf.org/doc/html/= draft-ietf-manet-dlep-lid-extension-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-manet-dlep-lid-extension-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--94eb2c05b62ce56a89056419a3e5--