Re: [manet] Last call ending

[Stan Ratliff <[e-mail]>]

Sent from my iPhone

> On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL <[e-mail]> wrote:
> 
> I tried to clarify Suppress Forwarding:
> 
>  The Suppress Forwarding Action is used by a router to indicate to its
>  peer that multi-hop forwarding performed by the modem is to be
>  suppressed.  A router may request that multi-hop forwarding may be
>  suppressed on a device wide or destination specific basis.
> 
>  A modem which receives the Suppress Forwarding Data Item in a Session
>  Update Message MUST suppress multi-hop forwarding on a device wide
>  basis.

This concerns me. Should the modem
a) silently drop traffic unless/until the multi-hop destination(s) become single-hop again? (Bad plan, IMO) Or,
b) issue Destination Down for multi-hop destination(s), and re-issue Destination Up If/when the dest is single-hop?

Regards, 
Stan

> For data traffic originating from the modem's peer router, the
>  modem MUST only send such traffic to destinations that are one hop
>  away.  Any data traffic received from the modem MUST NOT be resent to
>  another modem.  Impact to destination hop counts are provided to the
>  router by the modem as described above.
> 
>  A modem which receives the Suppress Forwarding Data Item in a Link
>  Characteristics Request Message MUST suppress multi-hop forwarding for
>  only the destination indicated in the message.  Sending of traffic by
>  the modem is modified as described in the previous paragraph, except
>  that the suppression only applies to the specific destination given in
>  the Link Characteristics Request Message.  Results are provided as
>  described above.
> 
> Does that fit what was meant?
> 
> Thanks,
> David
> 
> 
> 
> On 1/29/18, 1:37 PM, "Lou Berger" <[e-mail]> 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