Re: [manet] Last call ending

[Lou Berger <[e-mail]>]

On 1/25/2018 10:53 AM, Rick Taylor wrote:
> 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 agree it should not and this was not the intent.

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

100% agree.  any suggestions on wording changes to improve clarity would 
be most appreciated!

PS latest text can be found at:
https://github.com/louberger/dlep-extensions

Thanks,
Lou
>
> 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 <[e-mail]> on behalf of Justin Dean <bebema
>> [e-mail]>
>> Date: Tuesday, January 23, 2018 at 11:30 AM
>> To: MANET IETF <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet