Re: [manet] DLEP redundant Destination Ups

On Sat, Aug 10, 2019 at 12:37 PM Rick Taylor <rick@tropicalstormsoftware.com>
wrote:

> 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.
>

In the use case shown below, I believe Rick is correct - the second
Destination Up should be a Destination Update. This is just a change to the
logical destination represented by the MCAST group.

Now, as to how the protocol should handle the presentation of a Destination
Up on a MAC address that is already been the subject of an Up - I think the
second Destination Up should be responded to with an error, and the
Destination should be removed from the information base, for reasons I've
already stated. For example, let's say the first Destination Up specifies
an IPv4 Address Data Item Add of 1.2.3.4. The second Destination Up comes
with an IPv4 Address Data Item add of 5.6.7.8.

Is 1.2.3.4 supposed to be dropped? Or is 5.6.7.8 just supposed to be added
to the first address? The same issue exists with attached subnets.

Regards,
Stan

PS - I'm almost done with the initial draft on MCAST talked about at IETF
105. Will post ASAP (Provided next week's jury duty doesn't get in the way).

>
>
> 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> 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
> https://www.ietf.org/mailman/listinfo/manet
>
>