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
- [manet] DLEP redundant Destination Ups Wiggins, David - 0665 - MITLL
- Re: [manet] DLEP redundant Destination Ups Stan Ratliff
- Re: [manet] DLEP redundant Destination Ups Rick Taylor
- Re: [manet] DLEP redundant Destination Ups Wiggins, David - 0665 - MITLL
- Re: [manet] DLEP redundant Destination Ups Rick Taylor
- Re: [manet] DLEP redundant Destination Ups Stan Ratliff