Subject: Re: [manet] Last call ending

From: Lou Berger <[email-masked]>
Date: Wed, 14 Feb 2018 18:06:09 -0500

Sorry for the delayed response.

see bewlo

On 1/29/2018 5:26 PM, Wiggins, David - 0665 - MITLL 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.
yes.
>    A modem which receives the Suppress Forwarding Data Item in a Session
>    Update Message MUST suppress multi-hop forwarding on a device wide
>    basis. 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.
How about, slightly rephrased:

   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 means that data traffic originating from the modem's peer
   router SHALL only be sent by the modem to destinations that are one
   modem hop away, and that any data traffic received by the modem from
   another modem that is not destined to the peer router SHALL be
   dropped. 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.
Actually there's a substantive difference in the following, i.e., 
transit traffic is *not* impacted:

   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.  This means that data
   traffic originating from the modem's peer router SHALL be sent by the
   modem to the destination indicated in the Link Characteristics Request
   Message only when it is one modem hop away.  Notably, data traffic
   received by the modem from another modem MAY be forwarded by the modem
   per its normal processing.  Results are provided as described above.

Does this work for you/all?
Lou
> Does that fit what was meant?
>
> Thanks,
> David
>
>
>
> On 1/29/18, 1:37 PM, "Lou Berger" <[email-masked]> 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 <[email-masked]>
>      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
>      
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 14 Feb 2018 18:10:32 -0500

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 <[email-masked]> wrote:
>>
>>   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
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Feb 2018 11:40:17 -0500

Lou,

On Wed, Feb 14, 2018 at 6:10 PM, Lou Berger <[email-masked]> wrote:

>> b) issue Destination Down for multi-hop destination(s), and re-issue
>> Destination Up If/when the dest is single-hop?
>>
>

Yes, I'm good to go with that text. Apologies for any noise.

Regards,
Stan

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Feb 2018 16:38:19 -0500

Thanks Stan.

On 2/19/2018 11:40 AM, Stan Ratliff wrote:
> Lou,
>
> On Wed, Feb 14, 2018 at 6:10 PM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Stan,
>
>
>             On Jan 29, 2018, at 5:26 PM, Wiggins, David - 0665 - MITLL
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>         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?
>
>
>             On 1/29/18, 1:37 PM, "Lou Berger" <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 ...
>                 David, (all)
>                 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.
>
>             <https://github.com/louberger/dlep-extensions/commit/100217f5a8a3e35c6608b4a88428b20b14854f8f>
>                 Author: Lou Berger <[email-masked]
>             <mailto:[email-masked]>>
>                 diff --git
>             a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
>                 ---
>             a/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
>                 +++
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/manet>
>
>
>