Re: [manet-dlep-rg] DLEP multicast address
Martin Duke <martin.h.duke@gmail.com> Wed, 20 November 2013 05:36 UTC
Return-Path: <martin.h.duke@gmail.com>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DAC1AE30B for <manet-dlep-rg@ietfa.amsl.com>; Tue, 19 Nov 2013 21:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4XOiq_27DrC for <manet-dlep-rg@ietfa.amsl.com>; Tue, 19 Nov 2013 21:36:33 -0800 (PST)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FA1AE11A for <manet-dlep-rg@ietf.org>; Tue, 19 Nov 2013 21:36:33 -0800 (PST)
Received: by mail-vc0-f176.google.com with SMTP id lf12so1054194vcb.35 for <manet-dlep-rg@ietf.org>; Tue, 19 Nov 2013 21:36:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0a9mSOSDvK8TtKNVpkw6zUsYTMBB+kUNDVy6arte6g0=; b=CKZmNXDTj5M4YhOQzNsb6/hnH4wKYpV8e1z5wfNKs5S0neNUsKOrdv7ZWXwsztu1qn kXUN7N/veYnbGEnOd9ulS6FdG3nUNrgMBFssUnQyHGmDwXd0/MbtMI/7bV7yXHclMqei omciVn4ngcziGv5U2035ivoAmpOlW4iBbKAHQo+xsgwn8KKEmZV2o7ORmxBG70wNZyyv 1ye3Dj8T5vfkCB/tD2VYJoZ754HCFxDPOs1hyWbjQr92TaDWx4As0GTXPEjqCvjZfK5P hHU5gtjHbf0JDeLkVfNpWDtrBYwoBG21QEiqRG9zRuq63D6J3F/ao3ynwhKUVis1vaBj pteA==
MIME-Version: 1.0
X-Received: by 10.58.39.97 with SMTP id o1mr24862865vek.15.1384925787029; Tue, 19 Nov 2013 21:36:27 -0800 (PST)
Received: by 10.220.121.198 with HTTP; Tue, 19 Nov 2013 21:36:26 -0800 (PST)
In-Reply-To: <BB87C522-651D-4F3E-8D9D-D0055F590C92@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> <D02397F1-9D1B-4B36-81D0-4585ACDBA34A@gmail.com> <5D184300-2D97-4EC1-8D91-76D4A79B2BDA@inf-net.nl> <DDAE98C5-520E-4F8F-9F9B-2AB9A15A70EF@cisco.com> <0541163b-2d1c-4afd-ad06-ba9a25744310@SUCNPTEXC01.COM.AD.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FB0425@SUCNPTEXM01.com.ad.uk.ds.corp> <14B5C326-6499-439D-BC23-BB39A376825C@cisco.com> <CAGnRvuoxD_dxdoD_8qbHhq--6AF=2B7wNFEE5Xz=vKNwnBhhZw@mail.gmail.com> <9EB171E6-62E6-4136-BFDB-6FEB8DF23B74@cisco.com> <cb165b80-275e-45ff-ae0e-8ca5354a3568@SUCNPTEXC01.COM.AD.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FB081B@SUCNPTEXM01.com.ad.uk.ds.corp> <1EFB06F8-05B2-4A4B-8A6B-DDDB946B7D01@cisco.com> <2dde64e4-2a4a-4eb2-9717-4a9ffb8be0eb@SUCNPTEXC01.COM.AD.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FB0AC9@SUCNPTEXM01.com.ad.uk.ds.corp> <331538E2-23D3-4642-80FB-3309398BCC1C@inf-net.nl> <CAGnRvuq_63eQgKBncECMMYBJPcyG-XxTPRRK7h9hVY5Nc6vx4g@mail.gmail.com> <539cfe69-ecd3-47cf-b623-965dca5e580c@SUCNPTEXC01.COM.AD.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FB0F29@SUCNPTEXM01.com.ad.uk.ds.corp> <CAM4esxRNnWqd9LivxpoWMgJ1SBoPe7wYJk9kpwUVsXD-rMkyTg@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98FA593C5A@tss-server1.home.tropicalstormsoftware.com> <FB72E736-02BF-444B-8B3B-F96E45E4DEA6@cisco.com> <CAM4esxTdh_VkuYH33CMEyqd6u7gY5u9PxPhVd1eGeEBey1N=ig@mail.gmail.com> <BB87C522-651D-4F3E-8D9D-D0055F590C92@cisco.com>
Date: Tue, 19 Nov 2013 21:36:26 -0800
Message-ID: <CAM4esxTJOMyUZ2gHDzmpcOVYsa_zagYfGahS8X6FA-bWWOSiXw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
To: "Stan Ratliff, (sratliff)" <sratliff@cisco.com>
Content-Type: multipart/alternative; boundary="089e011834d89386be04eb9529fd"
Cc: "manet-dlep-rg@ietf.org Group, (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>, "Taylor, Rick" <Rick.Taylor@cassidian.com>
Subject: Re: [manet-dlep-rg] DLEP multicast address
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 20 Nov 2013 05:36:37 -0000
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)" <sratliff@cisco.com> wrote: > > On Nov 19, 2013, at 1:28 AM, Martin Duke <martin.h.duke@gmail.com> 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 > > > 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 >> 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 < >> rick@tropicalstormsoftware.com> >> 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. >> >> Rick (on his other email address) >> >> ------------------------------ >> *From:* manet-dlep-rg-bounces@ietf.org [manet-dlep-rg-bounces@ietf.org] >> on behalf of Martin Duke [martin.h.duke@gmail.com] >> *Sent:* 14 November 2013 15:16 >> *To:* Taylor, Rick >> *Cc:* manet-dlep-rg@ietf.org Group (manet-dlep-rg@ietf.org); 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" <Rick.Taylor@cassidian.com> >> wrote: >> >> > From: manet-dlep-rg-bounces@ietf.org [mailto:manet-dlep-rg- >> > bounces@ietf.org] On Behalf Of Stan Ratliff (sratliff) >> > Subject: Re: [manet-dlep-rg] DLEP multicast address >> > >> > +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. >> >> 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 >> >> > >> > Stan >> >> >> >
- 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)