Subject: [manet] DLEP redundant Destination Ups

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 9 Aug 2019 18:43:01 +0000

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

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 9 Aug 2019 15:33:00 -0400

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 <
[email-masked]> 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?
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Fri, 9 Aug 2019 20:49:56 +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:[email-masked]] On Behalf Of Stan Ratliff
Sent: 09 August 2019 20:33
To: Wiggins, David - 0665 - MITLL
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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?

Thanks,
David

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Sat, 10 Aug 2019 15:55:58 +0000

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 <[email-masked]>
Date: Friday, August 9, 2019 at 4:53 PM
To: Stan Ratliff <[email-masked]>, "Wiggins, David - 0665 - MITLL" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [manet] DLEP redundant Destination Ups

David,

Does that help?

Cheers,

Rick

David,

Other opinions?

Regards,

Stan

On Fri, Aug 9, 2019 at 2:43 PM Wiggins, David - 0665 - MITLL <[email-masked]> wrote:

d) something else

Thanks,

David

---

From: Rick Taylor <[email-masked]>
Date: Sat, 10 Aug 2019 16:37:04 +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:[email-masked]]
Sent: 10 August 2019 16:56
To: Rick Taylor; Stan Ratliff
Cc: [email-masked]
Subject: Re: [manet] DLEP redundant Destination Ups

Stan, Rick,

Thanks,
David

David,

Does that help?

Cheers,
Rick

David,

Other opinions?

Regards,
Stan

Thanks,
David

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 10 Aug 2019 21:38:41 -0400

On Sat, Aug 10, 2019 at 12:37 PM Rick Taylor <[email-masked]>
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).

> *From:* Wiggins, David - 0665 - MITLL [mailto:[email-masked]]
> *Sent:* 10 August 2019 16:56
> *To:* Rick Taylor; Stan Ratliff
> *Cc:* [email-masked]
> *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:
>
>
>
> - Modem sends Destination Announce Response for that group, and this
> counts as a Destination Up (by the above assumptions)
>
> - Modem sends a Destination Up for the group to let the router know there
> are other (unidentified) group members out there
>
> 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 <[email-masked]>
> *Date: *Friday, August 9, 2019 at 4:53 PM
> *To: *Stan Ratliff <[email-masked]>, "Wiggins, David - 0665 -
> MITLL" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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:[email-masked]] *On Behalf Of *Stan Ratliff
> *Sent:* 09 August 2019 20:33
> *To:* Wiggins, David - 0665 - MITLL
> *Cc:* [email-masked]
> *Subject:* Re: [manet] DLEP redundant Destination Ups
>
>
>
> David,
>
>
>