Re: [manet] Last call ending
"Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu> Mon, 29 January 2018 22:26 UTC
Return-Path: <prvs=55678ac255=david.wiggins@ll.mit.edu>
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 <manet@ietfa.amsl.com>; 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 <manet@ietfa.amsl.com>; 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 <manet@ietf.org>; 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" <David.Wiggins@ll.mit.edu>
To: Lou Berger <lberger@labn.net>, Justin Dean <bebemaster@gmail.com>, MANET IETF <manet@ietf.org>
Thread-Topic: [manet] Last call ending
Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44AgADx3oCAAP27gIAAdeyAgAPbQICAAJbjAP//7EOA
Date: Mon, 29 Jan 2018 22:26:01 +0000
Message-ID: <B9FA19D1-F931-474E-86C4-2C3DFF050B1A@ll.mit.edu>
References: <CA+-pDCeA5z0+YE4yXYymkWo8vNthp2k6Pt9nHr32z+ApCLum_A@mail.gmail.com> <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <b4faeff9-6fce-cf6c-83a5-ed1db17430e3@labn.net> <B4268EF6-B15D-4C56-A5A1-9B3522ED7F79@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <AA080710-A519-442C-89D7-BADE0EBF030F@ll.mit.edu> <c49477df-40b0-6ccc-3c5b-2df92cec177e@labn.net>
In-Reply-To: <c49477df-40b0-6ccc-3c5b-2df92cec177e@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_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: <https://mailarchive.ietf.org/arch/msg/manet/ZYgsxtM-xA5s_j3G9ew8g5RtSwc>
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 <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 22:26:08 -0000
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" <lberger@labn.net> 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 <lberger@labn.net> 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. </t> @@ -176,7 +177,7 @@ A value of zero (0) is used to indicated that processing of a Hop Control action, see <xref target="sec-di-hcontrol"/>, 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. </t> </list> @@ -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. </t> <t> 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. </t> <t> 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] Last call ending Justin Dean
- Re: [manet] Last call ending Wiggins, David - 0665 - MITLL
- Re: [manet] Last call ending Rick Taylor
- Re: [manet] Last call ending MATTY, Steven [UK]
- Re: [manet] Last call ending Stan Ratliff
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Wiggins, David - 0665 - MITLL
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Wiggins, David - 0665 - MITLL
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Wiggins, David - 0665 - MITLL
- Re: [manet] Last call ending Stan Ratliff
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Lou Berger
- Re: [manet] Last call ending Stan Ratliff
- Re: [manet] Last call ending Lou Berger