Re: [manet] Last call ending

[Lou Berger <[e-mail]>]

Hi Stan,


On 1/29/2018 5:39 PM, Stan Ratliff wrote:
>
> 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?

Stand note that the reference paragraph concludes:
   Impact to destination hop counts are provided to the
   router by the modem as described above.

and above it says:
  ...
  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
  changes in Hop Counts via Destination Update Messages.

Is this sufficient?
Thanks,
Lou
> 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