Re: [manet] DLEP redundant Destination Ups

Rick Taylor <rick@tropicalstormsoftware.com> Fri, 09 August 2019 20:50 UTC

Return-Path: <rick@tropicalstormsoftware.com>
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 76288120077 for <manet@ietfa.amsl.com>; Fri, 9 Aug 2019 13:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 AfaQ2_5kXdHp for <manet@ietfa.amsl.com>; Fri, 9 Aug 2019 13:49:59 -0700 (PDT)
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 D304912006B for <manet@ietf.org>; Fri, 9 Aug 2019 13:49:58 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Fri, 9 Aug 2019 21:49:56 +0100
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Stan Ratliff <ratliffstan@gmail.com>, "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu>
CC: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] DLEP redundant Destination Ups
Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7abzI/kAgAAlVeA=
Date: Fri, 09 Aug 2019 20:49:56 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com>
References: <E2AD4802-3193-4ACC-B3D9-3162A8EB7CB1@ll.mit.edu> <CALtoyo=K1xamjQ4_pBgeZQ8rp75_v5gwPt_Ux0u7RmYsZRQcnw@mail.gmail.com>
In-Reply-To: <CALtoyo=K1xamjQ4_pBgeZQ8rp75_v5gwPt_Ux0u7RmYsZRQcnw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2a02:1648:4000:120:15fe:c469:8a18:dba8]
Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801E6C0A715tssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/BkzpVKmpPHES79OxPepx1_5T8Ug>
Subject: Re: [manet] DLEP redundant Destination Ups
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Aug 2019 20:50:01 -0000

David,

I’m not sure this is an errata, but some clarification may be required.  I would expect a Destination Up Response with an error status of “Invalid Destination” (Terminate) if the receiver cannot handle the situation, or perhaps “Inconsistent Data” if it can continue.

Does that help?

Cheers,
Rick

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent: 09 August 2019 20:33
To: Wiggins, David - 0665 - MITLL
Cc: manet@ietf.org
Subject: Re: [manet] DLEP redundant Destination Ups

David,

This looks like it's a candidate for an errata. I think what *should* be done is for the router to respond with a "Destination Up Response", using a new status code that effectively says "State Error", or "Destination is already up". Then I think the router should treat the second Destination Up as a *Destination Down*, which resets the state error.

My rationale for not just ignoring the 2nd Dest up, or treating it as a Dest Update is that there *could be* associated data with the Dest Up, like IPv4/IPv6 address data items, and/or connected subnet data items, that may or may not clash with the new Dest Up. IMO, best to clean it up and try again "from scratch". I don't think this sould trigger a complete peer session outage.

Other opinions?

Regards,
Stan


On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David - 0665 - MITLL <David.Wiggins@ll.mit.edu<mailto:David.Wiggins@ll.mit.edu>> wrote:
If a modem sends two Destination Ups for the same destination without an intervening Destination Down for that destination, how should the router respond?

a) This is a protocol error.  Terminate the session.
b) Ignore the second Destination Up.
c) Treat the second Destination Up as a Destination Update.
d) something else

Thanks,
David

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