Re: [manet] DLEP redundant Destination Ups

["Wiggins, David - 0665 - MITLL" <[e-mail]>]

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 <[e-mail]>
Date: Friday, August 9, 2019 at 4:53 PM
To: Stan Ratliff <[e-mail]>, "Wiggins, David - 0665 - MITLL" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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:[e-mail]] On Behalf Of Stan Ratliff
Sent: 09 August 2019 20:33
To: Wiggins, David - 0665 - MITLL
Cc: [e-mail]
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 <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/manet