Re: [manet] Last call ending

I agree with Vicky and David - Both drafts are in pretty good shape,
bar some typos, and the hop count.

I'm with David on hop count issues. I'm not sure the local link between
router and modem should count as a hop, if it does then the simplest
network starts with 3 hops.  I would only count hops *between* modems,
as DLEP is really only about what happens between modems.  I don't see
benefit in counting the local switches between the router and the
modem.

Rick

On Thu, 2018-01-25 at 15:07 +0000, Wiggins, David - 0665 - MITLL 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?
>  
> 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 <bebema
> ster@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-extens
> ion/
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-exte
> nsion/
>  
> Please get your comments in.
>  
> Justin Dean
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet