Subject: [manet] Last call ending

From: Justin Dean <[email-masked]>
Date: Tue, 23 Jan 2018 11:29:48 -0500

Working group last call is ending on both

https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/

Please get your comments in.

Justin Dean

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Thu, 25 Jan 2018 15:07:10 +0000

I think the latency extension is in reasonable shape.  I agree with all of Vicky’s recent comments.

Here are some comments on the Multi-Hop extension.

Section 3.1

“…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.”

So hops are counted starting at the modem that is the DLEP peer of the router.  But then:

“The minimum number of hops is 1, which represents the router's locally connected modem.”

If counting starts at that modem, wouldn’t hop count be 0 for the modem?  If it’s 1, this seems to mean that the (typically) wired link between the router and the modem is being counted.  I think the two quotes above are inconsistent about whether this first link counts as a hop.  If the hop count was meant to convey over-the-air hops, then the router’s locally connected modem should have a hop count of 0.

“A value of zero (0) is used to indicated that processing of a Hop

Control action, see Section 3.2, has resulted in a destination no

longer being reachable.”

I would rather not have this special case.  Just leave it to Destination Down to convey loss of reachability.  I’ve worked on systems that had multiple different ways of indicating a node was down, and it leads to bugs, especially when the down indications are not closely synchronized.  Part of the system thinks a node is up, part thinks it’s down, and chaos ensues.

Section 3.2 paragraph 4

“Once the change is made, or fails or is rejected, the modem

MUST respond with a Link Characteristics Request Message…”

Should this have said Response Message?

Section 3.2 paragraph 5

I think a Session Update message should be replied to with a Session Update Response, and a Link Characteristics Request message with a Link Characteristics Response.  The text has both of these being replied to with a Link Characteristics Request message.

Sections 3.2.2 Terminate and 3.2.3 Direct Connection

These seem to be a way for the router to tell the modem how important it is to be able to communicate with specific destinations.  If that was the motivation, perhaps a more direct expression of that information would be better.  For example, the router could provide a list of destinations, ordered by importance.  I worry that the router giving low-level directions to the modem about which links to maintain might be difficult or suboptimal for some radios.

Section 3.2.4 Suppress Forwarding

What exactly is meant by suppressing multi-hop forwarding here?  Is it:

a) If the router sends data (over the data plane) to a destination, and that destination has a hop count > 1, the directly connected modem should drop the data.

b) The modem should discontinue forwarding of all data whose destination is more than one hop away, regardless of where the data came from.  E.g., the modem might be running a manet protocol, and the data could come over-the-air from another modem.

c) something else?

I think it’s probably a), but if so, couldn’t the router arrange its forwarding tables to drop such packets itself instead of asking the modem to do it?

Thanks,

David

From: manet <[email-masked]> on behalf of Justin Dean <[email-masked]>
Date: Tuesday, January 23, 2018 at 11:30 AM
To: MANET IETF <[email-masked]>
Subject: [manet] Last call ending

Justin Dean

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jan 2018 15:53:44 +0000

I agree with Vicky and David - Both drafts are in pretty good shape,
bar some typos, and the hop count.

I'm with David on hop count issues. I'm not sure the local link between
router and modem should count as a hop, if it does then the simplest
network starts with 3 hops.  I would only count hops *between* modems,
as DLEP is really only about what happens between modems.  I don't see
benefit in counting the local switches between the router and the
modem.

Rick

On Thu, 2018-01-25 at 15:07 +0000, Wiggins, David - 0665 - MITLL wrote:
> If counting starts at that modem, wouldn’t hop count be 0 for the
> modem?  If it’s 1, this seems to mean that the (typically) wired link
> between the router and the modem is being counted.  I think the two
> quotes above are inconsistent about whether this first link counts as
> a hop.  If the hop count was meant to convey over-the-air hops, then
> the router’s locally connected modem should have a hop count of 0.
>  
> I would rather not have this special case.  Just leave it to
> Destination Down to convey loss of reachability.  I’ve worked on
> systems that had multiple different ways of indicating a node was
> down, and it leads to bugs, especially when the down indications are
> not closely synchronized.  Part of the system thinks a node is up,
> part thinks it’s down, and chaos ensues.
>  
> Section 3.2 paragraph 4
> I think a Session Update message should be replied to with a Session
> Update Response, and a Link Characteristics Request message with a
> Link Characteristics Response.  The text has both of these being
> replied to with a Link Characteristics Request message.
>  
> These seem to be a way for the router to tell the modem how important
> it is to be able to communicate with specific destinations.  If that
> was the motivation, perhaps a more direct expression of that
> information would be better.  For example, the router could provide a
> list of destinations, ordered by importance.  I worry that the router
> giving low-level directions to the modem about which links to
> maintain might be difficult or suboptimal for some radios.
>  
> a) If the router sends data (over the data plane) to a destination,
> and that destination has a hop count > 1, the directly connected
> modem should drop the data.
> b) The modem should discontinue forwarding of all data whose
> destination is more than one hop away, regardless of where the data
> came from.  E.g., the modem might be running a manet protocol, and
> the data could come over-the-air from another modem.
> c) something else?
>  
> I think it’s probably a), but if so, couldn’t the router arrange its
> forwarding tables to drop such packets itself instead of asking the
> modem to do it?
>  
> Thanks,
> David
>  
>  
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "MATTY, Steven [UK]" <[email-masked]>
Date: Thu, 25 Jan 2018 16:11:46 +0000

>benefit in counting the local switches between the router and the

There is the possibility that a DLEP router & modem could exist in the
same platform with no wires between them at all (but merely different logical interfaces, if that)
which could only add to the confusion...

Steve

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 25 Jan 2018 13:31:58 -0500

Hi!

One question/issue inline:

On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL <
[email-masked]> wrote:

> If counting starts at that modem, wouldn’t hop count be 0 for the modem?
> If it’s 1, this seems to mean that the (typically) wired link between the
> router and the modem is being counted.  I think the two quotes above are
> inconsistent about whether this first link counts as a hop.  If the hop
> count was meant to convey over-the-air hops, then the router’s locally
> connected modem should have a hop count of 0.
>
>
>
> I would rather not have this special case.  Just leave it to Destination
> Down to convey loss of reachability.  I’ve worked on systems that had
> multiple different ways of indicating a node was down, and it leads to
> bugs, especially when the down indications are not closely synchronized.
> Part of the system thinks a node is up, part thinks it’s down, and chaos
> ensues.
>
>
>
> Section 3.2 paragraph 4
>
> Update Response, and a Link Characteristics Request message with a Link
> Characteristics Response.  The text has both of these being replied to with
> a Link Characteristics Request message.
>
>
>
> These seem to be a way for the router to tell the modem how important it
> is to be able to communicate with specific destinations.  If that was the
> motivation, perhaps a more direct expression of that information would be
> better.  For example, the router could provide a list of destinations,
> ordered by importance.  I worry that the router giving low-level directions
> to the modem about which links to maintain might be difficult or suboptimal
> for some radios.
>
>
>
> a) If the router sends data (over the data plane) to a destination, and
> that destination has a hop count > 1, the directly connected modem should
> drop the data.
>
> b) The modem should discontinue forwarding of all data whose destination
> is more than one hop away, regardless of where the data came from.  E.g.,
> the modem might be running a manet protocol, and the data could come
> over-the-air from another modem.
>
> c) something else?
>

If the answer is "a", then isn't that really "Destination Down"? What is
the use case for suppressing multi-hop forwarding in the first place? It
almost seems counter to the basic appeal of mesh radios.

Regards,
Stan

> forwarding tables to drop such packets itself instead of asking the modem
> to do it?
>
>
>
> Thanks,
>
> David
>
>
>
>
>
> *From: *manet <[email-masked]> on behalf of Justin Dean <
> [email-masked]>
> *Date: *Tuesday, January 23, 2018 at 11:30 AM
> *To: *MANET IETF <[email-masked]>
> *Subject: *[manet] Last call ending
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jan 2018 19:32:55 -0500

On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote:
> So hops are counted starting at the modem that is the DLEP peer of the 
> router.
>
yes, that's the intent.

> But then:
how about "which represents the *transmission* by the router's locally 
connected modem."?

> If counting starts at that modem, wouldn’t hop count be 0 for the modem?
I don't understand this.  Perhaps you mean for the hop between the 
router and the modem?  This extensions isn't intended to count router to 
modem hops.

>   If it’s 1, this seems to mean that the (typically) wired link 
> between the router and the modem is being counted.
>
How so?  1 means a single transmission over the modem attached media 
(RF) channel .

> I think the two quotes above are inconsistent about whether this first 
> link counts as a hop. If the hop count was meant to convey 
> over-the-air hops, then the router’s locally connected modem should 
> have a hop count of 0.
>
There is no destination for the locally connected modem, so zero would 
never be reported.  In what case do you see zero being reported?

> part thinks it’s down, and chaos ensues.
I'd actually expect both a Destination Down, per normal processing which 
is not modified by this document, and a  Link Characteristics Request 
Message.  This is so there is consistent processing of  the Hop Control 
Data Item on both router and modem.  Otherwise there how will a router 
know that a particular Hop Control request has completed.  Having just a 
Destination Down would mean that the router would have to infer that 
this was due to the hop control when in fact it may be due to just some 
transitory affect.  In my experience leaving things to inference is a 
bad transaction model and leads to race condition bugs. So I'd prefer to 
leave as is. I've added a note to make it clear that the Destination 
Down is still sent. specifically:
   Note that
   normal DLEP processing is not otherwise modified by this document, this
   includes the generation of Destination Down messages.

> Should this have said Response Message?
yes

> replied to with a Link Characteristics Request message.
What information would you like carried in the Session Update Response 
message?  Note that a reset may result in a destination specific change.

> it is to be able to communicate with specific destinations.
>
I see this as the way to reverse/undo a 'Direct Connection'.
>
> If that was the motivation, perhaps a more direct expression of that 
> giving low-level directions to the modem about which links to maintain 
> might be difficult or suboptimal for some radios.
>
How about:
OLD
    It indicates
     that the modem SHOULD attempt to terminate communication
     with the destination identified in the message.
NEW
    It indicates that a direct connection is no longer needed with the
    the destination identified in the message.
> and that destination has a hop count > 1, the directly connected modem 
> should drop the data.
>
> came from.  E.g., the modem might be running a manet protocol, and the 
> data could come over-the-air from another modem.
>
> c) something else?
>
> I think it’s probably a),
>
I read it as (a) and (b).  This does imply that the modem in a manet may 
need to alter it's route advertisement in that manet.

> but if so, couldn’t the router arrange its forwarding tables to drop 
> such packets itself instead of asking the modem to do it?
>
That doesn't cover race conditions in case (a) or case (b) at all.

Thank you for the comments!
Lou
>
> Thanks,
>
> David
>
> *From: *manet <[email-masked]> on behalf of Justin Dean 
> <[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jan 2018 19:36:26 -0500

On 1/25/2018 10:53 AM, Rick Taylor wrote:
> network starts with 3 hops.
I agree it should not and this was not the intent.

>   I would only count hops *between* modems,

100% agree.  any suggestions on wording changes to improve clarity would 
be most appreciated!

PS latest text can be found at:
https://github.com/louberger/dlep-extensions

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jan 2018 19:39:19 -0500

On 1/25/2018 1:31 PM, Stan Ratliff wrote:
> On Thu, Jan 25, 2018 at 10:07 AM, Wiggins, David - 0665 - MITLL 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     modem?  If it’s 1, this seems to mean that the (typically) wired
>     link between the router and the modem is being counted. I think
>     the two quotes above are inconsistent about whether this first
>     over-the-air hops, then the router’s locally connected modem
>     should have a hop count of 0.
>
>     down, and it leads to bugs, especially when the down indications
>     are not closely synchronized. Part of the system thinks a node is
>     up, part thinks it’s down, and chaos ensues.
>
>     Section 3.2 paragraph 4
>
>     I think a Session Update message should be replied to with a
>     Session Update Response, and a Link Characteristics Request
>     message with a Link Characteristics Response.  The text has both
>     of these being replied to with a Link Characteristics Request message.
>
>     These seem to be a way for the router to tell the modem how
>     important it is to be able to communicate with specific
>     destinations.  If that was the motivation, perhaps a more direct
>     expression of that information would be better.  For example, the
>     router could provide a list of destinations, ordered by
>     importance.  I worry that the router giving low-level directions
>     to the modem about which links to maintain might be difficult or
>     suboptimal for some radios.
>
>     a) If the router sends data (over the data plane) to a
>     destination, and that destination has a hop count > 1, the
>     directly connected modem should drop the data.
>
>     destination is more than one hop away, regardless of where the
>     data came from.  E.g., the modem might be running a manet
>     protocol, and the data could come over-the-air from another modem.
>
>     c) something else?
>
>
> If the answer is "a", then isn't that really "Destination Down"?
Only to multi hop destinations...

> What is the use case for suppressing multi-hop forwarding in the first 
> place? It almost seems counter to the basic appeal of mesh radios.

The basic use case is to have all forwarding done by the routers. This 
would only be useful in networks where routers are attached to all 
radios.  So this is a user deployment choice...

Lou

>
> Regards,
> Stan
>
>     I think it’s probably a), but if so, couldn’t the router arrange
>     its forwarding tables to drop such packets itself instead of
>     asking the modem to do it?
>
>     Thanks,
>
>     David
>
>     *From: *manet <[email-masked]
>     <mailto:[email-masked]>> on behalf of Justin Dean
>     <[email-masked] <mailto:[email-masked]>>
>     *To: *MANET IETF <[email-masked] <mailto:[email-masked]>>
>     <https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/>
>
>     <https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/manet>
>
>
>
>

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 26 Jan 2018 20:41:00 +0000

Comments inline… sorry if outlook mangles stuff

On 1/25/18, 7:33 PM, "Lou Berger" <[email-masked]> wrote:
    yes, that's the intent.

I like this better: “which represents transmission to destinations that are directly reachable from the router’s locally connected modem.”

No, I mean the modem.  If the hop count from the modem to one of its directly reachable destinations is 1, and assuming each hop increments the count by 1, then the modem’s hop count has to be zero for that math to work (  Now, we may expect a hop count of zero to never be reported, but that is a separate issue; more below.

It doesn’t matter now… I was just trying to reason through what it would mean if the modem’s hop count was 1, because it was ambiguous before.  Now it’s not.

I’ve been assuming that the locally connected modem could indeed announce a destination for itself, though admittedly this seems unusual.  However, I’m probably wrong; in 8175 section 2.1:

“Destinations can be identified by either the router or the modem and represent a specific, addressable location that can be reached via the link(s) managed by the modem.”

Unless we imagine an implied link from the modem to itself, which seems like a stretch, this means that the destinations are on the other end of a link from the modem.  So I accept that the modem itself won’t be a destination, and thus there won’t ever be a zero hop count.

The router would know that the Hop Control request has completed when it receives a Link Characteristics Response.  The status code would be used to indicate whether it succeeded or not.  If it did succeed, a Destination Down would come along soon after (if the action was Terminate).  This is almost what you have now, except I’m suggesting to use the status code data item rather than the hop count data item to indicate success.

A Hop Control Reset sent in a Session Update would be answered with a Session Update Response with an appropriate status code, followed by Destination Updates with appropriate Hop Count data items for any that changed.

Please, please don’t make a Session Update message be replied to with a Link Characteristics Request message.  That contorts my implementation in unnatural ways.

I’m talking about both Terminate and Direct Connection.

    How about:
    OLD
        It indicates

My concern is deeper than this.  The modem may be running a sophisticated topology control algorithm to decide which neighbors to maintain links to.  It may be juggling multiple beams, multiple frequencies, considering the local network density and traffic load, factoring in connectivity goals (e.g., biconnectedness), etc.  Having an external party (router) insert its own wishes for links into the mix could be untenable.  The probability is good that the router’s wishes will contradict the modem’s topology choices.

Also, there seems to be an unstated assumption that a direct connection (1 hop) to a destination is better in some sense that a non-direct connection.  Why else would the router ask for a direct connection?  Two short hops are often more reliable than one long hop, though.  Forcing a single hop could make communication worse.  Giving the router this control is too low-level; it doesn’t have enough information to do it right.

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.

    > What exactly is meant by suppressing multi-hop forwarding here?  Is it:

Borrowing text from a different message in this thread, Lou said:

Ah, I see.  This clarifies the intent significantly.  This motivation should be stated in the draft.  I’ve definitely heard the desire to turn off all of the radio’s routing and use it as a single-hop device.

Thanks,
David

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 Jan 2018 17:43:07 -0500

On January 26, 2018 3:41:30 PM "Wiggins, David - 0665 - MITLL" 
<[email-masked]> wrote:

> I like this better: “which represents transmission to destinations that are 
> directly reachable from the router’s locally connected modem.”
>

How about s/from/via ?

> No, I mean the modem.  If the hop count from the modem to one of its 
> directly reachable destinations is 1, and assuming each hop increments the 
> count by 1, then the modem’s hop count has to be zero for that math to work 
> (  Now, we may expect a hop count of zero to never be reported, but that is 
> a separate issue; more below.
>

Right- I think we agree that this is a non issue/case.

> It doesn’t matter now… I was just trying to reason through what it would 
> mean if the modem’s hop count was 1, because it was ambiguous before.  Now 
> it’s not.
>

Okay.

> I’ve been assuming that the locally connected modem could indeed announce a 
> destination for itself, though admittedly this seems unusual.  However, I’m 
> probably wrong; in 8175 section 2.1:
>
> “Destinations can be identified by either the router or the modem and 
> represent a specific, addressable location that can be reached via the 
> link(s) managed by the modem.”
>
> Unless we imagine an implied link from the modem to itself, which seems 
> like a stretch, this means that the destinations are on the other end of a 
> link from the modem.  So I accept that the modem itself won’t be a 
> destination, and thus there won’t ever be a zero hop count.
>

Great.

> The router would know that the Hop Control request has completed when it 
> receives a Link Characteristics Response.  The status code would be used to 
> indicate whether it succeeded or not.  If it did succeed, a Destination 
> Down would come along soon after (if the action was Terminate).  This is 
> almost what you have now, except I’m suggesting to use the status code data 
> item rather than the hop count data item to indicate success.
>

Hmm. A successful transaction does not necessarily Translate to a loss of 
connection, so I think being explicit here makes the most sense. We should 
certainly ensure that the text is clear either way.

> A Hop Control Reset sent in a Session Update would be answered with a 
> Session Update Response with an appropriate status code, followed by 
> Destination Updates with appropriate Hop Count data items for any that changed.
>
This works for me and seems sensible. I thought you were suggesting 
something different. I'll propose some text to this effect.

> Please, please don’t make a Session Update message be replied to with a 
> Link Characteristics Request message.  That contorts my implementation in 
> unnatural ways.
>

Understood.

> My concern is deeper than this.  The modem may be running a sophisticated 
> topology control algorithm to decide which neighbors to maintain links to.  
> It may be juggling multiple beams, multiple frequencies, considering the 
> local network density and traffic load, factoring in connectivity goals 
> (e.g., biconnectedness), etc.  Having an external party (router) insert its 
> own wishes for links into the mix could be untenable.  The probability is 
> good that the router’s wishes will contradict the modem’s topology choices.
>
Well certainly this extension is about a router in forming a modem about 
its wishes/preferenes.

> Also, there seems to be an unstated assumption that a direct connection (1 
> hop) to a destination is better in some sense that a non-direct connection. 
>  Why else would the router ask for a direct connection?  Two short hops are 
> often more reliable than one long hop, though.  Forcing a single hop could 
> make communication worse.  Giving the router this control is too low-level; 
> it doesn’t have enough information to do it right.
>

I think the router has access to sufficient information through other 
metrics. Certainly A system that doesn't care to provide this capability to 
a router doesn't have to implement it.

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

> Ah, I see.  This clarifies the intent significantly.  This motivation 
> should be stated in the draft.  I’ve definitely heard the desire to turn 
> off all of the radio’s routing and use it as a single-hop device.
>

I'll look at providing some text on this in the intro.

Thanks,

Lou

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 29 Jan 2018 14:36:37 +0000

On 1/26/18, 5:43 PM, "Lou Berger" <[email-masked]> wrote:
    On January 26, 2018 3:41:30 PM "Wiggins, David - 0665 - MITLL" 

    How about s/from/via ?

That’s fine.

OK.  Mainly what I hope to avoid is having Destination Down be expressed in two different ways by different messages that come at different times.

    

I think whether the router has enough knowledge to make good decisions is very system dependent.  Point taken though, if the modem knows that allowing the router to choose links is going to be bad news, the modem can simply not offer this 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.

    Thanks,
    
    Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 29 Jan 2018 13:36:40 -0500

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

> 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: Mon, 29 Jan 2018 16:39:22 -0500

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

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 29 Jan 2018 22:26:01 +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" <[email-masked]> wrote:

    ...
    David, (all)

    

    Thanks,
    
    Lou
    
    Changes from:

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 29 Jan 2018 17:39:18 -0500

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?

Regards, 
Stan

> For data traffic originating from the modem's peer router, the