Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

From: Teco Boot <[email-masked]>
Date: Thu, 7 Nov 2013 18:56:17 -0800

@Ronald: thanks.
@Ulrich: let’s keep the design team the design team.
@John: can you take the reporting_back task?

Teco

Op 7 nov. 2013, om 17:57 heeft Velt, R. (Ronald) in 't <[email-masked]> het volgende geschreven:

> I leave that up to the DLEP veterans to decide. They may want to "redact" these notes a bit ;-)
> 
> Ronald
> 
>> -----Original Message-----
>> From: Ulrich Herberg [mailto:[email-masked]]
>> Sent: vrijdag 8 november 2013 2:44
>> To: Velt, R. (Ronald) in 't
>> Cc: [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; Teco Boot (teco@inf-
>> net.nl); [email-masked]; Henning Rogge ([email-masked]);
>> [email-masked]; [email-masked]
>> Subject: Re: notes DLEP meeting @ IETF88
>> 
>> Thanks. Do you want to send them out to the MANET mailing list?
>> 
>> On Thu, Nov 7, 2013 at 5:40 PM, Velt, R. (Ronald) in 't <[email-masked]>
>> wrote:
>>> Hi,
>>> 
>>> Please find attached my *raw* notes of our meeting on Tuesday.
>> Disclaimer: Neither completeness nor correctness are guaranteed.
>>> 
>>> Best regards,
>>> Ronald in 't Velt
>>> 
>>> ----
>>> TNO Technical Sciences
>>> 
>>> Network Technology dept.
>>> ----
>>> 
>>> 
>>> 
>>> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet
>> de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt
>> u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO
>> aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze
>> waarop u deze gebruikt en voor schade, van welke aard ook, die verband
>> houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>>> 
>>> 
>>> 
>>> This message may contain information that is not intended for you. If you
>> are not the addressee or if this message was sent to you by mistake, you are
>> requested to inform the sender and delete the message. TNO accepts no
>> liability for the content of this e-mail, for the manner in which you use it and
>> for damage of any kind resulting from the risks inherent to the electronic
>> transmission of messages.
> 
> 
> 
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
> 
> 
> 
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>

---

From: Teco Boot <[email-masked]>
Date: Sat, 9 Nov 2013 07:58:56 +0100

Good summary, thanks. Let’s only post the summary to the MANET ML.
Having minutes archived on DLEP-RG ML would be fine, I think.

On 7: It was not discussed during our meeting, at least not were I was present. And I don’t think this is a good idea. It is not needed and blocks more advanced usage of DLEP. Let’s not have a restriction in that a router or modem has only a single DLEP peer.

Teco

Op 8 nov. 2013, om 21:40 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> Thanks Ron. That matches the notes I have. I might also add this summary of what I think we agreed on in terms of changing/clarifying the spec, which perhaps is more interesting than the play-by-play:
> 
> 1. There are no metric TLVs it is MANDATORY for the Router to process.
> 2. The modem MUST report MDRT, MDRR, CDRT, and CDRR in the Peer Discovery message, and make a best effort to accurately report these metrics subsequently.
> 3. The modem and router MUST include DLEP version in Peer Discovery and Peer Offer messages.
> 4. The modem MUST include a Heartbeat Interval/Threshold TLV in its Peer Discovery messages. It is STRONGLY RECOMMENDED that the Interval be a nonzero value.
> 5. The modem MUST include all metric TLVs it reports in the Peer Discovery Message to allow the router to initialize its session control block.
> 6. The Router MUST NOT include metric TLVs in a Link Characteristics Request message that were not in the session's Peer Discovery message.
> 7. The modem MUST NOT send Peer Discovery messages if it has an existing Peer Session.
> 8. Both router and modem MUST send a Heartbeat Message to the peer if it has sent no DLEP message in an interval equivalent to the Heartbeat Interval value in the Peer Discovery Message. It MAY send a Heartbeat Message in every instance of the interval regardless of any other DLEP traffic.
> 9. Both router and modem MUST reset their Heartbeat timer when any DLEP message arrives from the peer.
> 10. The Heartbeat Interval/Threshold TLV becomes a "Heartbeat Interval TLV." Any DLEP peer is free to set any threshold for terminating the peer session as long as it equals or exceeds two Heartbeat Intervals, unless the Heartbeat Interval is zero.
> 11. We will combine Expected Forwarding Time and Latency TLVs into a single, well-defined TLV.
> 12. Delete the Resources TLVs.
> 13. Keep the RLQ TLV, but Rick and Stan will formulate a stricter definition. There will be no other link quality TLVs (e.g. BER, packet delivery rate, SINR, etc) in the next draft.
> 14. Stan to add clarifying language on how multicast neighbors work, in line with what he said at the meeting.
> 
> As Ron said, the form of the Credits TLVs are unresolved at this moment.
> 
> From: Velt, R. (Ronald) in 't [mailto:[email-masked]] 
> Sent: Thursday, November 07, 2013 5:58 PM
> To: Ulrich Herberg
> Cc: [email-masked]; [email-masked]; [email-masked]; Duke, Martin; Teco Boot ([email-masked]); [email-masked]; Henning Rogge ([email-masked]); [email-masked]; [email-masked]
> Subject: RE: notes DLEP meeting @ IETF88
> 
>> de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, 
>> wordt u verzocht dat aan de afzender te melden en het bericht te 
>> verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van 
>> deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke 
>> aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>>> 
>>> 
>>> 
>> are not the addressee or if this message was sent to you by mistake, 
>> you are requested to inform the sender and delete the message. TNO 
>> accepts no liability for the content of this e-mail, for the manner in 
>> which you use it and for damage of any kind resulting from the risks 
>> inherent to the electronic transmission of messages.
> 
> 
>

---

From: Joe Macker <[email-masked]>
Date: Sat, 9 Nov 2013 17:57:19 -0500

the summary is more important once dt agrees on content and summary 

thanks joe

Sent from my iPhone

> On Nov 9, 2013, at 1:58 AM, Teco Boot <[email-masked]> wrote:
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: Teco Boot <[email-masked]>
Date: Sun, 10 Nov 2013 11:00:03 +0100

More on 7: I think it is OK that a modem supports only a single connection, although this blocks some useful scenario's. So it is a MAY or SHOULD for support for multiple connections. The protocol MUST support such.

On session management: I suggest the Peer Discovery message, send by modem, with only the DLEP Version and Peer Type TLVs. Router responds with TCP connection establishment. After three way handshake the router and modem sends the Peer Offer, with all supported TLVs. These messages are send once and responded with Offer Ack. Session is established when Offer Ack is send and received. Heartbeat timers start at session setup. When no Offer Ack received within Heartbeat interval, somethings went wrong and session establishment restarts over and over.

Text for section 30:

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Discovery---------   Modem initiates discovery
   ...
   <-------Peer Discovery---------   Repeats discovery forever
   ...

   ------------TCP SYN----------->   Router initiates TCP connection
   <-----------TCP SYN ACK--------   Modem part of TCP connection set up
   ------------TCP ACK----------->   Router finishes TCP connection set up

   <---------Peer Offer-----------   Modem starts DLEP session with Offer
   ----------Peer Offer---------->   Router starts DLEP session with Offer
   --------Peer Offer ACK-------->   Router finishes DLEP session set up
   <-------Peer Offer ACK—--------   Modem finishes DLEP session set up

   <=============================>   DLEP session is established

   <--------Peer Heartbeat--------   Heartbeats when no other messages
   ---------Peer Heartbeat------->     between Router and Modem

   <---------Neighbor Up ---------   Modem sends Neighbor Up with metrics
                                     No ACK required

   <-------Neighbor Update--------   Modem Neighbor metrics update
   ...
   <-------Neighbor Update--------
   ...
   <--------Neighbor Down---------   Modem sends Neighbor Down

   When somethings goes wrong or down state is scheduled, DLEP session 
   terminates with TCP connection mechanism:

   --------TCP RESET or FIN------>   Router terminates session
   or
   <-------TCP RESET or FIN-------   Modem terminates session
         completed following 
            TCP procedure

On item 8: here Heartbeat is a MUST. 4 permits a zero timer so it would be SHOULD. I think a MUST is needed for cleanup stale connections.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 00:55:54 +0000

Hmmm… 

I'm finally digging out from the mail storm (250 emails) just from Friday… sigh… 

As to the short version of the notes: 

Item 1 and 2 seem contradictory to me. Metric values are reported via TLVs. If a given metric TLV is MANDATORY, then the router MUST process it (at least, the router MUST NOT generate an error because it exists). What I'm envisioning is *NOT* to "remove" the Resources TLV, but to make it OPTIONAL. Remember, I've got implementations in the field with Resources in it.So for me, it's backwards compatibility… 

Also, as to the Discovery: Here's what I'm writing up as we speak: 

Router                                                                 Modem
========================================
                                     <------------------------ Peer Discovery Message
Peer Offer with           ------------------------->
unicast IP addr/
port for TCP connect

  *Connect on TCP socket. Router has issued TCP "listen", 
    modem issues TCP "connect" (e.g. Modem is the TCP "client",
    router is the TCP "server")

Now, The modem's UDP socket can be closed. Over the TCP 
Socket, 
                                    <------------------------- Peer Initialization containing
                                                                         TLVs/default values for ALL 
                                                                         supported metric values - all 
                                                                         meaning the MANDATORY ones, 
                                                                         plus any optional metrics (right now, 
                                                                         just Resources) that are supported. 

Peer Initialization ACK ---------------------->
MAY contain optional 
Layer 3 (address) TLVs

…. And, everything from there is basically the same as before.

Oh, and on termination:  I'm not removing the "Peer Terminate". Yes, a session can be brought down via TCP FIN. But, you can also announce it with a Peer Terminate. Gives a more orderly way to clean everything up, IMO. 

Point 11 - I didn't hear that. Really, I didn't hear any conclusions about Latency. Other opinions? 

One other BTW - All of the "Neighbor" signals (Neighbor Up, Neighbor Down, Neighbor Status) are renamed to "Destination <blah>" (e.g. Destination Up).

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 01:26:28 +0000

Oh, one more "By the way" - 

The stuff on "logical destinations in the network" (the multicast explanation) was *already in DLEP 04*. In the "Introduction" section, towards the bottom. Specifically: 

  "Multicast traffic is handled in IP networks by deriving a Layer 2 MAC
   address based on the Layer 3 address. Leveraging on this scheme,
   Multicast traffic is supported in DLEP simply by treating the derived
   MAC address as any other destination in the network. To support these
   logical destinations, one of the DLEP participants (typically, the
   router) informs the other as to the existence of the logical
   neighbor. The modem, once it is aware of the existence of this
   logical neighbor, reports link characteristics just as it would for
   any other destination in the network. The specific algorithms a modem
   would use to report metrics on multicast (or logical) destinations is
   outside the scope of this specification, and is left to specific
   implementations to decide."

I'm kind of surprised everyone was surprised….. or is the above explanation really obtuse?

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 16:48:28 +0100

I think we keep Peer Discovery message generation and DLEP session maintenance separate. This keeps state machines less complex, less code, less bugs, increased functionality.

Having multiple DLEP session to same modem is related. If we support it, sending Peer Discovery messages shall not be stopped after first session.

Reason why I need multiple sessions: about half of modems I have to support have multiple ethernet ports. They serve multiple unrelated networks, there is no single connected router. Some modems are 6 digit $, we have to share these expensive assets. And they fully support it;).

Teco

Op 11 nov. 2013, om 16:30 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> Teco,
> 
> Yes, this point was at the very end. The current spec says that if the router receives a Peer Discovery message it must terminate any existing session with that modem. Clearly this is not acceptable behavior if the modem is continuing to multicast Peer Discovery messages when a peer session exists.
> 
> There are other ways to solve this problem, but the reply I got back was that there was no reason to keep seeking routers once a peer session exists. If there's disagreement on this point I'm happy  to back off the assertion that it's settled.
> 
> Martin
> 
> From: Teco Boot [mailto:[email-masked]] 
> Sent: Friday, November 08, 2013 10:59 PM
> To: Duke, Martin
> Cc: DLEP Research Group ([email-masked])
> Good summary, thanks. Let's only post the summary to the MANET ML.
> On 7: It was not discussed during our meeting, at least not were I was present. And I don't think this is a good idea. It is not needed and blocks more advanced usage of DLEP. Let's not have a restriction in that a router or modem has only a single DLEP peer.
> 
> Teco
> 
>> [email-masked]; Duke, Martin; Teco Boot ([email-masked]); 
>> [email-masked]; Henning Rogge ([email-masked]); 
>>> [email-masked]; [email-masked]; Teco Boot 
>>> (teco@inf- net.nl); [email-masked]; Henning Rogge 
>>> ([email-masked]); [email-masked]; [email-masked]
>>> de geadresseerde bent of dit bericht abusievelijk aan u is 
>>> toegezonden, wordt u verzocht dat aan de afzender te melden en het 
>>> bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de 
>>> inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor 
>>> schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>>>> 
>>>> 
>>>> 
>>> accepts no liability for the content of this e-mail, for the manner 
>>> in which you use it and for damage of any kind resulting from the 
>>> risks inherent to the electronic transmission of messages.
>> 
>> 
>>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Nov 2013 16:58:35 +0100

I like this sequence except for a tiny little bit in the middle:

>    <-------Peer Offer ACK—--------   Modem finishes DLEP session set up

This opens the code for some strange timing conditions... why not just
make it a normal 3-way (or 4 way) handshake?

Modem sends Peer Offer to Router.
Router answers with Peer Offer ACK...
only after this the router sends a Peer Offer to the Modem...
Modem answers with a Peer Offer ACK.

This way the timing of the messages can only happen in a single way,
no need to guess who answers first.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:00:22 +0100

Was Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

I'll split of threads, unless one prefer mail storms without clear subjects.

Op 11 nov. 2013, om 01:55 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> Item 1 and 2 seem contradictory to me. Metric values are reported via TLVs. If a given metric TLV is MANDATORY, then the router MUST process it (at least, the router MUST NOT generate an error because it exists).

>>>>> 2. The modem MUST report MDRT, MDRR, CDRT, and CDRR in the Peer Discovery message, and make a best effort to accurately report these metrics subsequently.

Item 2 is the first one to read, then item 1 follows. Routers may ignore all TLVs, and for example only use Neighbor Up and Neighbor Down.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:11:55 +0100

Op 11 nov. 2013, om 01:55 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> What I'm envisioning is *NOT* to "remove" the Resources TLV, but to make it OPTIONAL. Remember, I've got implementations in the field with Resources in it.So for me, it's backwards compatibility…

We all have some kind of implementation (so do I).

I prefer complementary DLEP documents. It defines the optional TLV, purpose etc. This helps us get out the core document quickly. 

On a DLEP Resources RFC, I suggest not to mention battery level. Nor amount left in prepaid bundle. Such are very useful and deserve their own TLV.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:15:26 +0100

> Point 11 - I didn't hear that. Really, I didn't hear any conclusions about Latency. Other opinions? 

We discussed it and all speakers said it is an important metric, so it will be an optional TLV in core document.

Wasn't Henning tasked with verifying Latency and EFT?

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:17:49 +0100

> One other BTW - All of the "Neighbor" signals (Neighbor Up, Neighbor Down, Neighbor Status) are renamed to "Destination <blah>" (e.g. Destination Up).

Popped up after our meeting.
No objections heard, some comments: rename makes sense.
Go for it.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:19:57 +0100

> Oh, and on termination:  I'm not removing the "Peer Terminate". Yes, a session can be brought down via TCP FIN. But, you can also announce it with a Peer Terminate. Gives a more orderly way to clea…

It doesn't add anything, other than more messages, more state, more code and more bugs.
What am I missing?

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:29:11 +0100

> Also, as to the Discovery: Here's what I'm writing up as we speak: 

So this is multicast reply, telling modem to connect?
Why not TCP connect from router to modem? Makes more sense to me, the modem is the peer offering a service.
Maybe add a TcpPort TLV in the Peer Discovery, this allows other than IANA assigned ports.

> Now, The modem's UDP socket can be closed.

Please don't.

> Over the TCP 

Yes, here the full set TLV exchange takes place. This should not be in the Peer Discovery. That's why I suggested to put this in the Peer Offer.

> Peer Initialization ACK ---------------------->

I'm fine with three way handshake, not with this two way. Or use TCP disconnect when modem modem is not willing to accept first message from router.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 17:52:43 +0100

> I'm kind of surprised everyone was surprised….. or is the above explanation really obtuse?

This texts perfectly states why to take it out of the core document. We need to get more info on how multicast is handled and thereafter define the DLEP extensions for it.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 17:33:21 +0000

Teco, 

I'm opposed to putting Resources in yet another draft. Yes, I understand that you have an implementation. My company has sold units, and has them in the field, interoperating with other company's products. Stripping the Resources TLV makes them non-compliant. IMHO, that's not an option. 

I'm not opposed to changing the text around the (now) optional Resources TLV, to make it more vague. I am opposed to removing it in its entirety. Hence, I detect that we are at deadlock. Other opinions, please?

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 17:34:21 +0000

> It doesn't add anything, other than more messages, more state, more code and more bugs.

The ability for one side of the DLEP connection to tell the other *why* things are going down. 

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 17:38:09 +0000

> This texts perfectly states why to take it out of the core document. We need to get more info on how multicast is handled and thereafter define the DLEP extensions for it.

WHAT?!?!?!?!?! Your response makes no sense to me whatsoever. 

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 11 Nov 2013 17:44:04 +0000

> Item 2 is the first one to read, then item 1 follows. Routers may ignore all TLVs, and for example only use Neighbor Up and Neighbor Down.

Oh, well…. naturally. When looking at an enumerated list, I *SHOULD HAVE* had the general sense to read the second item first…. silly me.

On another topic, to say that I disagree with "… Routers may ignore all TLVs…" would be an understatement. That's why TLVs are classified as MANDATORY or OPTIONAL. Routers (or modems, for that matter) are free to ignore OPTIONAL TLVs. But to mandate that something exist in a message, but then say "but you can ignore it"? Doesn't make any sense to me. 

Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Nov 2013 18:46:42 +0100

> On another topic, to say that I disagree with "… Routers may ignore all TLVs…" would be an understatement. That's why TLVs are classified as MANDATORY or OPTIONAL. Routers (or modems, for that matt…

A good example is the "current link speed" TLV...

we demand that every radio provides one, but a router might just
decide to ignore it because its not necessary for this router.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:01:42 +0100

> no need to guess who answers first.

Agreed. 

Stan suggested a two-way handshake, enough for TLV exchange.
Third message eliminates reception of unexpected messages.

  Router                    Modem
  ===============================

  ... after TCP connection established, router sets up the DLEP session:
  ----------Peer Offer---------->   Router starts DLEP session with Offer
  <--------Peer Offer ACK--------   Modem joins in DLEP session with Offer ACK
  ---------Peer Offer ACK------->   Router completes DLEP session with Offer ACK

After Router has send Peer Offer ACK, it may send other messages.
After Modem has received Peer Offer ACK, it may send other messages.
If something unexpected or unacceptable occurs, TCP connection is closed and as a result the DLEP session is closed.

Maybe rename the message to Peer Initialize and Peer Initialize Ack (following Stan here).

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:04:32 +0100

> I'm opposed to putting Resources in yet another draft. Yes, I understand that you have an implementation. My company has sold units, and has them in the field, interoperating with other company's p…

Yes, IETF DLEP will not be compatible with your products.
IETF has no objective to be so.
You have to change your code anyway.

> 
> I'm not opposed to changing the text around the (now) optional Resources TLV, to make it more vague.

Agreed.

> I am opposed to removing it in its entirety. Hence, I detect that we are at deadlock. Other opinions, please?

There is no deadlock.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:13:58 +0100

> The ability for one side of the DLEP connection to tell the other *why* things are going down. 

I think a "Peer Down" message makes sense. This is very different than terminating a DLEP session, in that the latter would not indicate peers are no longer accessible. A "Peer Down" has an implicit meaning that all Destinations are down. Closure of DLEP TCP connection would not indicate such.

Maybe use a generic Peer Error message, as notification. Could be send before TCP connection teardown.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:17:17 +0100

> On another topic, to say that I disagree with "… Routers may ignore all TLVs…" would be an understatement. That's why TLVs are classified as MANDATORY or OPTIONAL. Routers (or modems, for that matt…

Why do you care? It is perfectly fine you use these mandatory TLV's. Let others do their thing. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:21:22 +0100

> WHAT?!?!?!?!?! Your response makes no sense to me whatsoever. 

If there is no idea on semantics for exchanged data items, let's take it out of the IETF standards process. 

I guess you missed my intention. I prefer clearly defined protocols that are useful for any of us. That includes DLEP multicast support. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 19:30:52 +0100

I might have missed some context here, discussed during post-meeting meeting.

Do you think there is a need for terminating the TCP connection, other than what TCP can provide? Maybe you had something in mind with heartbeat turned off and blocked TCP port. I prefer a non-blocking implementation. For a crashed DLEP agent, I can think of a Peer Order with Reset TLV, where router resets the modem. Would be similar to AT!RESET.

Teco

Op 11 nov. 2013, om 17:33 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> Teco,
> 
> Although I follow that you want multiple peer sessions per modem, I'm having trouble parsing what your prescription is to address the peer session teardown problem I pointed out.
> 
> Martin
> 
> Sent: Monday, November 11, 2013 7:48 AM
> To: Duke, Martin
> Cc: [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Nov 2013 19:55:01 +0100

On Mon, Nov 11, 2013 at 7:30 PM, Teco Boot <[email-masked]> wrote:
> For a crashed DLEP agent, I can think of a Peer Order with Reset TLV, where router resets the modem. Would be similar to AT!RESET.

Reset TLV is not necessary I think... if it comes from the same IP
address, its the same device and you can kill the old session.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 11 Nov 2013 22:39:26 +0100

Let's come back to this topic after we completed TCP connection and DLEP session management. Probably the issue is solved by then. 

Please comment on the TCP connection setup and maintenance. Below the proposal, adjusted after comments from Stan and Henning.

                                    with server TCP port

  ------------TCP SYN----------->   Router initiates TCP connection to TCP server 
                                    port from Peer Discovery
  <---------TCP SYN ACK----------   Modem part of TCP connection set up
  ------------TCP ACK----------->   Router finishes TCP connection set up

  -----------Peer Offer--------->   Router starts DLEP session with Offer
  <--------Peer Offer ACK--------   Modem joins in DLEP session with Offer Ack
  ---------Peer Offer ACK------->   Router completes DLEP session with Offer Ack

                                    No DLEP Ack required

  When somethings goes wrong or down state is scheduled, DLEP session 
  terminates with TCP connection mechanism. Before, a Peer Error MAY
  be send.

  <----------Peer Error----------   Optional Modem error report
  <-------TCP RESET or FIN-------   Modem terminates session
        completed following 
           TCP procedure
  or
  -----------Peer Error--------->   Optional Router error report
  --------TCP RESET or FIN------>   Router terminates session
        completed following 
           TCP procedure

Teco

Op 11 nov. 2013, om 19:48 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> We must be talking past each other. In Section 11 of DLEP-04:
> 
> A Peer Discovery Message received from a modem that is
>   already in session MUST be processed as if a Peer Termination Message
>   had been received. A router implementation MAY then process the
>   received Peer Discovery Message.
> 
> The plain language interpretation of this is that a modem that continues to send out Peer Discovery messages to find new peers will trigger resets of existing sessions.
> 
> Perhaps the root problem is that we haven't really done a scrub for the implications of using TCP on all of the reliability mechanisms from previous drafts. I get confused on whether or not we're precluding UDP implementations, but maybe the right answer is to simply delete this provision.
> 
> Sent: Monday, November 11, 2013 10:31 AM
> To: Duke, Martin
>>>> [email-masked]; Duke, Martin; Teco Boot
>>>> ([email-masked]); [email-masked]; Henning Rogge
>>>>> bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor
>>>>> de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor
>>>>> are not the addressee or if this message was sent to you by
>>>>> mistake, you are requested to inform the sender and delete the
>>>>> message. TNO accepts no liability for the content of this e-mail,
>>>>> for the manner in which you use it and for damage of any kind
>>>>> resulting from the risks inherent to the electronic transmission of messages.
>>>> 
>>>> 
>>>>

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 06:57:01 +0100

Op 11 nov. 2013, om 22:45 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> What is the purpose of the second Peer Offer ACK?

It informs the modem that router accepts the Modem Peer Offer. Then both peers of the session knows session setup was successful. If the Router does not accept the Peer Offer Ack (e.g. version mismatch), it sends an error and / or closes the connection.

Teco

> Sent: Monday, November 11, 2013 1:39 PM
> To: Duke, Martin

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 12:47:01 +0000

Sorry for the delay, I was out of office yesterday.

My thoughts:

    Router                                        Modem
    ===================================================

1)                                  TCP socket listen()

2)  <--------------------------- Peer Discovery Message
                              UDP unicast or broadcast?
                                       + Session Cookie
                                     + TCP address/port
           + Alternate reliable protocol endpoint infos

3)  TCP connect()

4)  Initialize (was Peer Offer) ---------------------->
    + Session Cookie

5)  <----------------------------------- Initialize ACK
                                       + Session Cookie
                                + Supported metric TLVs

My reasoning, often agreeing with others:

The Modem 'advertises' its DLEP support, and therefore should
be the one that listens for the TCP connect.

A cookie passed between the UDP discovery message and the TCP
connection adds a little security (is this the modem I think I am
connecting to?)  This could be extended to a full signature TLV
in a later RFC.

The Peer Discovery message could carry additional reliable
protocol endpoint information for non-TCP transports.

The Initialize ACK is the correct place to put the 'default'
metric TLVs, and is sent by the modem.

A 3-way handshake seems safer to me.

I have a question over whether the Peer Discovery message should
be unicast to a configured destination, or broadcast to all
connected peers on a TBD port.  I prefer broadcast as it is more
ZeroConf, but I can see use-cases for unicast to a configured
destination for more complex topologies.

Cheers,

Rick Taylor

> From: [email-masked] [mailto:manet-dlep-rg-
> [email-masked]] On Behalf Of Teco Boot
> Sent: 11 November 2013 16:29
> To: Stan Ratliff
> Subject: [manet-dlep-rg] DLEP session establishment
>
>
> Op 11 nov. 2013, om 01:55 heeft Stan Ratliff (sratliff)
> <[email-masked]> het volgende geschreven:
>
> > Router
> Modem
> Yes, here the full set TLV exchange takes place. This should not be in the
> Peer Discovery. That's why I suggested to put this in the Peer Offer.
>
>
> >
> I'm fine with three way handshake, not with this two way. Or use TCP
> disconnect when modem modem is not willing to accept first message from
> router.
>
> Teco
>
> >
> > .... And, everything from there is basically the same as before.
>
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 12:51:55 +0000

My understanding of mandatory metrics was:

Modems:  MUST advertise support (by giving default values in Initialize message at least) for MDRT,MDRR,CDRT,CDRR, RLQ and Latency (TBD)

Routers:  MUST NOT terminate a connection on receipt of any of these TLVs because they do not 'understand' them.  Whether the router does anything with any of these metrics is the router's business.

Rick Taylor

> Sent: 11 November 2013 18:17
> To: Stan Ratliff
> Subject: Re: [manet-dlep-rg] Mandatory processing TLVs by routers
>
>
> Op 11 nov. 2013, om 18:44 heeft Stan Ratliff (sratliff)
> >>> Item 1 and 2 seem contradictory to me. Metric values are reported via
> TLVs. If a given metric TLV is MANDATORY, then the router MUST process it
> (at least, the router MUST NOT generate an error because it exists).
> >>
> >> This is about:
> >>
> >>>>>>> 2. The modem MUST report MDRT, MDRR, CDRT, and CDRR in the Peer
> Discovery message, and make a best effort to accurately report these
> metrics subsequently.
> >>
> >> Item 2 is the first one to read, then item 1 follows. Routers may
> ignore all TLVs, and for example only use Neighbor Up and Neighbor Down.
> >
> >
> > Oh, well.... naturally. When looking at an enumerated list, I *SHOULD
> HAVE* had the general sense to read the second item first.... silly me.
> >
> > On another topic, to say that I disagree with "... Routers may ignore all
> TLVs..." would be an understatement. That's why TLVs are classified as
> MANDATORY or OPTIONAL. Routers (or modems, for that matter) are free to
> ignore OPTIONAL TLVs. But to mandate that something exist in a message,
> but then say "but you can ignore it"? Doesn't make any sense to me.
>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 12:57:55 +0000

+1

Keep the Peer Terminate message.  Include a status value to differentiate between a normal and abnormal termination.

Status 0 = Ok - Normal shutdown, e.g. user turned off device
1 = Missing heartbeats
2 = Incompatible configuration

I'm guessing at status codes here, but it's an idea.

Obviously a terminate can come from either modem or router, and MUST be the last message.

I am not sure it is clear that the termination of a DLEP session implies that all destinations are no longer reachable.  No more DLEP metrics about those destinations, sure, but unreachable?

Rick Taylor

> Sent: 11 November 2013 18:14
> To: Stan Ratliff
> Subject: Re: [manet-dlep-rg] Peer termination
>
>
> Op 11 nov. 2013, om 18:34 heeft Stan Ratliff (sratliff)
> >>> Oh, and on termination:  I'm not removing the "Peer Terminate". Yes, a
> session can be brought down via TCP FIN. But, you can also announce it
> with a Peer Terminate. Gives a more orderly way to clean everything up,
> IMO.
> >>
> I think a "Peer Down" message makes sense. This is very different than
> terminating a DLEP session, in that the latter would not indicate peers
> are no longer accessible. A "Peer Down" has an implicit meaning that all
> Destinations are down. Closure of DLEP TCP connection would not indicate
> such.
>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 13:02:50 +0000

Hmmm...  I don't like resources.  I never have, it seems to be another amorphous summary metric like RLQ but associated with the destination modem rather than the destination address.

I would propose that Stan moves his resources TLV to a vendor extension (and clearly defines it for his users).

I would have no objection to including Resources in the draft as a worked example of an extension metric TLV that applies to a modem rather than an address, as I have vendor extensions of that class, and would like the draft to offer good guidance to implementers of such extensions.

If that sounds like a fudge, it is because it is.

Rick Taylor

> Sent: 11 November 2013 18:05
> To: Stan Ratliff
> Subject: Re: [manet-dlep-rg] Resources TLV
>
>
> Op 11 nov. 2013, om 18:33 heeft Stan Ratliff (sratliff)
> > I'm opposed to putting Resources in yet another draft. Yes, I understand
> that you have an implementation. My company has sold units, and has them
> in the field, interoperating with other company's products. Stripping the
> Resources TLV makes them non-compliant. IMHO, that's not an option.
>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 13:16:35 +0000

I'm not sure if I was particularly clear in my opinion about Latency.

I would like to see a single 'good' latency/time metric mandatory in DLEP.

I appreciate the work Henning has already done in this area, and suggest to the DT that he selects a sensible definition of the Latency TLV (if he is willing!) and I'm sure we can all have a good argument about it afterwards ;)

Cheers,

Rick Taylor

> Sent: 11 November 2013 16:15
> To: Stan Ratliff
> Subject: [manet-dlep-rg] Latency
>
>
> We discussed it and all speakers said it is an important metric, so it
> will be an optional TLV in core document.
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 14:22:44 +0100

Yes, I heard this too in the MANET Meeting...

which made me wonder a bit because I was puzzled what was the
difference between the two.

Can maybe the people who already have an implementation for DLEP tell
us what kind of Latency they implemented?

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 13:43:07 +0000

>From my experience:

My test DLEP devices just make up a number (not very helpful)

The radios I have used that support DLEP-00 natively report a latency in ms.  What that really is I have no idea.  Again, not very useful.

I have my own DLEP proxy for some other radios, and I have just reported half of RTT on my control packets, which given I have jitter and back-off, again isn't very useful.

BUT, Having a latency metric, even if it is almost meaningless, is better than no metric at all.

I could suggest 100ms * hop-count works in mesh radios, as one of the simplest uses of latency is as an improved hopcount for split-horizoning in routing protocols.

It's amazing what one will try to use, even if the quality of the data is very poor!

Rick Taylor

> [email-masked]] On Behalf Of Henning Rogge
> Sent: 12 November 2013 13:23
> To: Teco Boot
> Cc: DLEP Research Group ([email-masked]); Stan Ratliff
> Subject: Re: [manet-dlep-rg] Latency
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 15:16:48 +0000

OK, looks like my opinion is "in the rough" on this one… 

But I'm still concerned about putting the TCP "server" code into the (probably more) constrained modem device. So, what if we make the *router* issue the Peer Discovery (call it a Peer Advertisement) to an MCAST address/well-known port? That Peer Discovery/Peer Advertisement would contain the unicast IP address/port for the TCP listener. The modem would respond with the TCP SYN…

The router would continue to periodically "strobe" the Peer Discovery/Peer Advertisement ad-nauseum (as much as I hate that approach).

I'm really concerned about modem-side complexity, based on discussions I had a couple of years ago with some radio vendors who were looking at implementing. 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 15:24:51 +0000

The radios I've worked with report latency as a "rolling average", in ms, for queueing time + transmission. The total amount of time used for the rolling average is left to the radio implementation. 

Yes, multi-hop mesh radios confuse the issue. Ideally, I'd like to see "END-TO-END queueing time + transmission time", but some approximation thereof might work. I would contend that it's the modem's job to do the approximating (e.g. the modem provides "latency", *not* "Here's a hop count, and some multiplier for that hop count, go knock your lights out…"

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 16:27:12 +0100

How much resolution do we need?

It milliseconds enough, or do we need to do better? Maybe 32 bit
integer in microseconds? That would give us enough precision but also
allows for high-delay radios.

*looking at Stan's reply* rolling latency sounds reasonable, so its
similar to the "control package RTT" Rick Taylor told us about?

So we are looking for a value that means "rough estimate of the time
between IP packet got delivered to radio and IP packet leaves other
radio" ?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 16:29:09 +0100

My view on DLEP is that it is loosely coupled with forwarding state. DLEP session termination doesn’t mean destinations are unreachable. If the modem sends Destination Down, it is likely the Destination is indeed unreachable. No guarantees here.

If the Modem knows Destinations are unreachable, it should send such.

Bit of a problem is Destination state the Router knows about, but no state was received in current DLEP session. State was set up by a previous DLEP session which was closed without Destination Down, or by the router hello protocol. I would say DLEP session state takes preference. Router is free to do otherwise.

Teco

PS. Radio Silence - Receive only is one of the operation modes I’m dealing with.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 15:34:11 +0000

> between IP packet got delivered to radio and IP packet leaves other

That sounds right to me. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 16:35:50 +0100

I must admit I like our original solution more, the one where the
radio initiates the contact.

I don't buy in the "complexity of tcp socket" thing, because most DLEP
radios/modems will only allow a single router to connect to them. This
should keep the complexity in check.

We also talked about leaving things out of DLEP that belong to SNMP
(or maybe web interfaces)... if the radio can handle SNMP, it can also
handle a single TCP session.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 15:40:41 +0000

> I am not sure it is clear that the termination of a DLEP session implies that all destinations are no longer reachable.  No more DLEP metrics about those destinations, sure, but unreachable?

At least in the current Cisco implementation, Peer Termination means that all information learned from the Peer is no longer valid. So the router removes information about all destinations learned via the modem. To do otherwise would put you a weird state if/when the radio comes back online. You'd have an "information base" for an instantiation of DLEP in the peer that wasn't built by said instantiation… 

Also, in the Cisco implementation, removing the known destinations for a modem fires an indicator to routing protocols to drive "Dead Timer" for those destinations. So, the routing protocols will remove any existing adjacency, and re-converge. So yes, the current implementation pretty much equates DLEP termination to "destination unreachable".

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 15:45:58 +0000

Hmmm... good point about complexity in the radio Stan.

I'd be okay with flipping the whole discovery process so the router advertises and the radio connects.  Making the router maintain the extra timer for strobing is probably more sensible.  Obviously some recommendation for timing of the strobes is needed.

The handshake still stays 3-way and that covers most of my concerns.

Any comment on a cookie in the offer?

I have double checked with the 04 draft, and you have covered the broadcast or configured unicast UDP address in the text, so I'm happy.

Rick Taylor

> From: Stan Ratliff (sratliff) [mailto:[email-masked]]
> Sent: 12 November 2013 15:17
> To: Taylor, Rick
> Subject: Re: [manet-dlep-rg] DLEP session establishment
>
> OK, looks like my opinion is "in the rough" on this one...
>
> But I'm still concerned about putting the TCP "server" code into the
> (probably more) constrained modem device. So, what if we make the *router*
> issue the Peer Discovery (call it a Peer Advertisement) to an MCAST
> address/well-known port? That Peer Discovery/Peer Advertisement would
> contain the unicast IP address/port for the TCP listener. The modem would
> respond with the TCP SYN...
>
> The router would continue to periodically "strobe" the Peer Discovery/Peer
> Advertisement ad-nauseum (as much as I hate that approach).
>
> I'm really concerned about modem-side complexity, based on discussions I
> had a couple of years ago with some radio vendors who were looking at
> implementing.
>
> Regards,
> Stan
>
> >> Maybe add a TcpPort TLV in the Peer Discovery, this allows other than
> IANA
> >> assigned ports.
> >>
> >>
> >>>
> > The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained
> within this e-mail or attached files, please contact the sender prior to
> any such disclosure. If you are not the intended recipient, any
> disclosure, copying or distribution is prohibited. Please also contact the
> sender and inform them of the error and delete the e-mail, including any
> attached files from your system. Cassidian Limited, Registered Office :
> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:
> 04191036 http://www.cassidian.com

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 15:47:29 +0000

Stan,

I'm going through the 04 draft and noting potential changes that will need to be made prior to 05 and will let you have a copy of the list when I can get it off one machine onto the other (don't ask!)

I'll also commit to updating some of the text for you...

Rick Taylor

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 15:48:56 +0000

> should keep the complexity in check.

The additional complexity comes with issuing the listen() call, handling receipt of the listen (which in over 95% of the cases I've seen, requires non-blocking socket mode and use of select() or poll()), and getting the accept() done…. 
I'll try to contact the radio vendors I was talking to a couple of years ago and see how they feel about the radio taking on the role of TCP "server". I don't have an ETA for a response.

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 15:54:19 +0000

I agree Stan: what you have described is the most rational handling of the situation, but I was wondering out loud if it was felt that specific text detailing that is required...

Rick Taylor

> Sent: 12 November 2013 15:41
> To: Taylor, Rick
> > Keep the Peer Terminate message.  Include a status value to
> differentiate between a normal and abnormal termination.
> >
> > I am not sure it is clear that the termination of a DLEP session implies
> that all destinations are no longer reachable.  No more DLEP metrics about
> those destinations, sure, but unreachable?
>
> At least in the current Cisco implementation, Peer Termination means that
> all information learned from the Peer is no longer valid. So the router
> removes information about all destinations learned via the modem. To do
> otherwise would put you a weird state if/when the radio comes back online.
> You'd have an "information base" for an instantiation of DLEP in the peer
> that wasn't built by said instantiation...
>
> Also, in the Cisco implementation, removing the known destinations for a
> modem fires an indicator to routing protocols to drive "Dead Timer" for
> those destinations. So, the routing protocols will remove any existing
> adjacency, and re-converge. So yes, the current implementation pretty much
> equates DLEP termination to "destination unreachable".
>
> Regards,
> Stan
>
>
> >
> > Rick Taylor
> >
> >>> The ability for one side of the DLEP connection to tell the other
> *why*
> >> things are going down.
> >>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 15:52:08 +0000

32 bit ms sounds good to me.

I wasn't suggesting X*hopcount was a good way of reporting latency, I was just giving you insight into a personal hack ;)

I think there is a general rule that should be covered by the 'Best Effort' statement:  In a multi-hop mesh, the metrics must reflect the fact it is multi-hop in a 'Best Effort' way.  That includes Latency, which I would consider a cumulative metric.

Rick Taylor

> [email-masked]] On Behalf Of Stan Ratliff (sratliff)
> Sent: 12 November 2013 15:34
> To: Henning Rogge
> Cc: DLEP Research Group ([email-masked]); Teco Boot; Taylor, Rick
> >> The radios I have used that support DLEP-00 natively report a latency
> in ms.  What that really is I have no idea.  Again, not very useful.
> >>
> >> I have my own DLEP proxy for some other radios, and I have just
> reported half of RTT on my control packets, which given I have jitter and
> back-off, again isn't very useful.
> >>
> >> I could suggest 100ms * hop-count works in mesh radios, as one of the
> simplest uses of latency is as an improved hopcount for split-horizoning
> in routing protocols.
> >>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 16:59:05 +0100

32 Bit and "milliseconds" would be a little bit much I think...

I was thinking about 32 Bit MICROseconds... would still allow for a
delay of more than one hour.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:04:11 +0000

Rick, 

> Any comment on a cookie in the offer?

What is the cookie used for? I was thinking the TCP 4-tuple (Source IP/Source Port/Destination IP/Destination Port) is sufficient for any correlation.

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:04:47 +0000

On Nov 12, 2013, at 10:47 AM, "Taylor, Rick" <[email-masked]> wrote:

> I'll also commit to updating some of the text for you…

Thanks, but I can handle the updates. We just need to agree on the text. 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:10:41 +0000

Henning, 

I had a thought here. You spoke before about talking with some people you know doing SDR development. Could you talk with them again about their preferences regarding whether they would want a TCP "server" implementation in the SDR or a TCP "client"? 

I'm also going to MILCOM next week; I'll be working with some of the guys from Persistent Systems (radio vendor; they have a DLEP implementation). I'll ask them about the TCP server vs. client issue, and report back to the DT. 

I'm just concerned that, while all of us have good backgrounds in wireless networking and dealing with radios, none of us are actually involved with creating a radio as a product. I think we're missing a valuable point of view. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 17:12:42 +0100

SDRs are machines with LOTS of CPU power (plus FPGA and DSP).

I don't think they would care about TCP server sockets at all. But I
can ask my co-workers at our SDR development tomorrow.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:18:19 +0000

I agree microseconds makes more sense numerically, but does it make sense from a latency recording sense, can we really ask for microsecond accuracy?

I leave it to you guys to advise...

Rick Taylor

> Sent: 12 November 2013 15:59
> To: Taylor, Rick
> Cc: DLEP Research Group ([email-masked]); Teco Boot; Stan Ratliff
> (sratliff)
> > I wasn't suggesting X*hopcount was a good way of reporting latency, I
> was just giving you insight into a personal hack ;)
> >
> > I think there is a general rule that should be covered by the 'Best
> Effort' statement:  In a multi-hop mesh, the metrics must reflect the fact
> it is multi-hop in a 'Best Effort' way.  That includes Latency, which I
> would consider a cumulative metric.
> >
> > Rick Taylor
> >
> >> >> It's amazing what one will try to use, even if the quality of the
> data
> >> is very poor!
> >> >>
> >> >> Rick Taylor
> >> >>
> >> >>>>> Point 11 - I didn't hear that. Really, I didn't hear any
> conclusions
> >> >>> about Latency. Other opinions?
> >> >>>>
> >> >>>> We discussed it and all speakers said it is an important metric,
> so
> >> it

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:23:29 +0000

John or I may be in a position to put the same question to a large military radio manufacturer in the next couple of weeks.

Rick Taylor

> Sent: 12 November 2013 16:11
> To: Henning Rogge
> Cc: DLEP Research Group ([email-masked]); Taylor, Rick
> I had a thought here. You spoke before about talking with some people you
> know doing SDR development. Could you talk with them again about their
> preferences regarding whether they would want a TCP "server"
> implementation in the SDR or a TCP "client"?
>
> I'm also going to MILCOM next week; I'll be working with some of the guys
> from Persistent Systems (radio vendor; they have a DLEP implementation).
> I'll ask them about the TCP server vs. client issue, and report back to
> the DT.
>
> I'm just concerned that, while all of us have good backgrounds in wireless
> networking and dealing with radios, none of us are actually involved with
> creating a radio as a product. I think we're missing a valuable point of
> view.
>
> Regards,
> Stan
>
> >> The router would continue to periodically "strobe" the Peer
> Discovery/Peer Advertisement ad-nauseum (as much as I hate that approach).
> >>
> >> I'm really concerned about modem-side complexity, based on discussions
> I had a couple of years ago with some radio vendors who were looking at
> implementing.
> >>
> >> Regards,
> >> Stan
> >>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:21:36 +0000

I seem to remember SCTP (which I hold in high regard) uses a cookie for its 4-way handshake on the grounds that it stops some types of spoofing attacks.

I'll re-read their rationale doc if I can find it.  I was just trying to cover some security considerations here, but it might be misplaced.

I just wonder whether replying to a broadcast with a IP address by blindly connecting to it without some way of checking what your connecting to is what you expect to be there is 'unsafe' - but you do make a good point about the TCP 4-tuple...

Rick Taylor

> Sent: 12 November 2013 16:04
> To: Taylor, Rick
> > I'd be okay with flipping the whole discovery process so the router
> advertises and the radio connects.  Making the router maintain the extra
> timer for strobing is probably more sensible.  Obviously some
> recommendation for timing of the strobes is needed.
> >
> What is the cookie used for? I was thinking the TCP 4-tuple (Source
> IP/Source Port/Destination IP/Destination Port) is sufficient for any
> correlation.
>
> Regards,
> Stan
>
> >
> > I have double checked with the 04 draft, and you have covered the
> broadcast or configured unicast UDP address in the text, so I'm happy.
> >
> > Rick Taylor
> >
> Discovery/Peer
> I
> >>>> Yes, here the full set TLV exchange takes place. This should not be
> in
> >> the

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:24:38 +0000

No worries, just offering as I have permission to free up some cycles for DLEP.

Rick Taylor

> Sent: 12 November 2013 16:05
> To: Taylor, Rick
> Subject: Re: [manet-dlep-rg] Draft-04 text
>
>
> > I'm going through the 04 draft and noting potential changes that will
> need to be made prior to 05 and will let you have a copy of the list when
> I can get it off one machine onto the other (don't ask!)
> >

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 17:26:42 +0100

I am not worried about the accuracy but that some radios with a strict
TDMA might fall below the 1ms delay.

But millisecond precision might be good enough.

Is 16 Bit in milliseconds good enough (up to 16 seconds delay) ?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 17:27:35 +0100

I think if someone breaks into the local link between router and
radio/modem, you have more things to worry about than spoofing
attacks.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 17:32:40 +0100

Op 12 nov. 2013, om 17:04 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> It feels like the terminology is a bit jumbled here. The "Peer Discovery" contains all the session parameters for the modem. The "Peer Offer" in effect acknowledges these and contains relevant parameters for the Router. The "Peer Offer ACK" confirms the modem's acceptance of these? Why do we have to confirm the confirmation?

We have to come back to this. Recent posts rename couple of messages. Discovery is just the advertisement, where DLEP session setup takes care of transfer of all supported TLVs.

The Peer Offer would be renamed to Peer Initialization, with three-way handshake.

Maybe better rename Peer Discovery to DLEP Modem Advertisement.

All of this has to do with rework because we transfer to TCP were we have the connection setup.

Teco

> Sent: Monday, November 11, 2013 9:57 PM
> To: Duke, Martin
>>                                  with server TCP port ...
>> terminates with TCP connection mechanism. Before, a Peer Error MAY be 
>> send.
>> 
>>> A Peer Discovery Message received from a modem that is already in 
>>> session MUST be processed as if a Peer Termination Message had been 
>>> received. A router implementation MAY then process the received Peer 
>>> Discovery Message.
>>> 
>>>>>>> toegezonden, wordt u verzocht dat aan de afzender te melden en 
>>>>>>> het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid 
>>>>>>> voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt 
>>>>>>> en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:38:12 +0000

Opening a contentious issue here...

I am concerned about the length field in a TLV - 8 bits seems too small.

My reasoning:

According to draft-04, section 10, all protocol messages have a standard header that states that the length field of the header is the sum of the length of the TLVs in the message + the length of the message, and 256-9 bytes seems too small.  It's okay for now (just), approximately 11 64bit TLVs, but once you include IPv6 addresses it starts to look a little tight.

Going forwards, one of the ideas bounced about at Berlin for per-flow-metrics was a 'bracketing' TLV that associated a set of TLVs with a certain flow, and in that case we will definitely run out of length bits.

I know we aren't touching per-flow-metrics, but one day someone will, and finding extra length bits is a complete pain (The ForCES WG are suffering it right now)

Proposal:

Change:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Signal TLV Type| Length        | DLEP data items...            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Signal TLV Type| Flags ( = 0)  | Length (16 bits)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP data items...                                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also, it might allow us to enforce a 32-bit alignment on TLVs that some processors find a little nicer to handle.  This is less relevant than the extra length bits.

This also applies to section 8.

Rick Taylor

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 12 Nov 2013 16:43:48 +0000

I think 16 seconds delay is going to be too small - some HF radios with clever IP implementations can have enormous latency, someone might try using this in DTNs - Mars is more than 16 seconds away I think ;)

Also, if there are radios that might need microseconds then we should specify them.

Perhaps you should ignore me and stick with 32bits microseconds - that's 71 minutes if my rough calculation is correct, and the sun is only 8 light minutes away, and I don't think we need to panic about saving 2 bytes on the wire.

Rick Taylor

> Sent: 12 November 2013 16:27
> To: Taylor, Rick
> > I agree microseconds makes more sense numerically, but does it make
> sense from a latency recording sense, can we really ask for microsecond
> accuracy?
> >
> >> On Tue, Nov 12, 2013 at 4:52 PM, Taylor, Rick
> <[email-masked]>
> >> wrote:
> >> >> reported half of RTT on my control packets, which given I have
> jitter
> >> and
> >> >> >> BUT, Having a latency metric, even if it is almost meaningless,
> is
> >> >> better than no metric at all.
> >> >> >>
> >> >> >>> long enough on the shores of the cosmic ocean. We are ready at
> last
> >> to
> >> >> >> The information contained within this e-mail and any files
> attached
> >> to
> >> >> within this e-mail or attached files, please contact the sender
> prior
> >> to
> >> >> disclosure, copying or distribution is prohibited. Please also
> contact
> >> the
> >> >> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ
> Company
> >> No:
> >> >> > long enough on the shores of the cosmic ocean. We are ready at
> last
> >> to

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 16:32:07 +0100

Op 12 nov. 2013, om 13:51 heeft Taylor, Rick <[email-masked]> het volgende geschreven:

> Routers:  MUST NOT terminate a connection on receipt of any of these TLVs because they do not 'understand' them.

Router SHOULD NOT terminate a connection on receipt of any TLVs it doesn't 'understand'.

Teco

>   Whether the router does anything with any of these metrics is the router's business.
> 
> Rick Taylor
>

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 16:51:32 +0100

Modern high rate radio’s have sub-miliseconds delay.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 16:54:24 +0100

> Sorry for the delay, I was out of office yesterday.

Cookies with expiration timers?
Doesn’t add much security. Maybe useful for sanity check. Let's use the MAC address as cookie.

I prefer real security, e.g. RFC 6622 or TLS. And access lists.

Let’s permit new usage scenario’s, where TCP connections are set up multiple hops away. E.g. from management station or PCE node.

> connecting to?)  This could be extended to a full signature TLV

Let’s do this right now. We can reuse existing security mechanisms, with some details how to implement.

> destination for more complex topologies.

Router can set up the TCP connection, if it knows the Modem IP address. Let’s keep the modem a somewhat dummy device.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:58:10 +0000

DLEP peers MUST terminate a session (or note an error and declare a message malformed) if any MANDATORY TLVs are *missing* from a message. 

As to the specific metrics case: 

Assume that a modem has delivered the 4 MANDATORY TLVs during DLEP peer session initialization. 
Now assume that a "Destination Update" is presented to the router containing a "new" (unannounced) metric TLV.

What is the router to do?

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:00:47 +0000

> I know we aren't touching per-flow-metrics, but one day someone will, and finding extra length bits is a complete pain (The ForCES WG are suffering it right now)

That works for me.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:01:30 +0100

New generation military radio’s I see have TCP servers already.
Old ones have SNMP and other type of servers.
All of this can run multiple sessions. I use multiple sessions. 

Teco

Op 12 nov. 2013, om 17:23 heeft Taylor, Rick <[email-masked]> het volgende geschreven:

>> in the

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:04:27 +0100

TCP 4-tupple is not enough to discard some form of blind TCP connect. There must be some sanity check.

Radio must protect itself against syn attack (no data, locked port).

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 19:05:57 +0100

Easiest way to protect yourself against most "long range" attacks is
to bind the TCP socket to an IPv6 linklocal address.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:06:54 +0100

???

Again, modern 802.11 alike radio’s have delays far below 1ms.
There is better gear around. Non blocking 1GE radios are not rare these days.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:17:38 +0100

> DLEP peers MUST terminate a session (or note an error and declare a message malformed) if any MANDATORY TLVs are *missing* from a message. 

Yes.

> What is the router to do?

This is not about TLVs it doesn't 'understand' but about invalid operation of the peer.

First, the router issues a bug record in vendors tracking system ;-)
Then, it makes the exception. That’s why it is a SHOULD.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:30:23 +0100

> to bind the TCP socket to an IPv6 linklocal address.

There is traffic with IPv6 link local address on the Internet.

Sent packets with IPv6 link local address should have hopcount=1. Doesn’t completely take away the problem. TTL=255 filter on incoming traffic is stronger (GTSM, RFC 5082). 
Use GTSM filter and IPv6 link-local addresses by default?

Rick and I came up with the idea DLEP can be used between peers multiple hops away. Modem may have an option allowing it. 

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 19:35:47 +0100

So we can agree on 32 Bit Latency in MICROseconds?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 19:36:36 +0100

I think most operation systems do not forward linklocal IPv6 addresses...

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:40:24 +0000

Henning, 

I agree, I don't think most networks forward IPv6 link-locals. But, once you consider the problem of allowing multi-hop connectivity, you've got the issue of defending against SYN attacks, etc. IMO, that is yet another reason for putting the TCP server functionality into the *router*, not the modem. The burden on the poor, supposedly resource-constrained modem just gets bigger, and bigger, and bigger…

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 19:42:40 +0100

If you consider multi-hop connectivity, maybe using a VPN-Box might be
a good idea... let the radio believe its single hop and outsource the
security. ;)

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:46:27 +0000

Fair point. Use of TLS would also help. But I don't think any of that defends against a SYN flood….  that requires things like a tight rein on listen depth, etc.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 19:47:39 +0100

I don't think defending against spoofed IP packets, Syn-Floods or just
DDOS should be part of DLEP.

We have other layers for this.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:54:11 +0100

Op 12 nov. 2013, om 17:56 heeft Duke, Martin <[email-masked]> het volgende geschreven:

> Teco,
> 
> It seems like there are two competing proposals for session initialization. Yours:
> 
> And Stan's:
> ======================================================
> <------------------------ Peer Discovery     Modem initiates discovery via MCAST UDP.
> Peer Offer    -------------------------->     Response to discovery, basically an "I'm here"
>                                              response. Contains TCP address/port for                                                                                        							subsequent connection.
> <------------------------- TCP SYN
> TCP SYN ACK ----------------------->
> <------------------------- ACK         (Standard TCP 3-way handshake)
> <-------------------------- Peer Initialization (New message). The Peer Init message contains, for example, all of the MANDATORY metric TLVs that the modem supports. It's a way to get the DLEP control session initialized.
> 
> ... and I suppose Stan, if he was finishing the example, would need two additional messages to complete session negotiation.
> 
> A bunch of comments:
> 1) Stan's stated purpose to flip the SYN is to put the server implementation at the router. Frankly that's good enough for me unless Teco has counter-arguments.

This blocks couple of scenario’s (the router multiple hops away, multiple routers). Also it looks not natural to me, the modem has information, to be shared with router.
Again, most modems I have already run multiple TCP servers. Some of these servers are DLEP-alike. Full featured http server doesn’t need more than 200k code size, few MB RAM.

> 2) Given #1, I agree with Stan the Peer Offer has to come outside the TCP connection to provide the port number.

That’s why I think it is not natural. It needs another message (or part of negotiation with UDP multicast, other part in the TCP connection. Hmm.

> 3) I'm not particularly convinced that we have to strip all the TLVs and whatnot out of the Peer Discovery/Peer Offer messages and put them in a new Peer Initialization exchange. It's a small thing either way, but I'm in favor of having fewer messages if we can afford it, and refusing sessions prior to a TCP handshake if we can do it.

Do you think we have to deal with incompatibility a lot? Worries me.

Yes, let’s make the session setup simple. I don’t like broadcast large packets. So Peer advertisement should be a somewhat small packet, with identification and data for connection setup. Then the initialization packets follow, with three-way handshake. Full set of TLVs could span multiple IP packets and I rather stay away from multicast fragments. Reasonable, I think.

Teco

> Sent: Tuesday, November 12, 2013 8:33 AM
> To: Duke, Martin
>>>>>>>> message. TNO accepts no liability for the content of this 
>>>>>>>> e-mail, for the manner in which you use it and for damage of any 
>>>>>>>> kind resulting from the risks inherent to the electronic transmission of messages.
>>>>>>> 
>>>>>>> 
>>>>>>>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:54:17 +0000

That's fair. Also not what I was driving at, so my apologies. It goes back to my contention that TCP server code is "arguably more complex" than client code, and therefore, we should endeavor to put the TCP client code in the modem.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 19:59:20 +0100

Op 12 nov. 2013, om 19:36 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> I think most operation systems do not forward linklocal IPv6 addresses…

Questionable. Link local destination: you might be right.  Link local source: what about ICMP from router without global address? It MUST send ICMP packets, it has no choice other then use link local source address. That’s why it would be permitted.

Reported link local packets were TCP to well known search engine. They see odd things…

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Nov 2013 20:00:43 +0100

How will you get a reply if you use a linklocal source IP?

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:01:33 +0000

On Nov 12, 2013, at 1:54 PM, Teco Boot <[email-masked]>
 wrote:

> This blocks couple of scenario’s (the router multiple hops away, multiple routers).

Perhaps I'm missing something, but I don't see how flipping the TCP server to the router blocks any multi-hop scenarios, or blocks multiple routers. In the case where the router is issuing the MCAST Peer Discovery/Peer Advertisement, the modem will receive multiple packets. In the original case above, the modem issues Peer Discovery, and gets multiple responses. It (the modem) can then issue multiple connects to all routers that respond, or pick & choose. which router (or routers) to connect to.

Stan

> Also it looks not natural to me, the modem has information, to be shared with router.

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 20:05:35 +0100

Access list on modem is needed if not on trusted network.
(all networks are less trusted these days…)

Stan: you have received from multiple sources that modem may have more CPU power and memory than the router. Elect TCP server based on clock speed & memory footprint? As a router vendor, why not taking the easy part?

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:24:39 +0000

> Stan: you have received from multiple sources that modem may have more CPU power and memory than the router. Elect TCP server based on clock speed & memory footprint? As a router vendor, why not ta…

First - Finally, text (even if implicit) agreeing with the notion that TCP servers are harder than TCP clients. 

Second - I'm not comfortable with the router "taking the easy part" because I've talked with radio vendors who expressed concerns with complexity of implementation. Unfortunately, those discussions were private, and I cannot divulge the specific vendors without their approval. I've asked, but have not received approval as of this writing. I understand the skepticism of this type of information in an open forum like the IETF, but as I said in an earlier email - While the DT has smart people who have worked with wireless devices in networks, we do not have anyone (nor is there anyone I know if participating in the working group) that actually produces radio products for a living. The lack of that perspective concerns me when we make radio implementations "harder" - I'm concerned that the additional complexity adds to any perceived "barrier to implement". That's why I think the DT (myself included) should touch base with contacts we have in the radio industry and ask the question. If the consensus opinion from vendors we contact is "TCP server, TCP client, we don't care", then I'll yield - The modem acting as TCP server looks "unnatural" to me, but I'll go with rough consensus, provided we have some indication the radio vendors won't poo-poo it en-masse. 

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 12 Nov 2013 19:59:06 +0000

Teco, 

> Stan: you have received from multiple sources that modem may have more CPU power and memory than the router. Elect TCP server based on clock speed & memory footprint? As a router vendor, why not ta…

One additional thought on this topic. In an earlier email on this same thread, you said (in part):
"...Let’s keep the modem a somewhat dummy device."

I 100% agree with that approach. It's part of what drives me to put "harder" code (like being a TCP server) into the router, not the modem. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 21:23:28 +0100

Don’t try to understand attackers…
ICMP errors do not require a response.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 21:54:39 +0100

Op 12 nov. 2013, om 20:01 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> Perhaps I'm missing something, but I don't see how flipping the TCP server to the router blocks any multi-hop scenarios, or blocks multiple routers.

I had a management or route server in mind, acting as "router". This server decides which and when devices are polled. This needs TCP server at modem, I guess.

> In the case where the router is issuing the MCAST Peer Discovery/Peer Advertisement, the modem will receive multiple packets. In the original case above, the modem issues Peer Discovery, and gets multiple responses. It (the modem) can then issue multiple connects to all routers that respond, or pick & choose. which router (or routers) to connect to.

You are right, at cost of an addition message and more state.

So we agree routers are passive listeners and modem advertise themselves?

Can we allow the DLEP TCP server at modem and define the TCP client starts the DLEP three-way initialize handshake? Then, on link you have the TCP server at router (more lightweight at modem), I have the option to set up the TCP connection to the modem from anywhere at anytime in the network?

We better wait on outcome what your modem vendors will come up with. I would be disappointed if they cannot support a TCP server. Mainly because they underestimate themselves and we have to deal with a more complex protocol. I want a public announcement here.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 21:58:22 +0100

> First - Finally, text (even if implicit) agreeing with the notion that TCP servers are harder than TCP clients. 

Did I say the opposite?
What I say is that TCP servers are on modems I have.

> Second - I'm not comfortable with the router "taking the easy part" because I've talked with radio vendors who expressed concerns with complexity of implementation. Unfortunately, those discussions…

OK, I’ll wait and see.

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 12 Nov 2013 22:07:52 +0100

> I 100% agree with that approach. It's part of what drives me to put "harder" code (like being a TCP server) into the router, not the modem. 

I think we both agree there would be little or no configuration on the modem. It is the plug&play device, with IP autoconfig, IPv4 DHCP and / or IPv6 SLAAC.

Again, I don’t know why you think it is hard to implement a TCP server, while stuff I have to deal with has it implemented. 

Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 12 Nov 2013 14:28:21 -0800

Stan,

I have not followed the detailed discussion closely enough to say whether
it is a good idea to put the Resources TLV in another draft or not, but I
have to agree with Teco that your argument is not a good one. If the
intention of DLEP is to document Cisco's current implementation, then there
is the option of sending a draft as independent submission directly to the
RFC Editor ("Company Foo's Protocol"). If, however, the intent is to
produce a document that has IETF consensus, then resisting change solely
because of the necessity to modify an existing implementation is not a
strong argument IMO.

Regards
Ulrich

On Mon, Nov 11, 2013 at 10:04 AM, Teco Boot <[email-masked]> wrote:

>
> Op 11 nov. 2013, om 18:33 heeft Stan Ratliff (sratliff) <
> [email-masked]> het volgende geschreven:
>
> > Teco,
> >
> that you have an implementation. My company has sold units, and has them in
> the field, interoperating with other company's products. Stripping the

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 08:12:39 +0100

> I'm also going to MILCOM next week; I'll be working with some of the guys from Persistent Systems (radio vendor; they have a DLEP implementation). I'll ask them about the TCP server vs. client issu…

If they have some objections, can you ask difference between complexity of implementing a simple DLEP TCP server and for example a HTTPS or DHCP server?

Their quad radio router has multiple ethernet ports, can you ask why they would prefer a limit, to connect only a single router?

Maybe they should join our DT, I know them as smart guys. Anyway, say hello to them from the Netherlands. I wish them well. 

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 10:12:03 +0000

My thoughts:

The principle of keeping the modem code as small and light as possible is good.  In general modems are not only getting bigger and smarter, they are also getting physically smaller and lower power.  Routers however are not getting so small so quickly, so even though there are full TCP stacks in many radios, we should not force a full server implementation on them.

So, Lets keep the 3-way handshake we have discussed, but make the router the advertiser/server:

   Router                                        Modem

1) TCP Listen()

2) UDP Peer_Discovery ------------------------------->
     + Version TLV
     + TCP address:port

3)                                       TCP Connect()

4) <-------------------------------- Peer_Initialize()
                                      + Version TLV
                                      + Ident TLV
                                      + Mandatory TLVs

5) Peer_Initialize_Ack ------------------------------>
     + Status TLV
     + Ident TLV

I withdraw my suggestion about cookies.  As Teco has pointed out, just do security properly (TLS or IPSec or whatever).  Putting in a lightweight/half-baked authentication process in the protocol may lead some implementers to assume this provides security.

I have also suggested just Version TLV and TCP endpoint address in the UDP discovery packet to save space.  This should allow a listening modem to decide whether to start a session with a router before TCP connect.

At step 5, the router has the opportunity to send a negative ACK, by including an error Status TLV in the Peer_Inialize_Ack and then shutdown the connection.  This captures Teco's SHOULD condition "The router SHOULD NOT start a session with a modem that does not advertise mandatory metric TLVs"

Would it help to have a state machine in the draft?

Comments?

Rick Taylor

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 10:13:32 +0000

+1

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 Nov 2013 11:19:07 +0100

I think we can even leave out the TCP address (and maybe even the
port) by just demanding that the UDP Peer_Discovery has to come from
the relevant address (and port) of the TCP socket.

I cannot see an use case for using a different source port/address for
the UDP Peer_Discovery at the moment.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 10:18:44 +0000

I'll stop top-posting...

> Op 12 nov. 2013, om 18:58 heeft Stan Ratliff (sratliff)
> > DLEP peers MUST terminate a session (or note an error and declare a
> message malformed) if any MANDATORY TLVs are *missing* from a message.
>
> Yes.

+1

> > Now assume that a "Destination Update" is presented to the router
> containing a "new" (unannounced) metric TLV.
> >
> Then, it makes the exception. That's why it is a SHOULD.

I think the draft needs to define an 'invalid operation' and what should be done (terminate session with Status TLV and TCP shutdown).  Then in various places in the draft, one can say "Not doing this is an invalid operation (See section X.Y)"

This should make it explicit for implementers, and we can try to spot these corner cases as we develop interoperable implementations ;)

Rick

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 10:24:45 +0000

Gah!

I just noticed that Teco, Martin and Stan have argued the complete opposite in the thread: "notes DLEP meeting @ IETF88"

Anyone want to try to combine this?

Rick

P.S> Martin, are you posting to the list? I'm only seeing your mails in Teco and Stan's replies.  Of course that might be my mailserver.
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 13 Nov 2013 12:14:57 +0000

Just to add my two pennyworth.

We need to agree that the operating scenario is one router and N modems. If we do need to move to more than one router and N modems, the situation is more complex in terms of who does the TCP serving. Can we agree that please?

Also, given the resistance we seem to be experiencing from modem manufacturers to get involved, I would want to give them the least complex half of the implementation. This means they will not have to upgrade hardware, TCP stacks and/or operating systems beyond that which is necessary. I would suggest that we want the modem manufacturers to add value in extracting relevant metrics from the modem and pass through DLEP to the router or other interested process, rather than insisting they upgrade their TCP stacks.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 13 November 2013 10:19
To: Taylor, Rick
Cc: DLEP Research Group ([email-masked]); Teco Boot; Stan Ratliff
Subject: Re: [manet-dlep-rg] DLEP session establishment

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 Nov 2013 13:26:08 +0100

I think this "complexity issue" is a null-argument.

IP capable radios/modems are complex devices, most of them have HTTP
based user interfaces, SNMP services and complete software stack.
Providing a TCP server socket is trivial for them and is not an
additional complexity.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 Nov 2013 14:06:58 +0100

I talked with a co-worker from our SDR department.

He said that most SDRs he works with have mid- to high-end ARM/MIPS
CPUs for handhelds and even more powerful ones for vehicle based SDRs.

These devices already have the necessary libraries on board to open
tcp server sockets for other purposes, software complexity for opening
the socket should be no real issue.

The other target platform I have in mind for DLEP are cheap embedded
routers that are converted into DLEP-capable radios with a special
firmware. They also have a full IP stack already present, a TCP server
socket is a non-issue with them either.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 15:21:56 +0000

Having recently spoken to a radio vendor, they too run a serious amount of services on their hardware, including a full linux routing stack, so being a server is no issue.

However, I still think the router is the correct device to be the server simply from the 1 to many relationship between router and modems.  One router has multiple simultaneous sessions with modems.  Modems have only one conversation with a router at once, this seems to match the router being the server and the modem calling connect().

Rick Taylor

> Sent: 13 November 2013 13:07
> To: Stan Ratliff (sratliff)
> Cc: DLEP Research Group ([email-masked]); Teco Boot
> >> (all networks are less trusted these days...)
> >>
> >> Stan: you have received from multiple sources that modem may have more
> CPU power and memory than the router. Elect TCP server based on clock
> speed & memory footprint? As a router vendor, why not taking the easy
> part?
> >
> > "...Let's keep the modem a somewhat dummy device."
> >
> > I 100% agree with that approach. It's part of what drives me to put
> "harder" code (like being a TCP server) into the router, not the modem.
> >
> > Stan
> >
> >
> >>
> >> Teco
> >>
> >> Op 12 nov. 2013, om 19:54 heeft Stan Ratliff (sratliff)
> >>> That's fair. Also not what I was driving at, so my apologies. It goes
> back to my contention that TCP server code is "arguably more complex" than
> client code, and therefore, we should endeavor to put the TCP client code
> in the modem.
> >>>
> >>> Regards,
> >>> Stan
> >>>
> >>>>> Fair point. Use of TLS would also help. But I don't think any of
> that defends against a SYN flood....  that requires things like a tight rein
> on listen depth, etc.
> >>>>>
> >>>>> Regards,
> >>>>> Stan
> >>>>>
> >>>>>>> I agree, I don't think most networks forward IPv6 link-locals.
> But, once you consider the problem of allowing multi-hop connectivity,
> you've got the issue of defending against SYN attacks, etc. IMO, that is
> yet another reason for putting the TCP server functionality into the
> *router*, not the modem. The burden on the poor, supposedly resource-
> constrained modem just gets bigger, and bigger, and bigger...
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Stan
> >>>>>>>
> >>>>>>>>> Op 12 nov. 2013, om 19:05 heeft Henning Rogge
> <[email-masked]> het volgende geschreven:
> >>>>>>>>>
> >>>>>>>>> Sent packets with IPv6 link local address should have
> hopcount=1. Doesn't completely take away the problem. TTL=255 filter on
> incoming traffic is stronger (GTSM, RFC 5082).
> >>>>>>>>> Rick and I came up with the idea DLEP can be used between peers
> multiple hops away. Modem may have an option allowing it.
> >>>>>>>>>
> >>>>>>>>> Teco
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Henning Rogge
> >>>>>>>>>>
> >>>>>>>>>>> TCP 4-tupple is not enough to discard some form of blind TCP
> connect. There must be some sanity check.
> >>>>>>>>>>>
> >>>>>>>>>>> Op 12 nov. 2013, om 17:21 heeft Taylor, Rick
> <[email-masked]> het volgende geschreven:
> >>>>>>>>>>>
> >>>>>>>>>>>> I seem to remember SCTP (which I hold in high regard) uses a
> cookie for its 4-way handshake on the grounds that it stops some types of
> spoofing attacks.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'll re-read their rationale doc if I can find it.  I was
> just trying to cover some security considerations here, but it might be
> misplaced.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I just wonder whether replying to a broadcast with a IP
> address by blindly connecting to it without some way of checking what your
> connecting to is what you expect to be there is 'unsafe' - but you do make
> a good point about the TCP 4-tuple...
> >>>>>>>>>>>>
> >>>>>>>>>>>> Rick Taylor
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Nov 12, 2013, at 10:45 AM, "Taylor, Rick"
> >>>>>>>>>>>>>>> (probably more) constrained modem device. So, what if we
> make the
> >>>>>>>>>>>>> *router*
> >>>>>>>>>>>>>>> contain the unicast IP address/port for the TCP listener.
> The modem
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>>> On Nov 12, 2013, at 7:47 AM, "Taylor, Rick"
> >>>>>>>>>>>>>>>>>>                            <------------------------
> Peer
> >>>>>>>>>>>>>>>>> Discovery Message
> >>>>>>>>>>>>>>>>> Why not TCP connect from router to modem? Makes more
> sense to me, the
> >>>>>>>>>>>>>>>>> modem is the peer offering a service.
> >>>>>>>>>>>>>>>>>>                           <-------------------------
> Peer
> >>>>>>>>>>>>>>>>> Initialization containing
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> disconnect when modem modem is not willing to accept
> first message
> >>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>> router.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Teco
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> this e-mail is private and in addition may include
> commercially
> >>>>>>>>>>>>> sensitive
> >>>>>>>>>>>>>>> within this e-mail or attached files, please contact the
> sender prior
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> disclosure, copying or distribution is prohibited. Please
> also contact
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> sender and inform them of the error and delete the e-mail,
> including
> >>>>>>>>>>>>> any
> >>>>>>>>>>>>>>> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10
> 8FZ Company
> >>>>>>>>>>>>> No:
> attached to
> attached to this e-mail is private and in addition may include
> commercially sensitive information. The contents of this e-mail are for
> the intended recipient only and therefore if you wish to disclose the
> information contained within this e-mail or attached files, please contact
> the sender prior to any such disclosure. If you are not the intended
> recipient, any disclosure, copying or distribution is prohibited. Please
> also contact the sender and inform them of the error and delete the e-
> mail, including any attached files from your system. Cassidian Limited,
> Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport,
> NP10 8FZ Company No: 04191036 http://www.cassidian.com
> last to
> last to

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 16:25:38 +0100

> the UDP Peer_Discovery at the moment.

We cannot prohibit. We can say it is not the standard.
(some use port 8080 etc).

I have no objections against having the TCP server port in Peer_Discovery. 
But if our goal is a simple implementation, we better take it out.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:28:38 +0000

> Their quad radio router has multiple ethernet ports, can you ask why they would prefer a limit, to connect only a single router?

Taking on the role of a TCP client doesn't have anything to do with connecting to multiple routers. If it did, then I would have argued that the router MUST be the TCP server, as it MUST have the capability of connecting to multiple radios….

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:30:44 +0000

I'm on board with this. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 16:32:21 +0100

> We need to agree that the operating scenario is one router and N modems. If we do need to move to more than one router and N modems, the situation is more complex in terms of who does the TCP servi…

No, lets support multiple routers. Even persistent dismount radio’s have two ethernet ports.

> Also, given the resistance we seem to be experiencing from modem manufacturers to get involved, I would want to give them the least complex half of the implementation. This means they will not have…

Just had discussion with modem vendor (or the one that makes technology available for modem vendors). Today’s hardware and operating systems can easily run a TCP server. The overall complexity is whats matters. Getting state out of the modem is important. Here, TCP helps, it takes care of reliable and in order transfer of messages.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 16:37:58 +0100

> Providing a TCP server socket is trivial for them and is not an

+1
Verified by team member.

He had concerns on this DLEP effort, all of this can be done with SNMP, he said. He is an expert on using SNMP on  somewhat historic devices. He has no doubt the radio can support TCP servers and would be amazed if a radio vendor would not be willing to implement a TCP server.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:40:19 +0000

Ulrich,

That's fair enough. And if I were arguing for making Resources a MANDATORY TLV, I'd be appropriately chastened… ;-)

But all I'm saying is that Resources becomes the "worked example" of an OPTIONAL metric TLV. If someone doesn't like it, they won't use it.

Stan

On Nov 12, 2013, at 5:28 PM, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:

Stan,

I have not followed the detailed discussion closely enough to say whether it is a good idea to put the Resources TLV in another draft or not, but I have to agree with Teco that your argument is not a good one. If the intention of DLEP is to document Cisco's current implementation, then there is the option of sending a draft as independent submission directly to the RFC Editor ("Company Foo's Protocol"). If, however, the intent is to produce a document that has IETF consensus, then resisting change solely because of the necessity to modify an existing implementation is not a strong argument IMO.

Regards
Ulrich

On Mon, Nov 11, 2013 at 10:04 AM, Teco Boot <[email-masked]<mailto:[email-masked]>> wrote:

Agreed.

There is no deadlock.

Teco

_______________________________________________
manet-dlep-rg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet-dlep-rg

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 13 Nov 2013 07:42:35 -0800

Alright ;-) Just wanted to assure that there are technical arguments.

Regards
Ulrich

On Wed, Nov 13, 2013 at 7:40 AM, Stan Ratliff (sratliff) <[email-masked]

>  Ulrich,
>
>  That's fair enough. And if I were arguing for making Resources a
> MANDATORY TLV, I'd be appropriately chastened… ;-)
>
>  But all I'm saying is that Resources becomes the "worked example" of an
> OPTIONAL metric TLV. If someone doesn't like it, they won't use it.
>
>  Stan
>
>  On Nov 12, 2013, at 5:28 PM, Ulrich Herberg <[email-masked]> wrote:
>
>  Stan,
>
>> > I'm opposed to putting Resources in yet another draft. Yes, I
>> understand that you have an implementation. My company has sold units, and
>> has them in the field, interoperating with other company's products.
>> Stripping the Resources TLV makes them non-compliant. IMHO, that's not an
>> option.
>>

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 16:42:37 +0100

> However, I still think the router is the correct device to be the server simply from the 1 to many relationship between router and modems.  One router has multiple simultaneous sessions with modems…

Maybe it is you as vendor of this single router.
I’m the network designer, that builds networks that are adaptive. I hate limitations build in into protocols disallowing services of my modems.

Another reason: current proprietary protocols don’t have this limitation. So the restriction actually limits adaption of DLEP.

Teco

>> commercially sensitive
>> sender prior to
>> also contact the
>> including any
>> 8FZ Company No:

---

From: "Dowdell, John" <[email-masked]>
Date: Wed, 13 Nov 2013 15:54:38 +0000

Teco, Henning, thanks for confirming that. I'm happy to withdraw my viewpoint on both counts.

John

+1
Verified by team member.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:55:59 +0000

> I’m the network designer, that builds networks that are adaptive. I hate limitations build in into protocols disallowing services of my modems.

I don't see this discussion as building in limitations or disallowing services…. and if so, then I would argue that putting the TCP server code into the modem would then build limitations (and/or disallow services) *from the router*. 

So what, exactly, are the use cases and technical reasons for hosting the TCP server at the modem? 

Stan

> Another reason: current proprietary protocols don’t have this limitation. So the restriction actually limits adaption of DLEP.

I don't understand this either. Any protocol that is TCP based has to have a TCP server and a TCP client. Do you mean that the current proprietary protocols are not TCP based? That would imply to me that perhaps the DT decision to go to TCP in the first place was ill-conceived (after all, there was a bit of working group angst when that was announced). 

Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 17:07:51 +0100

This could work.

It removes the additional multicast message, and state. 
The Peer_Discovery is some kind of ignition packet. Could be send with link local multicast every now and then (say, every 5 seconds), to discover recently connected devices (Ethernet port state is not reliable here). A remote server could send the Peer_Discovery packet with its global unicast address. Then, the modem will set up the TCP connection.

Sending the multicast from router to modem (and having the TCP server on router) adds some complexity on the modem, in that this multicast packet shall not be forwarded over the modem link (e.g. RF path). Cannot be done with L2 MAC filter, as this would block a set of multicast addresses. The filter has to block the assigned IANA DLEP multicast address. 
LLDP better fits our requirement for discovery. It doesn’t take away the need for the multicast Peer_Discovery. On the other hand, LLDP is not widely implemented, I think. And would be bridged on modems that doesn’t support it.

On 2: Ident TLV could be included here (e.g. for logging). Port would be removed. Maybe add mandatory authentication TLV (with as default a blank password, this helps getting it implemented). TCP address is in header.

On 4: ALL supported TLVs are send, not only the mandatory.

On 5: Add all supported TLVs? Remove Ident when sent on 2?

Add a 6, with Peer_Initialize_Ack from modem to router? This gives the modem a change to terminate the session before it was active.

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 16:10:12 +0000

I'd like to use Resources as a 'worked example' of an Extension metric TLV.

Only because I think it is a 'wishy-washy' metric that I don't want to see creep in as a core metric.

If Stan has uses for it, then Stan can specify it as a requirement for his use-cases, or we can firm up the definition.  Either/or as far as I'm concerned, but as it currently stands I don't want to see it as a core metric, optional or not.

Sorry!

Rick Taylor

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: 13 November 2013 15:40
To: Ulrich Herberg
Cc: DLEP Research Group ([email-masked]); Teco Boot
Subject: Re: [manet-dlep-rg] Resources TLV

Ulrich,

That's fair enough. And if I were arguing for making Resources a MANDATORY TLV, I'd be appropriately chastened... ;-)

Stan

Stan,

Agreed.

There is no deadlock.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 17:13:43 +0100

> So what, exactly, are the use cases and technical reasons for hosting the TCP server at the modem? 

Two items here:
a) 1 to many relationship between router and modems
b) TCP server at the modem

On a) I reject this limitation

On b) I don’t prefer a more complex protocol for making life more easy for modem vendors.

The proposal from Rich is a way out on b.

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 16:23:12 +0000

> Op 13 nov. 2013, om 16:55 heeft Stan Ratliff (sratliff)
> >> Op 13 nov. 2013, om 16:21 heeft Taylor, Rick
> >>> Having recently spoken to a radio vendor, they too run a serious
> amount of services on their hardware, including a full linux routing
> stack, so being a server is no issue.
> >>>
> >>> However, I still think the router is the correct device to be the
> server simply from the 1 to many relationship between router and modems.
> One router has multiple simultaneous sessions with modems.  Modems have
> only one conversation with a router at once, this seems to match the
> router being the server and the modem calling connect().
> >>
> >> I'm the network designer, that builds networks that are adaptive. I
> hate limitations build in into protocols disallowing services of my
> modems.
> >
> > I don't see this discussion as building in limitations or disallowing
> services.... and if so, then I would argue that putting the TCP server code
> into the modem would then build limitations (and/or disallow services)
> *from the router*.
> >

That's okay, I wasn't suggesting it as a limitation, but I still believe that there is an M to N relationship between Routers and Modems, where M <= N.

>
> On b) I don't prefer a more complex protocol for making life more easy for
> modem vendors.
>

I'm proposing b) purely to reduce complexity of implementation

Rick

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:27:42 +0000

> On a) I reject this limitation

I don't want the limitation either. Putting the TCP server at the router doesn't cause that limitation. 

> The proposal from Rich is a way out on b.

Subjective. I don't see Rick's proposal as complex. I see it as making sense. Also, having the "world's greatest IETF specification" is meaningless if no radio vendors actually implement it. I'd prefer tradeoffs that actually entice vendors to implement. 

Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 13 Nov 2013 16:37:59 +0000

> Subject: Re: [manet-dlep-rg] DLEP session establishment

Excellent, I see consensus approaching... ;)

> The Peer_Discovery is some kind of ignition packet. Could be send with
> link local multicast every now and then (say, every 5 seconds), to
> discover recently connected devices (Ethernet port state is not reliable
> here). A remote server could send the Peer_Discovery packet with its
> global unicast address. Then, the modem will set up the TCP connection.

Yes, just what I thought.

>
> Sending the multicast from router to modem (and having the TCP server on
> router) adds some complexity on the modem, in that this multicast packet
> shall not be forwarded over the modem link (e.g. RF path). Cannot be done
> with L2 MAC filter, as this would block a set of multicast addresses. The
> filter has to block the assigned IANA DLEP multicast address.
> LLDP better fits our requirement for discovery. It doesn't take away the
> need for the multicast Peer_Discovery. On the other hand, LLDP is not
> widely implemented, I think. And would be bridged on modems that doesn't
> support it.

I agree, but I imagined Peer_Discovery being link-local multicast/broadcast.  You are right that a multi-hop scoped multicast is a nightmare.

And yes, perhaps we should be using mDNS/Bonjour for discovery rather than re-inventing the wheel here.

Should we put in some text: "Unless there is an alternative discovery protocol in use, such as a-priori static configuration or mDNS, then Peer_Discovery messages SHOULD be sent every X seconds to the link-local multicast address"

>
>
> On 2: Ident TLV could be included here (e.g. for logging). Port would be
> removed. Maybe add mandatory authentication TLV (with as default a blank
> password, this helps getting it implemented). TCP address is in header.

I disagree.  Ident is only needed when the TCP connection is made, and it keeps the UDP packet size down by not including it.  Implementations shouldn't log Discovery packets, they will be constantly bouncing around.

> On 4: ALL supported TLVs are send, not only the mandatory.

Yes, I stand corrected.

> On 5: Add all supported TLVs? Remove Ident when sent on 2?

Why does the router advertise it's supported TLVs?  I thought we had agreed that the router should ignore any TLVs it doesn't understand, and we haven't yet discussed the router 'demanding' TLV support from the modem.

>
> Add a 6, with Peer_Initialize_Ack from modem to router? This gives the
> modem a change to terminate the session before it was active.

Not sure it is needed, unless the Router can change the 'parameters' of the session in its ACK, the modem already knows everything it wants to know, so we can avoid an extra step.

Rick

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 17:46:38 +0100

> That's okay, I wasn't suggesting it as a limitation, but I still believe that there is an M to N relationship between Routers and Modems, where M <= N.

Why?

If I have a PS radio with two interfaces, buy another radio just for M <= N?
:-)

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 18:43:30 +0100

> P.S> Martin, are you posting to the list? I'm only seeing your mails in Teco and Stan's replies.  Of course that might be my mailserver.

Bit a housekeeping: I wonder Martin received this mail. None of his mails made it into the archive.
@Stan or Joe/Ulrich: can you check Martin is with us?

Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 13 Nov 2013 09:50:38 -0800

I don't have administrative access to the list, so I cannot check whether
he is added.
Ulrich

On Wed, Nov 13, 2013 at 9:43 AM, Teco Boot <[email-masked]> wrote:

> > P.S> Martin, are you posting to the list? I'm only seeing your mails in
> Teco and Stan's replies.  Of course that might be my mailserver.
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 18:16:14 +0000

I've added [email-masked] to the DT list. Any email from the "@boeing.com" address won't make it in, however. 

Stan

On Nov 13, 2013, at 12:45 PM, "Duke, Martin" <[email-masked]> wrote:

> I am not actually a member of the list, because I'm actually signing off the supporting project soon.
> 
> That said, I've acquired a personal interest in this project, so I would be grateful if you could add [email-masked] to the list, so I can continue to participate on my own time after this week.
> 
> Sent: Wednesday, November 13, 2013 9:44 AM
> To: Duke, Martin; Stan Ratliff
> Subject: manet-dlep-rg: Martin's membership 
>

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 19:31:02 +0100

Changed subject.

> I agree, but I imagined Peer_Discovery being link-local multicast/broadcast.  You are right that a multi-hop scoped multicast is a nightmare.

Link-local is not sufficient. We need L2-link-local multicast address. We have to go to IEEE802 to allocate such. Even then, it takes ages to get it implemented.

The best we can do is specify the modem MUST NOT forward the DLEP link-local multicast packets to the link to the remote nodes. If the modem has an ethernet bridge function (as devices I have), this DLEP link-local multicast filter MUST NOT be implemented on the ethernet ports.

I’m still puzzled how it can work with cascaded devices, for example to connect a satcom system somewhere further away from the router using an Ethernet extender. Maybe use DLEP link-local for the local attached device and configure something on router (keep the satcom modem a dummy device) to reach the satcom modem with a unicast Peer_Discovery.

> And yes, perhaps we should be using mDNS/Bonjour for discovery rather than re-inventing the wheel here.

Not these ones. These shall be forwarded to remote nodes, to keep existing stuff going.

> 
> Should we put in some text: "Unless there is an alternative discovery protocol in use, such as a-priori static configuration or mDNS, then Peer_Discovery messages SHOULD be sent every X seconds to the link-local multicast address”

Or:
The Router SHOULD send Peer_Discovery messages every Peer_Discovery_Interval seconds to the DLEP assigned link-local multicast address on DLEP enabled interfaces. Alternative mechanism may be used, such as a-priori static configuration or alternative discovery protocol.
The Modem initiates a DLEP TCP connection on reception and successful validation of a DLEP Peer_Discovery message, either received with a DLEP assigned link-local multicast address or on a Modem configured unicast address.

This unicast Peer_Discovery packet is a disadvantage of having TCP server on the router. If one finds an improvement, I’m all ears.

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Mon, 11 Nov 2013 15:30:35 +0000

Teco,

Martin

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Friday, November 08, 2013 10:59 PM
To: Duke, Martin
Cc: DLEP Research Group ([email-masked])
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Mon, 11 Nov 2013 16:33:23 +0000

Teco,

Martin

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 7:48 AM
To: Duke, Martin
Cc: [email-masked]
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Mon, 11 Nov 2013 18:48:38 +0000

-----Original Message-----
From: Teco Boot [mailto:[email-masked]]
Sent: Monday, November 11, 2013 10:31 AM
To: Duke, Martin
Cc: [email-masked]
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Mon, 11 Nov 2013 21:45:16 +0000

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 1:39 PM
To: Duke, Martin
Cc: [email-masked]
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 12 Nov 2013 16:04:19 +0000

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 9:57 PM
To: Duke, Martin
Cc: [email-masked]
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 12 Nov 2013 16:56:47 +0000

Teco,

And Stan's:

A bunch of comments:

Martin

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 8:33 AM
To: Duke, Martin
Cc: [email-masked]
Subject: Re: notes DLEP meeting @ IETF88

Teco

---

From: "Duke, Martin" <[email-masked]>
Date: Wed, 13 Nov 2013 17:45:49 +0000

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 9:44 AM
To: Duke, Martin; Stan Ratliff
Cc: DLEP Research Group ([email-masked])
Subject: manet-dlep-rg: Martin's membership 

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 Nov 2013 20:45:33 +0100

Why should we need to ask IEEE? Just use the standard IP mac addresses
for the linklocal IPs.

The Modem can filter them based on IP content out of the bridge.
Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 20:08:33 +0000

+1. Henning's right; there's no need to go to the IEEE, IMO… 

Seems like the issue for us is how to scope discovery. Is it

(a) a single-hop operation, exploiting link-local MCAST, or 
(b) a potentially multi-hop operation, utilizing some sort of site-local or other MCAST technique/address?

I'm leaning to making it link-local (1-hop) myself. Note that does *NOT* preclude multi-hop DLEP operation over a TCP socket; it just means that multi-hop DLEP sessions would rely on a-priori configuration. There are *lots* of other issues that are going to confound, confuse, and otherwise screw-up multi-hop DLEP… ;-) Given the amount of characters typed over lesser issues, I don't know how far we want to go into multi-hop DLEP at this juncture. Suffice it to say my position is to write the spec in such a way as to avoid *precluding* it, but not to attempt to describe it. Multi-hop DLEP *can* work, given a careful network design (including a careful addressing policy). But I do not believe it will "generalize" down to something that warrants a section in the spec.  

Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 13 Nov 2013 21:12:26 +0100

And you can always either use a proxy to extend the reach of the
linklocal multicast or use a layer-2 VPN.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 22:01:06 +0100

> The Modem can filter them based on IP content out of the bridge.

Yes, this is the work-around. I think it is missing in dlep-04.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 22:03:31 +0100

> I'm leaning to making it link-local (1-hop) myself. Note that does *NOT* preclude multi-hop DLEP operation over a TCP socket; it just means that multi-hop DLEP sessions would rely on a-priori confi…

I think you mix up multi-hop L2 and multi-hop L3.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 13 Nov 2013 22:09:47 +0100

> linklocal multicast or use a layer-2 VPN.

Maybe stick to what we already have: 802.1D L2 (a.k.a. Ethernet) and L3 connections to Internet or private backbone.

Are you aware of L2 VPNs other than 802.1D that needs DLEP?

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 14 Nov 2013 10:11:45 +0000

> Subject: Re: [manet-dlep-rg] DLEP multicast address
>
> +1. Henning's right; there's no need to go to the IEEE, IMO...
>
> I'm leaning to making it link-local (1-hop) myself. Note that does *NOT*
> preclude multi-hop DLEP operation over a TCP socket; it just means that
> multi-hop DLEP sessions would rely on a-priori configuration. There are
> *lots* of other issues that are going to confound, confuse, and otherwise
> screw-up multi-hop DLEP... ;-) Given the amount of characters typed over
> lesser issues, I don't know how far we want to go into multi-hop DLEP at
> this juncture. Suffice it to say my position is to write the spec in such
> a way as to avoid *precluding* it, but not to attempt to describe it.
> Multi-hop DLEP *can* work, given a careful network design (including a
> careful addressing policy). But I do not believe it will "generalize" down
> to something that warrants a section in the spec.

This is a big +1 from me.

Yes, we should specify that link-local multicast SHOULD be used (sent by the router periodically) and not forwarded.

Yes, we should add some text to say "Other discovery methods may be used, but then you start the standard TCP part of DLEP session establishment"

Yes, we should not preclude multi-hop links between router and modem, but also we should not get caught up in defining it - the draft IMHO should define the 1-hop behaviour only.

(When I say 'we' - I mean Stan and the other authors, it's just easier than translating all sentences into the passive voice and using 'one' instead, which just makes my prose increasingly Shakespearean which is unkind on those for whom English is a second language - this sentence being a case in point)

Rick

> >> Op 13 nov. 2013, om 17:37 heeft Taylor, Rick
> >>> I agree, but I imagined Peer_Discovery being link-local
> multicast/broadcast.  You are right that a multi-hop scoped multicast is a
> nightmare.
> >>
> >> Link-local is not sufficient. We need L2-link-local multicast address.
> We have to go to IEEE802 to allocate such. Even then, it takes ages to get
> it implemented.
> >>
> >> The best we can do is specify the modem MUST NOT forward the DLEP link-
> local multicast packets to the link to the remote nodes. If the modem has
> an ethernet bridge function (as devices I have), this DLEP link-local
> multicast filter MUST NOT be implemented on the ethernet ports.
> >>
> >> I'm still puzzled how it can work with cascaded devices, for example to
> connect a satcom system somewhere further away from the router using an
> Ethernet extender. Maybe use DLEP link-local for the local attached device
> and configure something on router (keep the satcom modem a dummy device)
> to reach the satcom modem with a unicast Peer_Discovery.
> >>
> >>
> >>>
> >>> Should we put in some text: "Unless there is an alternative discovery
> protocol in use, such as a-priori static configuration or mDNS, then
> Peer_Discovery messages SHOULD be sent every X seconds to the link-local
> multicast address"
> >>
> >> Or:
> >> The Router SHOULD send Peer_Discovery messages every
> Peer_Discovery_Interval seconds to the DLEP assigned link-local multicast
> address on DLEP enabled interfaces. Alternative mechanism may be used,
> such as a-priori static configuration or alternative discovery protocol.
> >> The Modem initiates a DLEP TCP connection on reception and successful
> validation of a DLEP Peer_Discovery message, either received with a DLEP
> assigned link-local multicast address or on a Modem configured unicast
> address.
> >>
> >> This unicast Peer_Discovery packet is a disadvantage of having TCP
> server on the router. If one finds an improvement, I'm all ears.
> >>
> >>
> >> Teco
> >
> >
> >
> > --

---

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 14 Nov 2013 10:16:28 +0000

Martin,

I think the discussions passed like two ships in the night, but I believe we have now moved to peer discovery being a router-initiated process for exactly the reason you describe.

The router can keep strobing for interested modems, and modems can decide to connect to the advertising router if they wish.

If you check back through the archive, the recent thread called "DLEP session establishment" has the discussion.

Sorry, this list has gone quite mad since Vancouver, but I suppose that shows interest by the DT!

And thanks for taking a personal interest even if you are moving off your current project.

Cheers,

Rick

> [email-masked]] On Behalf Of Duke, Martin
> Sent: 12 November 2013 16:57
> To: [email-masked]
> Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
>
> Teco,
>
>                                               response. Contains TCP
> address/port for
>                                                       subsequent connection.
>  <-------------------------- Peer Initialization (New message). The Peer
> Init message contains, for example, all of the MANDATORY metric TLVs that
> the modem supports. It's a way to get the DLEP control session
> initialized.
>
> ... and I suppose Stan, if he was finishing the example, would need two
> additional messages to complete session negotiation.
>
> A bunch of comments:
> 1) Stan's stated purpose to flip the SYN is to put the server
> implementation at the router. Frankly that's good enough for me unless
> Teco has counter-arguments.
> 3) I'm not particularly convinced that we have to strip all the TLVs and
> whatnot out of the Peer Discovery/Peer Offer messages and put them in a
> new Peer Initialization exchange. It's a small thing either way, but I'm
> in favor of having fewer messages if we can afford it, and refusing
> sessions prior to a TCP handshake if we can do it.
>
> Martin
>
> > It feels like the terminology is a bit jumbled here. The "Peer
> Discovery" contains all the session parameters for the modem. The "Peer
> Offer" in effect acknowledges these and contains relevant parameters for
> the Router. The "Peer Offer ACK" confirms the modem's acceptance of these?
> Why do we have to confirm the confirmation?
>
> We have to come back to this. Recent posts rename couple of messages.
> Discovery is just the advertisement, where DLEP session setup takes care
> of transfer of all supported TLVs.
>
> > It informs the modem that router accepts the Modem Peer Offer. Then both
> peers of the session knows session setup was successful. If the Router
> does not accept the Peer Offer Ack (e.g. version mismatch), it sends an
> error and / or closes the connection.
>
> >
> > Teco
> >
> >
> >>
> >> Let's come back to this topic after we completed TCP connection and
> DLEP session management. Probably the issue is solved by then.
> >>
> >> Please comment on the TCP connection setup and maintenance. Below the
> proposal, adjusted after comments from Stan and Henning.
> >>
> >>> The plain language interpretation of this is that a modem that
> continues to send out Peer Discovery messages to find new peers will
> trigger resets of existing sessions.
> >>>
> >>> Perhaps the root problem is that we haven't really done a scrub for
> the implications of using TCP on all of the reliability mechanisms from
> previous drafts. I get confused on whether or not we're precluding UDP
> implementations, but maybe the right answer is to simply delete this
> provision.
> >>>
> >>> Do you think there is a need for terminating the TCP connection, other
> than what TCP can provide? Maybe you had something in mind with heartbeat
> turned off and blocked TCP port. I prefer a non-blocking implementation.
> For a crashed DLEP agent, I can think of a Peer Order with Reset TLV,
> where router resets the modem. Would be similar to AT!RESET.
> >>>
> >>> Teco
> >>>
> >>>
> >>>> Although I follow that you want multiple peer sessions per modem, I'm
> having trouble parsing what your prescription is to address the peer
> session teardown problem I pointed out.
> >>>>
> >>>> Martin
> >>>>
> >>>> I think we keep Peer Discovery message generation and DLEP session
> maintenance separate. This keeps state machines less complex, less code,
> less bugs, increased functionality.
> >>>>
> >>>> Having multiple DLEP session to same modem is related. If we support
> it, sending Peer Discovery messages shall not be stopped after first
> session.
> >>>>
> >>>> Reason why I need multiple sessions: about half of modems I have to
> support have multiple ethernet ports. They serve multiple unrelated
> networks, there is no single connected router. Some modems are 6 digit $,
> we have to share these expensive assets. And they fully support it;).
> >>>>
> >>>> Teco
> >>>>
> >>>>
> >>>>> Yes, this point was at the very end. The current spec says that if
> the router receives a Peer Discovery message it must terminate any
> existing session with that modem. Clearly this is not acceptable behavior
> if the modem is continuing to multicast Peer Discovery messages when a
> peer session exists.
> >>>>>
> >>>>> There are other ways to solve this problem, but the reply I got back
> was that there was no reason to keep seeking routers once a peer session
> exists. If there's disagreement on this point I'm happy  to back off the
> assertion that it's settled.
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> On 7: It was not discussed during our meeting, at least not were I
> was present. And I don't think this is a good idea. It is not needed and
> blocks more advanced usage of DLEP. Let's not have a restriction in that a
> router or modem has only a single DLEP peer.
> >>>>>
> >>>>> Teco
> >>>>>
> >>>>>> Thanks Ron. That matches the notes I have. I might also add this
> summary of what I think we agreed on in terms of changing/clarifying the
> spec, which perhaps is more interesting than the play-by-play:
> >>>>>>
> >>>>>> 4. The modem MUST include a Heartbeat Interval/Threshold TLV in its
> Peer Discovery messages. It is STRONGLY RECOMMENDED that the Interval be a
> nonzero value.
> >>>>>> 5. The modem MUST include all metric TLVs it reports in the Peer
> Discovery Message to allow the router to initialize its session control
> block.
> >>>>>> 6. The Router MUST NOT include metric TLVs in a Link
> Characteristics Request message that were not in the session's Peer
> Discovery message.
> >>>>>> 8. Both router and modem MUST send a Heartbeat Message to the peer
> if it has sent no DLEP message in an interval equivalent to the Heartbeat
> Interval value in the Peer Discovery Message. It MAY send a Heartbeat
> Message in every instance of the interval regardless of any other DLEP
> traffic.
> >>>>>> 10. The Heartbeat Interval/Threshold TLV becomes a "Heartbeat
> Interval TLV." Any DLEP peer is free to set any threshold for terminating
> the peer session as long as it equals or exceeds two Heartbeat Intervals,
> unless the Heartbeat Interval is zero.
>
> >>>>>> 13. Keep the RLQ TLV, but Rick and Stan will formulate a stricter
> definition. There will be no other link quality TLVs (e.g. BER, packet
> delivery rate, SINR, etc) in the next draft.
> >>>>>> 14. Stan to add clarifying language on how multicast neighbors
> work, in line with what he said at the meeting.
> >>>>>>
> >>>>>>> en voor schade, van welke aard ook, die verband houdt met risico's
> verbonden aan het elektronisch verzenden van berichten.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This message may contain information that is not intended for
> you.
> >>>>>>>> If you
> >>>>>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
> >>>>>> This message may contain information that is not intended for you.
> If you are not the addressee or if this message was sent to you by
> mistake, you are requested to inform the sender and delete the message.
> TNO accepts no liability for the content of this e-mail, for the manner in

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 11:19:49 +0100

> Sorry, this list has gone quite mad since Vancouver, but I suppose that shows interest by the DT!

I would say we became quite active... :)

And we are moving forward... if we keep pushing in this pace we might
have the necessary facts for DLEP-05 together this year. :)

Henning Rogge

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Nov 2013 07:16:45 -0800

I agree with almost all of what Stan and Rick said, but I don't think it
would hurt to have a sentence like "A router MAY send unicast peer
discovery messages to modems, regardless of logical distance, if it has
obtained their IP address through an out-of-band process."
On Nov 14, 2013 2:13 AM, "Taylor, Rick" <[email-masked]> wrote:

> Yes, we should specify that link-local multicast SHOULD be used (sent by
> the router periodically) and not forwarded.
>
> Yes, we should add some text to say "Other discovery methods may be used,
> but then you start the standard TCP part of DLEP session establishment"
>
> Yes, we should not preclude multi-hop links between router and modem, but
> also we should not get caught up in defining it - the draft IMHO should
> define the 1-hop behaviour only.
>
> (When I say 'we' - I mean Stan and the other authors, it's just easier
> than translating all sentences into the passive voice and using 'one'
> instead, which just makes my prose increasingly Shakespearean which is
> unkind on those for whom English is a second language - this sentence being
> a case in point)
>
> Rick
>
> >
> > Stan
> >
> > >>>> Sending the multicast from router to modem (and having the TCP
> server
> > on
> > >>>> with L2 MAC filter, as this would block a set of multicast
> addresses.
> > The
> only and therefore if you wish to disclose the information contained within
> this e-mail or attached files, please contact the sender prior to any such
> disclosure. If you are not the intended recipient, any disclosure, copying
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files from
> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Nov 2013 07:19:11 -0800

I'm comfortable with router-initiated processes, though it doesn't seem to
match up with things that Stan and Teco have said recently.
On Nov 14, 2013 2:17 AM, "Taylor, Rick" <[email-masked]> wrote:

> Martin,
>
> I think the discussions passed like two ships in the night, but I believe
> we have now moved to peer discovery being a router-initiated process for
> exactly the reason you describe.
>
> The router can keep strobing for interested modems, and modems can decide
> to connect to the advertising router if they wish.
>
> If you check back through the archive, the recent thread called "DLEP
> session establishment" has the discussion.
>
> > <------------------------ Peer Discovery     Modem initiates discovery
> via
> > MCAST UDP.
> >                                                       subsequent
> connection.
> > Op 12 nov. 2013, om 17:04 heeft Duke, Martin <[email-masked]>
> het
> > volgende geschreven:
> >
> > >>> Op 11 nov. 2013, om 17:33 heeft Duke, Martin <[email-masked]
> >
> > het volgende geschreven:
> > >>>
> > >>>> Teco,
> > >>>>
> > >>>> Op 11 nov. 2013, om 16:30 heeft Duke, Martin <
> [email-masked]>
> > het volgende geschreven:
> > >>>>
> > >>>>> Teco,
> > >>>>>
> > >>>>> Op 8 nov. 2013, om 21:40 heeft Duke, Martin <
> [email-masked]>
> > het volgende geschreven:
> > >>>>>
> > >>>>>> 3. The modem and router MUST include DLEP version in Peer
> Discovery
> > and Peer Offer messages.
> > >>>>>>>> Indien u niet
> bericht

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 16:19:28 +0100

Are we still talking about switching the tcp-server socket and the
originator of the multicast discovery packet?

Henning Rogge

On Thu, Nov 14, 2013 at 4:16 PM, Martin Duke <[email-masked]> wrote:
> would hurt to have a sentence like "A router MAY send unicast peer discovery
> messages to modems, regardless of logical distance, if it has obtained their
> IP address through an out-of-band process."
>
>> > >>>> shall not be forwarded over the modem link (e.g. RF path). Cannot
>> > >>>> be
>> > done
>> > >>>> LLDP better fits our requirement for discovery. It doesn't take
>> > >>>> away
>> > the
>> > >>> And yes, perhaps we should be using mDNS/Bonjour for discovery
>> > >>> rather
>> > than re-inventing the wheel here.
>> > >>
>> information. The contents of this e-mail are for the intended recipient only
>> and therefore if you wish to disclose the information contained within this
>> e-mail or attached files, please contact the sender prior to any such

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 16:20:34 +0100

I still prefer the UDP peer discovery sent by the radio.

Henning Rogge

On Thu, Nov 14, 2013 at 4:19 PM, Martin Duke <[email-masked]> wrote:
>> > 2) Given #1, I agree with Stan the Peer Offer has to come outside the
>> > TCP
>> > connection to provide the port number.
>> > All of this has to do with rework because we transfer to TCP were we
>> > have
>> > the connection setup.
>> >
>> > Teco
>> >
>> >
>> > >
>> > >>> Op 11 nov. 2013, om 17:33 heeft Duke, Martin
>> > >>> <[email-masked]>
>> > het volgende geschreven:
>> > >>>
>> > >>>> Teco,
>> > >>>>
>> > >>>> Op 11 nov. 2013, om 16:30 heeft Duke, Martin
>> > >>>> <[email-masked]>
>> > het volgende geschreven:
>> > >>>>
>> > >>>>> Teco,
>> > >>>>>
>> > >>>>> Op 8 nov. 2013, om 21:40 heeft Duke, Martin
>> > >>>>> <[email-masked]>
>> > het volgende geschreven:
>> > >>>>>
>> > >>>>>> 9. Both router and modem MUST reset their Heartbeat timer when
>> > >>>>>> any
>> > DLEP message arrives from the peer.
>> > >>>>>> 11. We will combine Expected Forwarding Time and Latency TLVs
>> > >>>>>> into
>> > a single, well-defined TLV.

---

From: Rick Taylor <[email-masked]>
Date: Thu, 14 Nov 2013 15:56:20 +0000

+1 - Good point, I think we need to suggest some final text for this whole discovery process soon or we will forget our rough consensus.

Rick (on his other email address)

________________________________
From: [email-masked] [[email-masked]] on behalf of Martin Duke [[email-masked]]
Sent: 14 November 2013 15:16
To: Taylor, Rick
Cc: [email-masked] Group ([email-masked]); Stan Ratliff (sratliff)
Subject: Re: [manet-dlep-rg] DLEP multicast address

I agree with almost all of what Stan and Rick said, but I don't think it would hurt to have a sentence like "A router MAY send unicast peer discovery messages to modems, regardless of logical distance, if it has obtained their IP address through an out-of-band process."

On Nov 14, 2013 2:13 AM, "Taylor, Rick" <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:manet-dlep-rg-<mailto:manet-dlep-rg->
> [email-masked]<mailto:[email-masked]>] On Behalf Of Stan Ratliff (sratliff)

Rick

>
> Stan
>
> On Nov 13, 2013, at 2:45 PM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
>
> > On Wed, Nov 13, 2013 at 7:31 PM, Teco Boot <[email-masked]<mailto:[email-masked]>> wrote:
> >> Changed subject.
> >>
> <[email-masked]<mailto:[email-masked]>> het volgende geschreven:
> >>>
> >>>>

---

From: Rick Taylor <[email-masked]>
Date: Thu, 14 Nov 2013 15:58:29 +0000

The problem as I see it with the modem initiated discovery process is the extra ACK required via UDP from the router:

Router                         Modem
=====================
<--------------------- Peer Discovery
I'm here (UDP) -------------------->
<----------------------- TCP connect

Rather than:

Router                         Modem
=====================
Peer Advert -------------------->
<----------------------- TCP connect

Just one less step with unreliable transport.

Can you describe what advantages you see with Modem initiated discovery?

Cheers,

Rick

________________________________________
From: [email-masked] [[email-masked]] on behalf of Henning Rogge [[email-masked]]
Sent: 14 November 2013 15:20
To: Martin Duke
Cc: Duke, Martin; DLEP Research Group ([email-masked]); Teco Boot; Taylor, Rick
Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 14 Nov 2013 16:03:11 +0000

If you've already got the the peer's address via some out-of-band mechanism, then why "discover" him? I've tried to separate things out so that the *only* thing discovery does is… wait for it… 'discover'. It tells you the address/port of where you need to go connect up. Pretty much all other init gets pushed back into the new Peer Initialization message. About the only thing that makes sense to me in discovery is the software level of the peers - If, for instance, I'm at DLEP Version 19, and I discover a potential DLEP peer at Version 1, I *might not* want to connect up in the first place.

Regards,
Stan

On Nov 14, 2013, at 10:56 AM, Rick Taylor <[email-masked]<mailto:[email-masked]>>
 wrote:

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Martin Duke [[email-masked]<mailto:[email-masked]>]
Sent: 14 November 2013 15:16
To: Taylor, Rick
Cc: [email-masked]<mailto:[email-masked]> Group ([email-masked]<mailto:[email-masked]>); Stan Ratliff (sratliff)
Subject: Re: [manet-dlep-rg] DLEP multicast address

Rick

> server on the router. If one finds an improvement, I'm all ears.
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com<http://www.cassidian.com/>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 17:05:38 +0100

I would prefer this:

Router                         Modem
=====================
<--------------------- Peer Discovery
TCP connect ------------------------>

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Thu, 14 Nov 2013 16:03:58 +0000

The only reason for a unicast UDP packet I can see is for the router to signal it's readiness to accept connections to a modem, but it is a corner case out of scope for the core draft really and doesn't actually change the protocol.

I was thinking through what needs to go in the discovery packet, and I agree with Stan:  Mandatory version, any other TLV is optional and could be alternate TCP address, alternate reliable protocol endpoint address, but these are all optional TLVs.

I'll get my ASCII art out in a sec and give it a go...

Rick

P.S.  Switched to plain text...

From: Stan Ratliff (sratliff) [[email-masked]]

Sent: 14 November 2013 16:03

To: Rick Taylor

Cc: Martin Duke; Taylor, Rick; [email-masked] Group ([email-masked])

If you've already got the the peer's address via some out-of-band mechanism, then why "discover" him? I've tried to separate things out so that the *only* thing discovery does is… wait for it… 'discover'. It tells you the address/port of where you need
 to go connect up. Pretty much all other init gets pushed back into the new Peer Initialization message. About the only thing that makes sense to me in discovery is the software level of the peers - If, for instance, I'm at DLEP Version 19, and I discover a
 potential DLEP peer at Version 1, I *might not* want to connect up in the first place.

Regards,
Stan

On Nov 14, 2013, at 10:56 AM, Rick Taylor <[email-masked]>
 wrote:

From: [email-masked] [[email-masked]]
 on behalf of Martin Duke [[email-masked]]

To: Taylor, Rick

Cc: [email-masked] Group ([email-masked]);
 Stan Ratliff (sratliff)

I agree with almost all of what Stan and Rick said, but I don't think it would hurt to have a sentence like "A router MAY send unicast peer discovery messages to modems, regardless of logical distance, if it has
 obtained their IP address through an out-of-band process."

> (b) a potentially multi-hop operation, utilizing some sort of site-local

> or other MCAST technique/address?

(When I say 'we' - I mean Stan and the other authors, it's just easier than translating all sentences into the passive voice and using 'one' instead, which just makes my prose increasingly Shakespearean which is unkind on those for whom English is a second
 language - this sentence being a case in point)

Rick

> >>>> Sending the multicast from router to modem (and having the TCP server

> >>>> router) adds some complexity on the modem, in that this multicast

> packet

> >>>> shall not be forwarded over the modem link (e.g. RF path). Cannot be

> >>>> with L2 MAC filter, as this would block a set of multicast addresses.

> >>>> LLDP better fits our requirement for discovery. It doesn't take away

> >>>> widely implemented, I think. And would be bridged on modems that

> doesn't

> >>> And yes, perhaps we should be using mDNS/Bonjour for discovery rather

> >> Not these ones. These shall be forwarded to remote nodes, to keep

> existing stuff going.

> https://www.ietf.org/mailman/listinfo/manet-dlep-rg

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose
 the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform
 them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

[email-masked]

---

From: Teco Boot <[email-masked]>
Date: Thu, 14 Nov 2013 17:09:05 +0100

Op 14 nov. 2013, om 16:19 heeft Martin Duke <[email-masked]> het volgende geschreven:

> I'm comfortable with router-initiated processes, though it doesn't seem to match up with things that Stan and Teco have said recently.

It is in the details here. Questions are: who initiates the TCP connection, who initiates the discovery.

We have an outcome on modem as multicast listener and TCP connection - DLEP session initiator. My personal view is that it makes DLEP a somewhat more complex protocol, where some of you say the modem DLEP implementation is more lightweight. Decision is pending, also because some of us gather viewpoints from radio vendors.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 14 Nov 2013 17:12:49 +0100

> I still prefer the UDP peer discovery sent by the radio.

+1
Followed by a TCP SYN response sent by router.
This enables set up of DLEP sessions without the UDP ignition packet. Routers can send the TCP SYN to the modem if they have knowledge on the modem IP address.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 14 Nov 2013 16:24:33 +0000

On Nov 14, 2013, at 11:12 AM, Teco Boot <[email-masked]>
 wrote:

> This enables set up of DLEP sessions without the UDP ignition packet.

I just want to make sure we're on the same page here… AFAIK, opening up a UDP socket *is* the mechanism whereby applications (like DLEP) would actually send an MCAST packet - *any* MCAST packet. Or am I missing something?

Stan

> Routers can send the TCP SYN to the modem if they have knowledge on the modem IP address.
> 
> Teco
> 
> 
>> 
>> Henning Rogge
>>

---

From: Rick Taylor <[email-masked]>
Date: Thu, 14 Nov 2013 16:23:51 +0000

I'm afraid I still prefer the router being in the listen state for the TCP and the modem sending the SYN.

It just seems more logical to have the router that will be communicating with multiple modems being the TCP server.

Rick
________________________________________
From: [email-masked] [[email-masked]] on behalf of Teco Boot [[email-masked]]
Sent: 14 November 2013 16:12
To: Henning Rogge
Cc: Duke, Martin; DLEP Research Group ([email-masked]); Martin Duke; Taylor,    Rick
Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

+1

Teco

---

From: Rick Taylor <[email-masked]>
Date: Thu, 14 Nov 2013 16:25:34 +0000

I think we are on the same page, just writing on different sides of it...

________________________________________
From: [email-masked] [[email-masked]] on behalf of Stan Ratliff (sratliff) [[email-masked]]
Sent: 14 November 2013 16:24
To: Teco Boot
Cc: DLEP Research Group ([email-masked])
Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88

Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 14 Nov 2013 17:22:54 +0000

+1

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 18:43:52 +0100

LOL, yes...

I think we talked a lot about this ~ a year ago... who should do the
initial discovery multicast and who should answer. The result back at
this time was "radio sends multicast, router responds".

I don't really see a good reason to turn this around now.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 14 Nov 2013 17:53:07 +0000

I thought about not sending this email… perhaps I should have abided that urge, but what-the-heck… ;-) 

> This enables set up of DLEP sessions without the UDP ignition packet. Routers can send the TCP SYN to the modem if they have knowledge on the modem IP address.

If this winds up being the path taken, it means that modems are going to wind up juggling UDP and TCP sockets, including a TCP listen() socket. Multi-socket select() dispatch loops; managing listen queue depth, and dealing with non-blocking sockets (so that the select works) are also on the horizon for the modem implementers. And all of this to get a 1-hop discovery mechanism running - I wonder what the path length (libraries INCLUDED) for that is, just to avoid a single line of config (that being, the address and port of the other end of the connection)? 

The alternative I was shooting for, from the modem perspective, was along the lines of: 
1. Open a (blocking? non-blocking? don't care) UDP socket. 
2. Receive the discovery packet. Close that socket? Keep it open? Your call. 
3. Open a TCP socket. Issue connect(), from the info you got (and/or derived) from the discovery packet.
4. Flail away, sending and receiving actual DLEP protocol packets!

I'm beginning to think we need to pop the champagne corks and congratulate ourselves for (partially) designing something no one in their right mind would implement…

Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Nov 2013 18:58:06 +0100

Stan,

maybe you should think about the argument again... it doesn't matter
if the radio or the router sends the UDP discovery packet... it
doesn't matter either if the radio is the TCP server or client.

In all cases both radio and router will handle UDP and TCP... and most
likely nobody will care about the few lines of codes.

Many modern radio vendors implement their radio software by buying an
embedded operation system including a full TCP/IP stack... or they
just use an open source one, which also will already have a posix
compatible IP stack. They wont have to implement it themselves.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 14 Nov 2013 19:49:34 +0100

Op 14 nov. 2013, om 18:53 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

> If this winds up being the path taken, it means that modems are going to wind up juggling UDP and TCP sockets, including a TCP listen() socket.

No. Sending the UDP multicasts stays active. TCP listen socket stays listening.

> Multi-socket select() dispatch loops; managing listen queue depth, and dealing with non-blocking sockets (so that the select works) are also on the horizon for the modem implementers. And all of this to get a 1-hop discovery mechanism running - I wonder what the path length (libraries INCLUDED) for that is, just to avoid a single line of config (that being, the address and port of the other end of the connection)? 

I would not recommend to implement it this way.

> 4. Flail away, sending and receiving actual DLEP protocol packets!

Looks complex to me.
Just use:
1. start simple DLEP discovery daemon, sending a UDP link-local multicast packet every now and then
2. start DLEP listener daemon
3. on TCP SYN, spawn a DLEP proces

For 3 there are other options. I’m pretty sure there will be a high performance open source DLEP implementations before RFC status. 

> I'm beginning to think we need to pop the champagne corks and congratulate ourselves for (partially) designing something no one in their right mind would implement…

You are wrong. TCP servers on modems are implemented today. 

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Nov 2013 10:17:47 +0100

> I would not recommend to implement it this way.

I will implement it exactly like Stan described. Single-threaded code
using posix API like select() to handle multiple sockets. I just don't
think I need the "manage listen queue depth"... if the implementation
is configured to only accept a single DLEP radio, it just will send a
"terminate" message the all other incoming connections.

Moving DLEP (as a specification) forward and getting an open source
(BSD licence) and standard compliant implementation is one of the
goals of the CONFINE project for us in the next two years.

Main platforms for this code will be OpenWRT (for embedded systems)
and normal Linux.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 15 Nov 2013 10:33:36 +0000

Okay, just to back it up a bit, and try to get some clarity in the debate.

As I understand it, we are all happy with:

    Server                                          Client

1)  TCP Listen()

2*) Peer_Discovery (UDP) ------------Multicast----------->
      + Version

3)  <--------------------------------------- TCP Connect()

4)  <---------------------------------- Peer_Request (TCP)
                                                 + Version
                                       + optional extras 1

5)  Peer_Accept (TCP) ----------------------------------->
      + Status
      + Version
      + optional extras 2

*Step 2 may be replaced with a-priori configuration, mDNS, etc...

What we are arguing about is who should be the Client, and who should be the Server.

So, I am now calling for everyone's answer to the following question:

"Should the modem be the Client or the Server in the above diagram, and why?"

I have intentionally left 'optional extras' 1 and 2 undefined as they may be relevant in your answers.

I will give my answers in a separate email.

If anyone has a problem with the above diagram, now is your chance to shout!

Cheers,

Rick

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 13:11:08 +0100

> As I understand it, we are all happy with:

Modem should be the server:
 - modems are servers today, for link metrics, OA&M etc.
 - modems provide a service, so they act as server
 - modems are "thumb" devices and can be reach from anywhere in the Internet, if permitted. No need to configure the modem for it, except setting access rights. No need to fire an "ignition packet".
 - modems can easily handle many TCP sockets, either TCP server or TCP client
 - TCP server programming is not more difficult than TCP client

> I have intentionally left 'optional extras' 1 and 2 undefined as they may be relevant in your answers.

The Ack in the 3-way handshake is missing. After 5, Server thinks the DLEP session is open, but Client is not aware of it yet. This is minor detail, perhaps indeed use as few packets as possible. Also less state.

> If anyone has a problem with the above diagram, now is your chance to shout!

Yes, TCP server socket must be opened before the Peer_Discovery. 
After connection, Peer_Discovery packets SHOULD continue to be sent, for the following reasons:
 - no relation between UDP and TCP sockets, more lightweight
 - for modems that support it, other routers may set up DLEP sessions also
 - better recovery in case of failures, router knows modem is still present (think of heartbeat=zero)
 - in line with other discovery protocols (CDP, LLDP, Bonjour etc).

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 15 Nov 2013 12:54:18 +0000

> Subject: Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re:
> notes DLEP meeting @ IETF88)
>  - modems are "thumb" devices and can be reach from anywhere in the
> Internet, if permitted. No need to configure the modem for it, except
> setting access rights. No need to fire an "ignition packet".

I'll send my thoughts on this later.

> The Ack in the 3-way handshake is missing. After 5, Server thinks the DLEP
> session is open, but Client is not aware of it yet. This is minor detail,
> perhaps indeed use as few packets as possible. Also less state.

Isn't the client aware the session is established when it receives the Peer_Accept (I renamed the ACK) with status code?

> Yes, TCP server socket must be opened before the Peer_Discovery.

+1 Yes, agreed, it is, that's what I meant by listen() in step 1.

>  - in line with other discovery protocols (CDP, LLDP, Bonjour etc).

+1 Yes, I just didn't put this in the diagram for simplicity.

Rick

---

From: John Dowdell <[email-masked]>
Date: Fri, 15 Nov 2013 12:55:37 +0000

>  - in line with other discovery protocols (CDP, LLDP, Bonjour etc).

My question would be that if I wanted to use a low power radio mesh device
(e.g. 802.15.4), I would like the radio to have the fewest cycles to
perform so that the sleep mode (which might be 90% of its life) functions
as normal.

John

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Nov 2013 13:58:39 +0100

On Fri, Nov 15, 2013 at 1:55 PM, John Dowdell
<[email-masked]> wrote:
> (e.g. 802.15.4), I would like the radio to have the fewest cycles to perform
> so that the sleep mode (which might be 90% of its life) functions as normal.

Do you mean an IEEE 802.15.4 radio attached via ethernet to a local
system or an embedded system with integrated radio that use DLEP as a
generic API for its software?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 14:20:02 +0100

> generic API for its software?

I had same kind of question. 

IETF has a routing protocol for route over. Others have defined a mesh under. Runs on devices themselves. There are proposals to connect such networks with ethernet to a backbone router.

Maybe such use cases can reuse some of DLEP. For us, it is less in scope, I think. 

Teco

---

From: John Dowdell <[email-masked]>
Date: Fri, 15 Nov 2013 13:27:00 +0000

> generic API for its software?

I would want to use them attached via Ethernet, but even if the module
is embedded and runs over SPI bus or similar, the concept should be
the same, maybe using a virtual NIC.

John

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Nov 2013 14:32:05 +0100

First of course the transmitter/receiver part of the radio should
sleep as much as possible.

I would guess that you would also increase the intervals of all
"Heartbeat/Discovery" mechanisms a bit so the CPU of the radio can go
to sleep mode until the next data of the router arrives or the next
timer event happens.

It might also make sense to have a rate limitation of the metric
updates, to prevent the radio from waking up the router too much when
no traffic is incoming. Maybe a metric update would be delayed until
the radio has to deliver the next IP packet (either heartbeat or radio
traffic) to the router.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 15 Nov 2013 13:34:52 +0000

Okay, I'm wavering on this one.  I've being thinking hard on this, and my opinion is changing.

First off:

Implementation issues are irrelevant in my opinion.  We are all agreed that writing a TCP server or client is pretty much boiler-plate code.  Modems have full TCP stacks, so do routers (I'm ignoring John's 802.15.4 question).

And now my ramblings:

The correct assignment of Server and Client roles should be driven by semantics of the roles, a server normally handles multiple conversations with many clients: HTTP, SNMP, SMTP, etc, etc...

A server also 'serves' information to interested parties: "I have information, come get it" is a well-used paradigm.

But, using these two suggested modes of operation gives two different answers:

Routers (in general) will handle multiple sessions with modems, and modems (in general) will communicate with a single router.  This implies that the Router should be the Server.

However, Modems 'serve' DLEP information to routers; they have information for the router to come ask them about.  This implies that the Modem should be the TCP server.  The modem can decide how many sessions to accept and serve (generally 1).

An important factor that I believe has not yet been addressed is that DLEP capable routers 'want' to create a DLEP session with a modem so they can perform their function, but a modem doesn't really care if anyone is receiving DLEP info.  This leads me to suggest that a router should find out that there is a modem on an interface (it receives the discovery) and it then demands the DLEP session from the modem (i.e. It connects to the server in the modem).

>From a game-theory perspective (bear with me) the modem gets no benefit by connecting to an advertising router, and therefore may not, but a router does gain benefit and therefore can force the session creation by connecting.  Therefore, the router should be the client.

Aaaargh!  I'm now arguing with myself!

Rick

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Nov 2013 14:42:15 +0100

> Routers (in general) will handle multiple sessions with modems, and modems (in general) will communicate with a single router.  This implies that the Router should be the Server.

Teco told me about radios he work with (UMTS, satlink) that have
multiple ethernet connections to attach local devices, which might be
a case of "radio talking to multiple routers/devices". I don't think
this will change the core protocol of DLEP at all, it just makes the
"server/client" decision even more ambiguous.

>  Therefore, the router should be the client.

I agree. *G*

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Fri, 15 Nov 2013 13:40:22 +0000

After a quick rant at a colleague, it has been pointed out that the fewer devices on the network throwing out discovery packets on multicast, the better.

So perhaps the router should be the server.

But, the multi-cast is link-local so there shouldn't be issues with flooding...

Aaargh!

________________________________________
From: [email-masked] [[email-masked]] on behalf of Taylor, Rick [[email-masked]]
Sent: 15 November 2013 13:34
Cc: DLEP Research Group ([email-masked]); Dowdell, John
Subject: Re: [manet-dlep-rg] TCP clients, servers, and discovery (WAS: Re: notes DLEP meeting @ IETF88)

First off:

And now my ramblings:

Rick

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 14:57:29 +0100

> "server/client" decision even more ambiguous.

Stan: you cooperate with Persistent. Their small radio has two ethernets, the larger one has five. Even it is only one router connected, and other ports are for hosts, why not having the hosts have knowledge of network state? We use applications that are topology and / or available resources aware. Also, a host could run a management app which shows the dlep provided data with a GUI. I'm pretty sure it is not only me, as some of those apps are off the shelf.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 15 Nov 2013 14:57:15 +0100

And if the radio is directly (without a switch) connected to an
interface of the router, there is not even a difference between
unicast and multicast in terms of networking overhead.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 15:05:26 +0100

> unicast and multicast in terms of networking overhead.

Router and modem cannot know if there is a transparent bridge between.

>> After a quick rant at a colleague, it has been pointed out that the fewer devices on the network throwing out discovery packets on multicast, the better.

Yes, this is a valid argument. The fewer multicast packets are seen by modem, the better. Same for router.

The protocol can be tuned to react on circumstances. After an IF UP condition, multicast rate may be higher for minute or so (STP is still around). After a stable state, and no other router is expected, multicast rate can be decreased, optionally to zero. Doesn't influence the protocol.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 15 Nov 2013 16:37:02 +0000

>> As I understand it, we are all happy with:

As long as all supported metric TLVs are part of "optional extras 1", I'm OK with this. 

> - TCP server programming is not more difficult than TCP client

Obviously I disagree. I've seen emails on this thread that speak of "keeping the modem dumb". Making the modem a TCP server is orthogonal to that approach. As to "an ignition packet", I have *no idea* what that means. UDP traffic is going to be required for discovery. It's pretty easy for me to call any UDP packet sent or received "an ignition packet"., so that particular argument seems specious.

There have also been comments about the 1-to-N relationships (router-to-modem, modem-to-router). In reality, there's *always* been an underlying "N-to-N" notion in DLEP. Now, that was before the decision to change to TCP...

> The Ack in the 3-way handshake is missing. After 5, Server thinks the DLEP session is open, but Client is not aware of it yet. This is minor detail, perhaps indeed use as few packets as possible. A…

No its not. The Peer Accept is the "ACK". Is it "tow-MAY-tow", or "tow-MAH-tow"? (Maybe a bad joke for the non-native English speakers, but I'm leaving it in).

> Yes, TCP server socket must be opened before the Peer_Discovery. 

Wow. Just. Wow.

> After connection, Peer_Discovery packets SHOULD continue to be sent, for the following reasons:

Seems to me that there's an implicit notion at play here. Specifically, it's that "I (irrespective of whether I'm the modem or the router) will keep strobing discovery packets because I might find other appropriate DLEP peers *on this network segment*." Remember, we've already come close to consensus that discovery is a 1-hop operation, using link-local MCAST.  Having multiple radios on the same network segment (Ethernet) is something that Cisco has long advised customers *NOT* to do. Especially when the RF coverage of those multiple radios overlap with respect to the destinations served - for example let's assume that I have routers that have C-band satellite radios, and some line-of-sight radio. I take 9 or 10 of those setups, and I stick them out in the middle of a flat desert plain, at distances of about 5KM. Everyone can see everyone else, so *both* the C-band satellite radios *and* the LOS radios connect. So far, so good. 

Now, one of the routers emit a multicast packet (one to a multicast MAC). Or a broadcast packet. Which radio serves it? The problem in this case extends to unicast destinations as well. Since the destination MAC in the packet is the far-end router, then in theory *both* radios know about it - after all, they've *both* got connectivity to the exact same far-end MAC address (since everyone has the multiple radios). So in that case, do you get two copies of everything? Or does some intervening Ethernet switch try to decide? If the switch is in play, then "Murphy's Law" (the notion that 'If anything CAN go wrong, it WILL go wrong') will be in play, and chances are the switch will make the *wrong* decision (or at least the decision you DIDN'T expect it to make). 

If the connectivity of the two radios is completely orthogonal, then this setup works like a champ. But as the connectivity of the two different RF nets starts to converge, the problems mount. Hence, the recommendation to run multiple radios on *different* network segments - either by using VLANS, or sub interfaces, or just different Ethernet ports if you have to. 

As for the "1-to-N" case from the modem perspective (e.g. 1 modem connected to N routers), you don't really have the problem above - the modem knows it will *always* handle the traffic. But there's an entirely different set of issues. Namely, how *do* you report bandwidth? Yeah, I know - we've been saying "that's the radio's problem." But in looking at the deployment scenario, what would you *recommend* as to how that situation be handled? 

Stan 

> - in line with other discovery protocols (CDP, LLDP, Bonjour etc)

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 18:15:27 +0100

> Obviously I disagree. I've seen emails on this thread that speak of "keeping the modem dumb". Making the modem a TCP server is orthogonal to that approach. As to "an ignition packet", I have *no id…

The ignition packet is the additional required (unicast) UDP packet when modem is TCP client and TCP server on other node is several hops away.

> There have also been comments about the 1-to-N relationships (router-to-modem, modem-to-router). In reality, there's *always* been an underlying "N-to-N" notion in DLEP. Now, that was before the de…

OK, we keep the N-to-M where N < M or N = M or N > M.

> No its not. The Peer Accept is the "ACK". Is it "tow-MAY-tow", or "tow-MAH-tow"? (Maybe a bad joke for the non-native English speakers, but I'm leaving it in).

The ACK on Peer_Accept is missing.

> Seems to me that there's an implicit notion at play here. Specifically, it's that "I (irrespective of whether I'm the modem or the router) will keep strobing discovery packets because I might find other appropriate DLEP peers *on this network segment*." Remember, we've already come close to consensus that discovery is a 1-hop operation, using link-local MCAST.  Having multiple radios on the same network segment (Ethernet) is something that Cisco has long advised customers *NOT* to do.

Good recommendation. 
Without DLEP, it works. Better not have DLEP break what is working today.

> Especially when the RF coverage of those multiple radios overlap with respect to the destinations served - for example let's assume that I have routers that have C-band satellite radios, and some line-of-sight radio. I take 9 or 10 of those setups, and I stick them out in the middle of a flat desert plain, at distances of about 5KM. Everyone can see everyone else, so *both* the C-band satellite radios *and* the LOS radios connect. So far, so good. 
> 
> Now, one of the routers emit a multicast packet (one to a multicast MAC). Or a broadcast packet. Which radio serves it?

With 802.1D, STP is mandatory here.
(I second your recommendation here, don't do this!)

> The problem in this case extends to unicast destinations as well. Since the destination MAC in the packet is the far-end router,

Could be. MAC destination address could also be the modem.

> then in theory *both* radios know about it - after all, they've *both* got connectivity to the exact same far-end MAC address (since everyone has the multiple radios). So in that case, do you get two copies of everything?

No.

> Or does some intervening Ethernet switch try to decide?

Yes.

> If the switch is in play, then "Murphy's Law" (the notion that 'If anything CAN go wrong, it WILL go wrong') will be in play, and chances are the switch will make the *wrong* decision (or at least the decision you DIDN'T expect it to make).

STP is somewhat better than Murphy, but I know what you mean.

> If the connectivity of the two radios is completely orthogonal, then this setup works like a champ. But as the connectivity of the two different RF nets starts to converge, the problems mount. Henc…

Lets recommend separate interfaces for routers with multiple modems attached (like Figure 2 in DLEP).

> As for the "1-to-N" case from the modem perspective (e.g. 1 modem connected to N routers), you don't really have the problem above - the modem knows it will *always* handle the traffic. But there's…

Reporting link metrics is not the problem. It is the multi-party control sessions that introduce complexity.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 15 Nov 2013 18:29:57 +0000

> The ignition packet is the additional required (unicast) UDP packet when modem is TCP client and TCP server on other node is several hops away.

We've already said we're excluding multi-hop discovery. Multi-hop sessions skip to step 3. No "ignition" expressed or implied. 

> OK, we keep the N-to-M where N < M or N = M or N > M.

:-) Fine. We'll use your verbiage. 

> The ACK on Peer_Accept is missing.

I would disagree with "missing". I'd call it "unnecessary". I don't think you need a 3-way layer 7 handshake on top of a 3-way layer 4 handshake. Unless there's a *specific* protocol issue I'm missing. 

> Lets recommend separate interfaces for routers with multiple modems attached (like Figure 2 in DLEP).

We're in agreement there. But that recommendation does implicitly offer up a protocol optimization - that being, once you've found a DLEP partner on a given network segment (or interface), you can stop strobing discovery packets *on that segment* (or interface). Not that you have to - after all, it's a recommendation, not a MUST. 

> Reporting link metrics is not the problem. It is the multi-party control sessions that introduce complexity.

Well… reporting link metrics *is* a problem. The modem has a finite amount of RF. In this scenario, it has multiple entities trying to access the finite resource. All of those multiple entities (the routers) want to know how big the pipe is. It's not really much different than in the L2 mesh networking case, where there are multiple hops in the L2 mesh.  It becomes really, really easy for the modem to over-commit the RF resource. Multiple control sessions might be a problem as well, especially with the Link Characteristics Request. If router "A" asks for link characteristics that ultimately wind up interfering with router "B", I can see where a conflict can arise. I would expect the modem to mitigate that problem with "some vendor-specific heuristics". Outside of the LCR, the other MAJOR faux-pas I can see with multiple sessions happens *ONLY* when they are on the same local Ethernet segment (e.g. somebody that does NOT take our recommendation). Credits could get you into a HUGE problem there… With those exceptions, I don't see a whole lot of opportunity for things to go screwy with multiple sessions - after all, most of the rest of DLEP is less of a "control session" and more of a "signaling/eventing" mechanism.

Stan

---

From: Teco Boot <[email-masked]>
Date: Fri, 15 Nov 2013 20:00:30 +0100

> We're in agreement there. But that recommendation does implicitly offer up a protocol optimization - that being, once you've found a DLEP partner on a given network segment (or interface), you can…

Top be decided after we know who is TCP server.
If modem is TCP server, it should continue sending discovery packets, for newly attached routers to the ethernet segment.
If router is TCP server, it may stop discovery after TCP connection setup.

> Well… reporting link metrics *is* a problem. The modem has a finite amount of RF. In this scenario, it has multiple entities trying to access the finite resource. All of those multiple entities (th…

For shared media, it doesn't matter if concurrent access is from routers connected to same modem or from other nodes. Didn't we discuss this in Berlin? I remember the CDR was for rate when channel was idle. We discussed a third metric, the expected rate for this node, which is <= CDR.
Can you provide feedback on this topic after a chat with the Persistent guys? They would know how to deal with multiple routers (or hosts) to their radio's.

Teco

---

From: Martin Duke <[email-masked]>
Date: Mon, 18 Nov 2013 22:28:08 -0800

I don't think we want to rely just on TCP if we have OOB detection. Here
are some cases where we need the peer discovery anyway:

1. The router is configured with the modem address but the modem does not
have the router address.

2. The modem has the router IP address but not the port. (I believe the
latest concept requires zero standard TCP ports, and the Peer Discovery can
simply include the port number.)

3. The modem has the peer address, but powers up first; the TCP SYN gets no
reply, backs off and times out.

Clearly it is much cleaner for the router to send a UDP packet where we
control the frequency and timeout.

On Thursday, November 14, 2013, Stan Ratliff (sratliff) wrote:

>  If you've already got the the peer's address via some out-of-band
> mechanism, then why "discover" him? I've tried to separate things out so
> that the *only* thing discovery does is… wait for it… 'discover'. It tells
> you the address/port of where you need to go connect up. Pretty much all
> other init gets pushed back into the new Peer Initialization message. About
> the only thing that makes sense to me in discovery is the software level of
> the peers - If, for instance, I'm at DLEP Version 19, and I discover a
>  On Nov 14, 2013, at 10:56 AM, Rick Taylor <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> >
>  wrote:
>
>   +1 - Good point, I think we need to suggest some final text for this
> whole discovery process soon or we will forget our rough consensus.
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]]
> *Sent:* 14 November 2013 15:16
> *To:* Taylor, Rick
> *Cc:* [email-masked] Group ([email-masked]); Stan Ratliff
> (sratliff)
> *Subject:* Re: [manet-dlep-rg] DLEP multicast address
>
>   I agree with almost all of what Stan and Rick said, but I don't think
> it would hurt to have a sentence like "A router MAY send unicast peer

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 19 Nov 2013 17:47:09 +0000

On Nov 19, 2013, at 1:28 AM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:

I don't think we want to rely just on TCP if we have OOB detection. Here are some cases where we need the peer discovery anyway:

1. The router is configured with the modem address but the modem does not have the router address.

In the general case, the TCP client needs the address/port of the TCP server.

2. The modem has the router IP address but not the port. (I believe the latest concept requires zero standard TCP ports, and the Peer Discovery can simply include the port number.)

I don't think we should even try to cover all bases of mod-configuration. Your either provide a-priori config, or you don't. If you do, and it's wrong, then shame on you. ;-)

3. The modem has the peer address, but powers up first; the TCP SYN gets no reply, backs off and times out.

"Heuristics for retrying the TCP session are left to the discretion of the implementation"… ;-)

Clearly it is much cleaner for the router to send a UDP packet where we control the frequency and timeout.

This looks like a backup for bad a-priori config, or to address timing issues. IMO, it increases complexity of the implementation, and doesn't provide a whole lot of value-add. But I could be missing something.

Regards,
Stan

Regards,
Stan

On Nov 14, 2013, at 10:56 AM, Rick Taylor <[email-masked]<javascript:_e({},%20'cvml',[email-masked]');>>
 wrote:

Rick

---

From: Martin Duke <[email-masked]>
Date: Tue, 19 Nov 2013 21:36:26 -0800

I actually think it makes implementation simpler. The server sends UDP
packets occasionally to a well-known port and listens on a TCP port. The
client just has to listen ona UDP port; no other cases to handle. With
discovery messages always coming in, there's no need to build TCP retry
heuristics.

Configuration: I agree that there are no problems if client and server are
identically configured. But part of an interoperability spec is not
providing ways for client and server to get out of sync.

Regardless, I suggest the Peer Discovery contain the TCP server port, and
that if there is no Peer Discovery message the configuration must include
the server port. That way, we need only get the UDP port number from IANA.
On Nov 19, 2013 9:47 AM, "Stan Ratliff (sratliff)" <[email-masked]>
wrote:

>
>  On Nov 19, 2013, at 1:28 AM, Martin Duke <[email-masked]> wrote:
>
>  I don't think we should even try to cover all bases of
> mod-configuration. Your either provide a-priori config, or you don't. If
> you do, and it's wrong, then shame on you. ;-)
>
>
>  This looks like a backup for bad a-priori config, or to address timing
> issues. IMO, it increases complexity of the implementation, and doesn't
> provide a whole lot of value-add. But I could be missing something.
>
>  Regards,
> Stan
>
>
>> *Cc:* [email-masked] Group ([email-masked]); Stan
>> Ratliff (sratliff)

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Nov 2013 08:08:10 +0100

Wouldn't it be easier if we demand that the UDP source port of the
multicast is the same than the TCP server port?

Henning Rogge
On Nov 20, 2013 6:36 AM, "Martin Duke" <[email-masked]> wrote:

>>> Yes, we should add some text to say "Other discovery methods may be
>>> used, but then you start the standard TCP part of DLEP session
>>> establishment"
>>>
>>> Yes, we should not preclude multi-hop links between router and modem,
>>> but also we should not get caught up in defining it - the draft IMHO should

---

From: Teco Boot <[email-masked]>
Date: Wed, 20 Nov 2013 08:28:20 +0100

Op 20 nov. 2013, om 06:36 heeft Martin Duke <[email-masked]> het volgende geschreven:

> I actually think it makes implementation simpler. The server sends UDP packets occasionally to a well-known port and listens on a TCP port. The client just has to listen ona UDP port; no other cases to handle. With discovery messages always coming in, there's no need to build TCP retry heuristics.

This is the model I had in mind.
No need to specify TCP retry mechanism or wait for a discovery packet, both are fine.

> Configuration: I agree that there are no problems if client and server are identically configured. But part of an interoperability spec is not providing ways for client and server to get out of sync.

This needs collision handling. When two TCP connections are set up, one has to be cleared. During the period that two connections are active, it is difficult to predict what will happen with order messages.

> Regardless, I suggest the Peer Discovery contain the TCP server port, and that if there is no Peer Discovery message the configuration must include the server port. That way, we need only get the UDP port number from IANA.

No, I want a passive model supported, where a TCP client can set up the connection on the IANA assigned well known DLEP port. Having the port allocated for UDP and TCP isn't a problem, I think. This enables multi-hop reachability to (or from) the modem. I don't know how to do that _from_ the modem.

May I repeat one of my use cases, where the DLEP (or derivate) protocol passes a crypto device with built in data diode. TCP will not make it here. See http://tools.ietf.org/html/draft-ivancic-manet-modemlpa Figure 5 for description of this use case (thanks to authors of modemlpa). I have to use some kind of DLEP proxy/tunnel, making the protocol uni-directional tunnel. For now, I see standardization of such mechanism as future work.

Teco

> 
> On Nov 19, 2013 9:47 AM, "Stan Ratliff (sratliff)" <[email-masked]> wrote:
>

---

From: Teco Boot <[email-masked]>
Date: Wed, 20 Nov 2013 08:52:35 +0100

Op 20 nov. 2013, om 08:08 heeft Henning Rogge <[email-masked]> het volgende geschreven:

> Wouldn't it be easier if we demand that the UDP source port of the multicast is the same than the TCP server port?

I like protocols with (pseudo-)random source ports.

Teco

---

From: John Dowdell <[email-masked]>
Date: Wed, 20 Nov 2013 14:38:16 +0000

Teco

I see your need, but I would gently suggest that the data diode and/or
crypto scenario should be out of scope for the core standard.

Regards
John

---

From: Teco Boot <[email-masked]>
Date: Wed, 20 Nov 2013 17:11:34 +0100

> crypto scenario should be out of scope for the core standard.

That is why I say it is future work.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 21 Nov 2013 19:47:10 +0000

On Nov 20, 2013, at 2:28 AM, Teco Boot <[email-masked]> wrote:

>> I actually think it makes implementation simpler. The server sends UDP packets occasionally to a well-known port and listens on a TCP port. The client just has to listen ona UDP port; no other cases to handle.

Maybe we are saying the same thing here? What I'm proposing is that the Peer Discovery is sent to a well-known port. But it is sent to an IANA-assigned link-local MCAST address. This peer discovery MAY continue to be sent on a periodic timer pop (with the heuristics of said timer at the discretion of the implementation), or it MAY cease once a TCP connection is established (reference the discussion about multiple DLEP peers existing on the same interface). Where I'm opposed is the notion of the Peer Discovery message being sent to a *unicast* address (what I thought was being described as some Out-of-band operation). I don't like that, it introduces additional protocol complexity, and we've already said that discovery is a 1-hop operation. If you *have* the unicast address to send the Peer Discovery to, then you've already got a-priori config. Either config it, or let it discover, but *NOT* both. Unless there's a *specific* use case you'd like to share - everything I've seen to this point is somewhat vague, and seems to relate to multi-hop operation, which we've also already said introduces a whole lot of assumptions and problems. 

>> With discovery messages always coming in, there's no need to build TCP retry heuristics.
> 

I read the point from Martin and the one from Teco as two different issues. As to the point from Martin - if the a-priori configuration is bad, then fix it. I don't know of a protocol that will somehow mitigate or re-sync bad configuration. That's a really bad idea, IMO. When you take "what the human said" (e.g. the configuration) and somehow munge it around, then the human that configured it in the first place is now ticked off that the code didn't pay attention to his config. I'm adamantly opposed to the notion of *specifying* how a discovery protocol overrides a-priori configuration. IMHO, that will be seen as a security vulnerability, instead of a "feature". 

Now, as to Teco's point. If there are collisions - that being, a TCP connect comes in on the same 4-tuple as an existing connection - the problem should be handled as the current DLEP does it. The older session is immediately terminated, and the new connection is used, starting from the Peer Initialize. This indicates that the two peers have lost state with each other; the only way to recover is to nuke the older, existing session, and pick up anew. 

> No, I want a passive model supported, where a TCP client can set up the connection on the IANA assigned well known DLEP port. Having the port allocated for UDP and TCP isn't a problem, I think. Thi…

No, Teco. Or actually, the answer is "You're *both* right". What's in my current -05 spec is that the TCP port TLV is OPTIONAL. If it's not there, then the connecter falls back to the well-known port number. If it *is* there, it's used. Offers good flexibility, without much complexity.

> May I repeat one of my use cases, where the DLEP (or derivate) protocol passes a crypto device with built in data diode. TCP will not make it here. See http://tools.ietf.org/html/draft-ivancic-mane…

Yes, future work. Waaaaaay in the future. Don't want to get wrapped around the axle of what crypto devices are or are not doing. That will extend this process out ad-nauseum.

Stan

---

From: Martin Duke <[email-masked]>
Date: Fri, 22 Nov 2013 08:23:29 -0800

That would certainly work as well.

On Tue, Nov 19, 2013 at 11:08 PM, Henning Rogge <[email-masked]>wrote:

>> Configuration: I agree that there are no problems if client and server
>> are identically configured. But part of an interoperability spec is not
>>>  2. The modem has the router IP address but not the port. (I believe
>>> the latest concept requires zero standard TCP ports, and the Peer Discovery
>>> can simply include the port number.)
>>>
>>>
>>>>   I agree with almost all of what Stan and Rick said, but I don't
>>>> think it would hurt to have a sentence like "A router MAY send unicast peer
>>>> Yes, we should specify that link-local multicast SHOULD be used (sent
>>>> by the router periodically) and not forwarded.
>>>>