Re: [manet] DLEP redundant Destination Ups

Rick Taylor <rick@tropicalstormsoftware.com> Sat, 10 August 2019 16:37 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 7E65C120046 for <manet@ietfa.amsl.com>; Sat, 10 Aug 2019 09:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FvhB0WuYmUW2 for <manet@ietfa.amsl.com>; Sat, 10 Aug 2019 09:37:09 -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 0D3A2120111 for <manet@ietf.org>; Sat, 10 Aug 2019 09:37:09 -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; Sat, 10 Aug 2019 17:37:06 +0100
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu>, Stan Ratliff <ratliffstan@gmail.com>
CC: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] DLEP redundant Destination Ups
Thread-Index: AQHVTuJFidsVE35B90GHgDX2g+eI7abzI/kAgAAlVeCAATBdAIAAG7Fg
Date: Sat, 10 Aug 2019 16:37:04 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DB@tss-server1.home.tropicalstormsoftware.com>
References: <E2AD4802-3193-4ACC-B3D9-3162A8EB7CB1@ll.mit.edu> <CALtoyo=K1xamjQ4_pBgeZQ8rp75_v5gwPt_Ux0u7RmYsZRQcnw@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F9801E6C0A715@tss-server1.home.tropicalstormsoftware.com> <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu>
In-Reply-To: <255BBAD2-529D-4C41-A763-1122448C64B5@ll.mit.edu>
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_38A5475DE83986499AEACD2CFAFC3F9801E6C0A8DBtssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/ILqKKXYePgAFrf9ZmSQQBeSQafw>
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: Sat, 10 Aug 2019 16:37:13 -0000

Hi David,

As a first thought – and I need to have a longer think to check my assumptions – your second ‘odd’ Destination Up should probably be a Destination Update.

In my mind, the modem is informing the modem of a change to an *existing* destination, hence update, rather than a *new* destination.

Let me ponder a little more, but I’m interested what others think.

Cheers,

Rick

From: Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu]
Sent: 10 August 2019 16:56
To: Rick Taylor; Stan Ratliff
Cc: manet@ietf.org
Subject: Re: [manet] DLEP redundant Destination Ups

Stan, Rick,

Thanks for the quick response.  It helps to know that you both think it should be an error (I do too), though we have different ideas on what the exact behavior should be.  I would probably go with Rick’s second suggestion, “Inconsistent Data” (Continue).  I’m not a fan of implementation-defined behavior, so I’d rather there be exactly one way to handle this.  Actually I think “Invalid Destination” (Continue) would make a bit more sense, but the failure mode for “Invalid Destination” is defined to be Terminate, and there isn’t an easy way to change that.

This issue is one piece of the larger issue of how multicast destinations are handled.  I see in the minutes that was discussed at IETF 105; regrettably, I wasn’t able to join the discussion.  So here is the difficulty I’m having with multicast.  Let’s assume for a moment the following:

- Two Destination Ups for the same destination (without Down in between) is a protocol error
- A Destination Announce Response is exactly semantically equivalent to a Destination Up
- A Destination Announce w/ multicast destination is expressing a multicast group join by the local node
- A Destination Up w/ multicast destination expresses that some other node has joined the multicast group

Then the following bad behavior can occur:

- Router sends Destination Announce w/ multicast destination (group)
- Modem sends Destination Announce Response for that group, and this counts as a Destination Up (by the above assumptions)
- Some other node joins the same group, and this gets propagated via non-DLEP means to the local modem
- Modem sends a Destination Up for the group to let the router know there are other (unidentified) group members out there
- Router considers this an error because it’s two Destination Ups for the same destination

This is essentially what happens with our current implementation.  I’m very interested in the intended way to handle this, as I’ll be updating our implementation with whatever is decided.

Thanks,
David



From: Rick Taylor <rick@tropicalstormsoftware.com>
Date: Friday, August 9, 2019 at 4:53 PM
To: Stan Ratliff <ratliffstan@gmail.com>, "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu>
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: RE: [manet] DLEP redundant Destination Ups

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