Re: [manet-dlep-rg] DLEP multicast address
Martin Duke <martin.h.duke@gmail.com> Fri, 22 November 2013 16:23 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 16FB21ADEA1 for <manet-dlep-rg@ietfa.amsl.com>; Fri, 22 Nov 2013 08:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level:
X-Spam-Status: No, score=-0.485 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, URIBL_RHS_DOB=1.514] autolearn=no
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 PeUE0PbhzCwP for <manet-dlep-rg@ietfa.amsl.com>; Fri, 22 Nov 2013 08:23:37 -0800 (PST)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0A1ADBE5 for <manet-dlep-rg@ietf.org>; Fri, 22 Nov 2013 08:23:37 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so1042255veb.2 for <manet-dlep-rg@ietf.org>; Fri, 22 Nov 2013 08:23:29 -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=3vCDp9yGOAvQBeRqab/ynpZRJi4Ex/qAWcU2QAFBTPU=; b=HXm6Nv80M8YUR228UavZag9bohh9HaX9wwizt/bINrkxZaY0fLQx5JzU6RbnmprHN0 3hvbbtGqlbDKvbZL7QzQbbzrlDgrUA5pMD5jjdUB0CnWB7ntbuF29zqcBKy3cx63xgWz elUCbfbjAvYHsiAKQyV8MrRiVyv2PyZYvfB8GpjrnvPv0CmMGslpLaFB082QzB2opXPY 0+5Jb0/uexzmyuiSl9KxElsAJ0fG7i71tFLqr7bed1ueUFT18XjRg/vDJeK8ZiWLknNd wHWAVKcVhTSacJ/6qqmkIXM1kPOt/VLG+7dBEcasGQ3hIrUXmuXTKj0ZGstvA4GqrZb/ ozDA==
MIME-Version: 1.0
X-Received: by 10.58.100.244 with SMTP id fb20mr11984608veb.6.1385137409891; Fri, 22 Nov 2013 08:23:29 -0800 (PST)
Received: by 10.220.121.198 with HTTP; Fri, 22 Nov 2013 08:23:29 -0800 (PST)
In-Reply-To: <CAGnRvuqYMPVB+qGe46wa=HktrCNm8aRq0_Zo29HKdscDA5A5Rw@mail.gmail.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> <CAM4esxTJOMyUZ2gHDzmpcOVYsa_zagYfGahS8X6FA-bWWOSiXw@mail.gmail.com> <CAGnRvuqYMPVB+qGe46wa=HktrCNm8aRq0_Zo29HKdscDA5A5Rw@mail.gmail.com>
Date: Fri, 22 Nov 2013 08:23:29 -0800
Message-ID: <CAM4esxQdGGDAhTg9h8ne_nDNRwCtS-W_0V7i=AMuw5R3=QQgcg@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
To: Henning Rogge <hrogge@googlemail.com>
Content-Type: multipart/alternative; boundary="089e013a27084823d304ebc66fe6"
Cc: "manet-dlep-rg@ietf.org Group, (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, "Taylor, Rick" <Rick.Taylor@cassidian.com>, Rick Taylor <rick@tropicalstormsoftware.com>, "Stan Ratliff, (sratliff)" <sratliff@cisco.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: Fri, 22 Nov 2013 16:23:42 -0000
That would certainly work as well. On Tue, Nov 19, 2013 at 11:08 PM, Henning Rogge <hrogge@googlemail.com>wrote: > 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" <martin.h.duke@gmail.com> 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. 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 >>>> >>>> >>>> >>> >> _______________________________________________ >> 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)