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

["Stan Ratliff (sratliff)" <[e-mail]>]

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



On Nov 10, 2013, at 5:00 AM, Teco Boot <[e-mail]> wrote:

> 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
> 
> 
> Op 9 nov. 2013, om 23:57 heeft Joe Macker <[e-mail]> het volgende geschreven:
> 
>> 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 <[e-mail]> wrote:
>>> 
>>> 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 <[e-mail]> 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.
>>>> 
>>>> -----Original Message-----
>>>> From: Velt, R. (Ronald) in 't [mailto:[e-mail]] 
>>>> Sent: Thursday, November 07, 2013 5:58 PM
>>>> To: Ulrich Herberg
>>>> Cc: [e-mail]; [e-mail]; [e-mail]; Duke, Martin; Teco Boot ([e-mail]); [e-mail]; Henning Rogge ([e-mail]); [e-mail]; [e-mail]
>>>> Subject: RE: notes DLEP meeting @ IETF88
>>>> 
>>>> 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:[e-mail]]
>>>>> Sent: vrijdag 8 november 2013 2:44
>>>>> To: Velt, R. (Ronald) in 't
>>>>> Cc: [e-mail]; [e-mail]; 
>>>>> [e-mail]; [e-mail]; Teco Boot (teco@inf- 
>>>>> net.nl); [e-mail]; Henning Rogge ([e-mail]); 
>>>>> [e-mail]; [e-mail]
>>>>> 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 
>>>>> <[e-mail]>
>>>>> 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.
>>> 
>>> _______________________________________________
>>> manet-dlep-rg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg