Re: [manet] Last call ending

[Lou Berger <[e-mail]>]

FYI - I just pushed an updated - David noticed some vestigial (and now
illegal) case being described - I removed the paragraph and pushed the
change...

Lou

On 01/29/2018 01:36 PM, Lou Berger wrote:
> ...
> David, (all)
> I think I've addressed all comments in the latest push to the repo.  I'm
> enclosing below a specific diff of the commit that addresses your
> comments, please take a look and let me know if you see any issues
> remaining.
> 
> Note I have clarified processing when hop control is in a
> characteristics change message and changed/simplified in the Session
> request massage case - to improve processing consistency as you
> requested.  Please see the specific changes below and let me know what
> you think.
> 
> I also have one comment in response to your comment below.
> 
> On 01/29/2018 09:36 AM, Wiggins, David - 0665 - MITLL wrote:
>>     > That’s why I was suggesting a radically different mechanism for
>> the router     > to express its wishes, e.g., by ordering the
>> destinations in terms of     > importance, and letting the modem work
>> that information into its topology     > control scheme however it
>> can.  The router’s most important destination may     > be best
>> reached over a 3-hop link.
>>     >
>>         To me this is a different extension with different objectives.
>> I certainly     would be interested in reading that extension.
>>
>> It has very similar objectives to the Direct Connection/Terminate part
>> of this extension, but I agree that it doesn’t fit well in this
>> extension.
> 
> I think an extension that does this as well as let's a router understand
> some of the resource impacts of a manet topology (with out exposing the
> full topology ala ospf/isis-te) would be very interesting.  I actually
> had some related discussion on this in singapore.  If you have a
> proposal on this or are interested in collaborating on such, I'm very
> interested in this!
> 
> Thanks,
> 
> Lou
> 
> Changes from:
> https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f
> 
> commit 100217f5a8a3e35c6608b4a88428b20b14854f8f
> Author: Lou Berger <[e-mail]>
> Date:   Mon Jan 29 13:20:09 2018 -0500
> 
>     Multi-hop: Address remainder of Dave W. comments
>         - Clean up Hop Behavior processing.
>           Send only one message when link characteristic change results in
>                a change/unreachable requested destination
>           Destination impact due to Hop Control Data Item in a Session
>                Update Message always provided via a Destination Down or
>                Destination Update Message.
> 
> diff --git a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
> b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
> index 5fc2845..f81e3be 100644
> --- a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
> +++ b/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
> @@ -110,7 +110,8 @@
>    words, 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.  The minimum
> -  number of hops is 1, which represents the transmission by the router's
> +  number of hops is 1, which represents transmission to destinations
> +  that are directly reachable via the router's
>    locally connected
>    modem.
>  </t>
> @@ -176,7 +177,7 @@
>        A value of zero (0) is used to indicated that processing of a Hop
>        Control action, see <xref target="sec-di-hcontrol"/>, has resulted
>        in a destination no longer being reachable.  A zero value MUST NOT
> -      be used in any message other then a Destination Announce Response
> +      be used in any message other then a Link Characteristics Response
>        Message.
>      </t>
>    </list>
> @@ -189,7 +190,8 @@
>    connectivity to a particular destination, or in multi-hop processing
>    on a device wide basis. A router can request multi-hop reachable
>    destination be changed to a single hop.  A router can also indicate
> -  that the modem terminate connectivity to a particular destination.
> +  that the modem terminates a previous direct connectivity request to a
> +  particular destination.
>  </t>
>  <t>
>    The Hop Control Data Item MAY be carried in a Session Update Message
> @@ -218,20 +220,19 @@
>    notify the router of each destination that is no longer reachable via
>    a Destination Down Message. The modem MUST notify the router of any
>    changes in Hop Counts via Destination Update Messages.  Note that
> -  normal DLEP processing is not otherwise modified by this document, this
> -  includes the generation of Destination Down messages.
> +  neither Destination Down or Update Message SHOULD NOT be sent for the
> +  destination MAC address contained in the Link Characteristics
> +  Response Message.
>  </t>
>  <t>
>    A modem that receives the Hop Control Data Item in
>    a Session Update Message
>    SHOULD attempt to make the change indicated by the data item
> -  for the associated destination MAC address, when carried in a Link
> -  Characteristics Request Message, or all destinations, when carried in
> -  a Session Update Message. Once the change is made,
> -  or fails or is rejected, the modem MUST respond with a Link
> Characteristics
> -  Request Message containing an updated Hop Count Data Item.  Note that
> -  other destinations can be impacted as a result of the change and such
> -  changes are reported in
> +  for all known destinations.  Once the change is made, or fails or is
> +  rejected, the modem MUST respond with a Session Update Response
> +  Message with an appropriate Status Code.  Destination specific
> +  impact resulting from the processing of a Hop Control Data Item in a
> +  Session Update Message is provided via
>    Destination Down and Destination Update Messages.  The modem MUST
>    notify the router of each destination that is no longer reachable via
>    a Destination Down Message. The modem MUST notify the router of any
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet