Re: [manet] Last call ending

On 1/25/2018 1:31 PM, Stan Ratliff wrote:
> Hi!
>
> One question/issue inline:
>
> On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL 
> <David.Wiggins@ll.mit.edu <mailto: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"?
Only to multi hop destinations...

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

The basic use case is to have all forwarding done by the routers. This 
would only be useful in networks where routers are attached to all 
radios.  So this is a user deployment choice...

Lou

>
> 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
>     <mailto:manet-bounces@ietf.org>> on behalf of Justin Dean
>     <bebemaster@gmail.com <mailto:bebemaster@gmail.com>>
>     *Date: *Tuesday, January 23, 2018 at 11:30 AM
>     *To: *MANET IETF <manet@ietf.org <mailto: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-latency-extension/>
>
>     https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-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 <mailto:manet@ietf.org>
>     https://www.ietf.org/mailman/listinfo/manet
>     <https://www.ietf.org/mailman/listinfo/manet>
>
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet