Re: [manet] Last call ending

"Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu> Mon, 29 January 2018 22:26 UTC

Return-Path: <prvs=55678ac255=david.wiggins@ll.mit.edu>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBF1201F8 for <manet@ietfa.amsl.com>; Mon, 29 Jan 2018 14:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htJzsdx7o4CK for <manet@ietfa.amsl.com>; Mon, 29 Jan 2018 14:26:05 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8B126E3A for <manet@ietf.org>; Mon, 29 Jan 2018 14:26:04 -0800 (PST)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w0TMQ3Ne028550; Mon, 29 Jan 2018 17:26:03 -0500
From: "Wiggins, David - 0665 - MITLL" <David.Wiggins@ll.mit.edu>
To: Lou Berger <lberger@labn.net>, Justin Dean <bebemaster@gmail.com>, MANET IETF <manet@ietf.org>
Thread-Topic: [manet] Last call ending
Thread-Index: AQHTlGeADtKGAZJJIEOy3Mnj+9lmU6OEs44AgADx3oCAAP27gIAAdeyAgAPbQICAAJbjAP//7EOA
Date: Mon, 29 Jan 2018 22:26:01 +0000
Message-ID: <B9FA19D1-F931-474E-86C4-2C3DFF050B1A@ll.mit.edu>
References: <CA+-pDCeA5z0+YE4yXYymkWo8vNthp2k6Pt9nHr32z+ApCLum_A@mail.gmail.com> <020E5EA0-7A6B-46D1-9363-640E3FBBA0ED@ll.mit.edu> <b4faeff9-6fce-cf6c-83a5-ed1db17430e3@labn.net> <B4268EF6-B15D-4C56-A5A1-9B3522ED7F79@ll.mit.edu> <16134a38478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <AA080710-A519-442C-89D7-BADE0EBF030F@ll.mit.edu> <c49477df-40b0-6ccc-3c5b-2df92cec177e@labn.net>
In-Reply-To: <c49477df-40b0-6ccc-3c5b-2df92cec177e@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.25.59.118]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3600091561_1507085430"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-29_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290286
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/ZYgsxtM-xA5s_j3G9ew8g5RtSwc>
Subject: Re: [manet] Last call ending
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 22:26:08 -0000

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. 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" <lberger@labn.net> 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 <lberger@labn.net>
    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