Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
"Stan Ratliff (sratliff)" <sratliff@cisco.com> Thu, 14 November 2013 17:23 UTC
Return-Path: <sratliff@cisco.com>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9677221E8098 for <manet-dlep-rg@ietfa.amsl.com>; Thu, 14 Nov 2013 09:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.799
X-Spam-Level:
X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpqwM81JD5fo for <manet-dlep-rg@ietfa.amsl.com>; Thu, 14 Nov 2013 09:22:56 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB621E80F7 for <manet-dlep-rg@ietf.org>; Thu, 14 Nov 2013 09:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25461; q=dns/txt; s=iport; t=1384449776; x=1385659376; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7sjXAAX9w3fXvxVhI/BPMZUyuNdI5ewCYO3WVabiwF8=; b=fGhIPGbXzZ1PCkBReVDDJXgdwhGy8USDfaczEeEggJxRXFhigZYA9vMH xMVG5G0S0sgZNBnKi5bDMdmBYRs6VDfZzWSV89wZ1vA34ZPHjp3QqQGW3 NiMw+eIJuVxcvU57WzNYvrCgwSDH6QC0+4Bm1YTo4iWNutsqCXt/VM7n4 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFANIFhVKtJV2b/2dsb2JhbABagwc4U78hgSAWdIIlAQEBAwEBAQEXDRMbGQsFBwQCAQgRBAEBAR4JByEGCxQJCAIECgQFh28DCQYNtmgNiT+MbYEzBoEGCAUmBwIEgxqBEQONd4Y3gXeBa4xUhTiDKIFoCRci
X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284839552"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 17:22:55 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAEHMtqG017582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 17:22:55 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:22:54 -0600
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
Thread-Topic: [manet-dlep-rg] notes DLEP meeting @ IETF88
Thread-Index: Ac7cIBudyZKg9mGDQHuqmsLjfRuq7AARupUAAAB71YAAFTiyEAAnl5cAAGWXcLAAEXwqAAAPOSzQ//+zlgCAAIWGIP//rykAgACEnYCAAAZpgP//4IDwgADRGQCAAIQDgP/+T9rQAINX0YAAAAxeAAAB0yeAAABipYAAAg/zAA==
Date: Thu, 14 Nov 2013 17:22:54 +0000
Message-ID: <2946A574-0660-4643-8FC8-8BA1E86A1360@cisco.com>
References: <72FB622921C13746AD6349E70A8D9F307D9192F7@EXC-MBX03.tsn.tno.nl> <CAK=bVC85XAXR3Zkwq+JwELF-dvgrKwbowWCvwvnjeVn7VStnbw@mail.gmail.com> <72FB622921C13746AD6349E70A8D9F307D9193CD@EXC-MBX03.tsn.tno.nl> <5A8A5085482DA84995F4E70F5093AB50268E6C@XCH-BLV-503.nw.nos.boeing.com> <B2BA430A-F4E6-4DED-A7BB-7282A22802B7@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50269139@XCH-BLV-503.nw.nos.boeing.com> <DAAF2F4E-8918-4708-8D68-4792A919541B@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB502691C9@XCH-BLV-503.nw.nos.boeing.com> <EBD19831-B87C-4F37-B028-E00687B59FE1@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB5026926A@XCH-BLV-503.nw.nos.boeing.com> <51F083CF-62B8-4858-9C3D-5D48BFE6D8BE@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50269348@XCH-BLV-503.nw.nos.boeing.com> <57D01331-8D30-4A02-A2BA-B644DBA7A808@inf-net.nl> <5A8A5085482DA84995F4E70F5093AB50269934@XCH-BLV-503.nw.nos.boeing.com> <4840CBE1-5710-4AA1-A6F2-B8A65DE98F25@inf-net.nl> <6b9b8b9f-ad60-4128-88dd-4ecccc91526d@SUCNPTEXC01.COM.A D.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FB0F3F@SUCNPTEXM01.com.ad.uk.ds.corp> <CAM4esxQx4L+=8j_EsKf6zJf=405Wn1fffUEfhRq092N3=72SoQ@mail.gmail.com> <CAGnRvuo2iRwFGYB18gjbJnZQhc2rkWhOr1voXE0zkOhGVhq1sQ@mail.gmail.com>, <6EB41DAA-4AD6-4E1D-B497-90275673A508@inf-net.nl> <38A5475DE83986499AEACD2CFAFC3F98FA593DAC@tss-server1.home.tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98FA593DAC@tss-server1.home.tropicalstormsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.102.41.107]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C507F3BEA495AF44AD60FC1099BAF6D3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "DLEP Research Group (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>
Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 17:23:01 -0000
+1 On Nov 14, 2013, at 11:23 AM, Rick Taylor <rick@tropicalstormsoftware.com> wrote: > 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: manet-dlep-rg-bounces@ietf.org [manet-dlep-rg-bounces@ietf.org] on behalf of Teco Boot [teco@inf-net.nl] > Sent: 14 November 2013 16:12 > To: Henning Rogge > Cc: Duke, Martin; DLEP Research Group (manet-dlep-rg@ietf.org); Martin Duke; Taylor, Rick > Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 > > Op 14 nov. 2013, om 16:20 heeft Henning Rogge <hrogge@googlemail.com> het volgende geschreven: > >> 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 > > >> >> Henning Rogge >> >> On Thu, Nov 14, 2013 at 4:19 PM, Martin Duke <martin.h.duke@gmail.com> wrote: >>> 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" <Rick.Taylor@cassidian.com> 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. >>>> >>>> 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 >>>> >>>>> -----Original Message----- >>>>> From: manet-dlep-rg-bounces@ietf.org [mailto:manet-dlep-rg- >>>>> bounces@ietf.org] On Behalf Of Duke, Martin >>>>> Sent: 12 November 2013 16:57 >>>>> To: teco@inf-net.nl >>>>> Cc: manet-dlep-rg@ietf.org >>>>> Subject: Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 >>>>> >>>>> Teco, >>>>> >>>>> It seems like there are two competing proposals for session >>>>> initialization. Yours: >>>>> >>>>>>> Router Modem Message Description >>>>>>> ==================================================================== >>>>>>> >>>>>>> <-------Peer Discovery--------- Modem initiates discovery >>>>>>> with server TCP port ... >>>>>>> <-------Peer Discovery--------- Repeats discovery forever >>>>>>> ... >>>>>>> >>>>>>> ------------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 >>>>> >>>>> And Stan's: >>>>> >>>>> Router Modem Message Description >>>>> ====================================================== >>>>> <------------------------ 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. >>>>> 2) Given #1, I agree with Stan the Peer Offer has to come outside the >>>>> TCP >>>>> connection to provide the port number. >>>>> 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 >>>>> >>>>> -----Original Message----- >>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>> Sent: Tuesday, November 12, 2013 8:33 AM >>>>> To: Duke, Martin >>>>> Cc: manet-dlep-rg@ietf.org >>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>> >>>>> >>>>> Op 12 nov. 2013, om 17:04 heeft Duke, Martin <Martin.Duke@boeing.com> >>>>> 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 >>>>> >>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>> Sent: Monday, November 11, 2013 9:57 PM >>>>>> To: Duke, Martin >>>>>> Cc: manet-dlep-rg@ietf.org >>>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>>> >>>>>> >>>>>> Op 11 nov. 2013, om 22:45 heeft Duke, Martin <Martin.Duke@boeing.com> >>>>> 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 >>>>>> >>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>>> Sent: Monday, November 11, 2013 1:39 PM >>>>>>> To: Duke, Martin >>>>>>> Cc: manet-dlep-rg@ietf.org >>>>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Router Modem Message Description >>>>>>> ==================================================================== >>>>>>> >>>>>>> <-------Peer Discovery--------- Modem initiates discovery >>>>>>> with server TCP port ... >>>>>>> <-------Peer Discovery--------- Repeats discovery forever >>>>>>> ... >>>>>>> >>>>>>> ------------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 >>>>>>> >>>>>>> <=============================> 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 DLEP 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. 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 <Martin.Duke@boeing.com> >>>>> 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. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>>>> Sent: Monday, November 11, 2013 10:31 AM >>>>>>>> To: Duke, Martin >>>>>>>> Cc: manet-dlep-rg@ietf.org >>>>>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>>>>> >>>>>>>> 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 >>>>>>>> <Martin.Duke@boeing.com> >>>>> 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 >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>>>>> Sent: Monday, November 11, 2013 7:48 AM >>>>>>>>> To: Duke, Martin >>>>>>>>> Cc: manet-dlep-rg@ietf.org >>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> <Martin.Duke@boeing.com> >>>>> 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 >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Teco Boot [mailto:teco@inf-net.nl] >>>>>>>>>> Sent: Friday, November 08, 2013 10:59 PM >>>>>>>>>> To: Duke, Martin >>>>>>>>>> Cc: DLEP Research Group (manet-dlep-rg@ietf.org) >>>>>>>>>> Subject: Re: notes DLEP meeting @ IETF88 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <Martin.Duke@boeing.com> >>>>> 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:Ronald.intVelt@tno.nl] >>>>>>>>>>> Sent: Thursday, November 07, 2013 5:58 PM >>>>>>>>>>> To: Ulrich Herberg >>>>>>>>>>> Cc: john.dowdell@cassidian.com; john.dowdell486@gmail.com; >>>>>>>>>>> Rick.Taylor@cassidian.com; Duke, Martin; Teco Boot >>>>>>>>>>> (teco@inf-net.nl); sratliff@cisco.com; Henning Rogge >>>>>>>>>>> (hrogge@googlemail.com); jpmacker@gmail.com; bcheng@ll.mit.edu >>>>>>>>>>> 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:ulrich@herberg.name] >>>>>>>>>>>> Sent: vrijdag 8 november 2013 2:44 >>>>>>>>>>>> To: Velt, R. (Ronald) in 't >>>>>>>>>>>> Cc: john.dowdell@cassidian.com; john.dowdell486@gmail.com; >>>>>>>>>>>> Rick.Taylor@cassidian.com; Martin.Duke@boeing.com; Teco Boot >>>>>>>>>>>> (teco@inf- net.nl); sratliff@cisco.com; Henning Rogge >>>>>>>>>>>> (hrogge@googlemail.com); jpmacker@gmail.com; bcheng@ll.mit.edu >>>>>>>>>>>> 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 >>>>>>>>>>>> <Ronald.intVelt@tno.nl> >>>>>>>>>>>> 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 >>>>> manet-dlep-rg@ietf.org >>>>> 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 >>>> _______________________________________________ >>>> manet-dlep-rg mailing list >>>> manet-dlep-rg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg >>> >>> >>> _______________________________________________ >>> manet-dlep-rg mailing list >>> manet-dlep-rg@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg >>> >> >> >> >> -- >> 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 > > _______________________________________________ > manet-dlep-rg mailing list > manet-dlep-rg@ietf.org > https://www.ietf.org/mailman/listinfo/manet-dlep-rg > _______________________________________________ > manet-dlep-rg mailing list > manet-dlep-rg@ietf.org > https://www.ietf.org/mailman/listinfo/manet-dlep-rg
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Joe Macker
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- [manet-dlep-rg] Mandatory processing TLVs by rout… Teco Boot
- [manet-dlep-rg] Resources TLV Teco Boot
- [manet-dlep-rg] Latency Teco Boot
- [manet-dlep-rg] Rename Neighbor to Destination Teco Boot
- [manet-dlep-rg] Peer termination Teco Boot
- [manet-dlep-rg] DLEP session establishment Teco Boot
- [manet-dlep-rg] Multicast in dlep-04 Teco Boot
- Re: [manet-dlep-rg] Resources TLV Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Peer termination Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Multicast in dlep-04 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Henning Rogge
- [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] Resources TLV Teco Boot
- Re: [manet-dlep-rg] Peer termination Teco Boot
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Multicast in dlep-04 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Taylor, Rick
- Re: [manet-dlep-rg] Peer termination Taylor, Rick
- Re: [manet-dlep-rg] Resources TLV Taylor, Rick
- Re: [manet-dlep-rg] Resources TLV Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] Latency Henning Rogge
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Latency Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Latency Henning Rogge
- Re: [manet-dlep-rg] Peer termination Teco Boot
- Re: [manet-dlep-rg] Latency Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Peer termination Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- [manet-dlep-rg] Draft-04 text Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Peer termination Taylor, Rick
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] Latency Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] Draft-04 text Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] Draft-04 text Taylor, Rick
- Re: [manet-dlep-rg] Latency Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] DLEP TLV length Taylor, Rick
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Teco Boot
- Re: [manet-dlep-rg] Latency Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP TLV length Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Latency Teco Boot
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] Latency Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Resources TLV Ulrich Herberg
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP multicast address Martin Duke
- Re: [manet-dlep-rg] DLEP multicast address Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] Resources TLV Ulrich Herberg
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] Latency Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] Mandatory processing TLVs by … Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Dowdell, John
- Re: [manet-dlep-rg] DLEP session establishment Henning Rogge
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Dowdell, John
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] Resources TLV Taylor, Rick
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] DLEP session establishment Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP session establishment Taylor, Rick
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] DLEP session establishment Teco Boot
- [manet-dlep-rg] manet-dlep-rg: Martin's membership Teco Boot
- Re: [manet-dlep-rg] manet-dlep-rg: Martin's membe… Ulrich Herberg
- Re: [manet-dlep-rg] manet-dlep-rg: Martin's membe… Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] DLEP multicast address John Dowdell
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] DLEP multicast address Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Duke, Martin
- Re: [manet-dlep-rg] manet-dlep-rg: Martin's membe… Duke, Martin
- Re: [manet-dlep-rg] DLEP multicast address Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Martin Duke
- Re: [manet-dlep-rg] DLEP multicast address Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] DLEP multicast address Teco Boot
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] DLEP multicast address Taylor, Rick
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Taylor, Rick
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Martin Duke
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Henning Rogge
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Rick Taylor
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Rick Taylor
- Re: [manet-dlep-rg] DLEP multicast address Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Rick Taylor
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Teco Boot
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Rick Taylor
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Rick Taylor
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] notes DLEP meeting @ IETF88 Henning Rogge
- Re: [manet-dlep-rg] DLEP multicast address Martin Duke
- [manet-dlep-rg] TCP clients, servers, and discove… Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Taylor, Rick
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Taylor, Rick
- Re: [manet-dlep-rg] TCP clients, servers, and dis… John Dowdell
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] TCP clients, servers, and dis… John Dowdell
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Taylor, Rick
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Henning Rogge
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Rick Taylor
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Stan Ratliff (sratliff)
- Re: [manet-dlep-rg] TCP clients, servers, and dis… Teco Boot
- Re: [manet-dlep-rg] DLEP multicast address Martin Duke
- Re: [manet-dlep-rg] DLEP multicast address Stan Ratliff (sratliff)