Re: [manet] Last call ending

"Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu> Thu, 25 January 2018 15:07 UTC

Return-Path: <prvs=45637bf078=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 4BBB912DA53 for <manet@ietfa.amsl.com>; 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 <manet@ietfa.amsl.com>; 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 <manet@ietf.org>; 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" <David.Wiggins@ll.mit.edu>
To: Justin Dean <bebemaster@gmail.com>, MANET IETF <manet@ietf.org>
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: <CA+-pDCeA5z0+YE4yXYymkWo8vNthp2k6Pt9nHr32z+ApCLum_A@mail.gmail.com>
In-Reply-To: <CA+-pDCeA5z0+YE4yXYymkWo8vNthp2k6Pt9nHr32z+ApCLum_A@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/manet/CT88CFjhvPAakEHccJvQ_y3FiZQ>
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: Thu, 25 Jan 2018 15:07:26 -0000

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 <manet-bounces@ietf.org> on behalf of Justin Dean <bebemaster@gmail.com>
Date: Tuesday, January 23, 2018 at 11:30 AM
To: MANET IETF <manet@ietf.org>
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