Re: [manet] Last call ending

Hi!

One question/issue inline:

On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL <
David.Wiggins@ll.mit.edu> wrote:

> I think the latency extension is in reasonable shape.  I agree with all of
> Vicky’s recent comments.
>
>
>
> Here are some comments on the Multi-Hop extension.
>
>
>
> Section 3.1
>
> “…each hop represents a transmission and the number of hops is
>
> equal to the number of transmissions required to go from a router
>
> connected modem to the destination's connected modem.”
>
>
>
> So hops are counted starting at the modem that is the DLEP peer of the
> router.  But then:
>
>
>
> “The minimum number of hops is 1, which represents the router's locally
> connected modem.”
>
>
>
> If counting starts at that modem, wouldn’t hop count be 0 for the modem?
> If it’s 1, this seems to mean that the (typically) wired link between the
> router and the modem is being counted.  I think the two quotes above are
> inconsistent about whether this first link counts as a hop.  If the hop
> count was meant to convey over-the-air hops, then the router’s locally
> connected modem should have a hop count of 0.
>
>
>
> “A value of zero (0) is used to indicated that processing of a Hop
>
> Control action, see Section 3.2, has resulted in a destination no
>
> longer being reachable.”
>
>
>
> I would rather not have this special case.  Just leave it to Destination
> Down to convey loss of reachability.  I’ve worked on systems that had
> multiple different ways of indicating a node was down, and it leads to
> bugs, especially when the down indications are not closely synchronized.
> Part of the system thinks a node is up, part thinks it’s down, and chaos
> ensues.
>
>
>
> Section 3.2 paragraph 4
>
> “Once the change is made, or fails or is rejected, the modem
>
> MUST respond with a Link Characteristics Request Message…”
>
>
>
> Should this have said Response Message?
>
>
>
> Section 3.2 paragraph 5
>
> I think a Session Update message should be replied to with a Session
> Update Response, and a Link Characteristics Request message with a Link
> Characteristics Response.  The text has both of these being replied to with
> a Link Characteristics Request message.
>
>
>
> Sections 3.2.2 Terminate and 3.2.3 Direct Connection
>
> These seem to be a way for the router to tell the modem how important it
> is to be able to communicate with specific destinations.  If that was the
> motivation, perhaps a more direct expression of that information would be
> better.  For example, the router could provide a list of destinations,
> ordered by importance.  I worry that the router giving low-level directions
> to the modem about which links to maintain might be difficult or suboptimal
> for some radios.
>
>
>
> Section 3.2.4 Suppress Forwarding
>
> What exactly is meant by suppressing multi-hop forwarding here?  Is it:
>
> a) If the router sends data (over the data plane) to a destination, and
> that destination has a hop count > 1, the directly connected modem should
> drop the data.
>
> b) The modem should discontinue forwarding of all data whose destination
> is more than one hop away, regardless of where the data came from.  E.g.,
> the modem might be running a manet protocol, and the data could come
> over-the-air from another modem.
>
> c) something else?
>

If the answer is "a", then isn't that really "Destination Down"? What is
the use case for suppressing multi-hop forwarding in the first place? It
almost seems counter to the basic appeal of mesh radios.

Regards,
Stan

>
>
> I think it’s probably a), but if so, couldn’t the router arrange its
> forwarding tables to drop such packets itself instead of asking the modem
> to do it?
>
>
>
> Thanks,
>
> David
>
>
>
>
>
> *From: *manet <manet-bounces@ietf.org> on behalf of Justin Dean <
> bebemaster@gmail.com>
> *Date: *Tuesday, January 23, 2018 at 11:30 AM
> *To: *MANET IETF <manet@ietf.org>
> *Subject: *[manet] Last call ending
>
>
>
> Working group last call is ending on both
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/
>
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-
> multi-hop-extension/
>
>
>
> Please get your comments in.
>
>
>
> Justin Dean
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>