Re: [manet-dlep-rg] DLEP multicast address

Teco Boot <teco@inf-net.nl> Wed, 20 November 2013 16:11 UTC

Return-Path: <teco@inf-net.nl>
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 ED0001AE00C for <manet-dlep-rg@ietfa.amsl.com>; Wed, 20 Nov 2013 08:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 FMexGZJs4SSG for <manet-dlep-rg@ietfa.amsl.com>; Wed, 20 Nov 2013 08:11:51 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 971D11ADF8E for <manet-dlep-rg@ietf.org>; Wed, 20 Nov 2013 08:11:43 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id e52so4145569eek.15 for <manet-dlep-rg@ietf.org>; Wed, 20 Nov 2013 08:11:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=P0RZvWSRs8aw6isfB32IUami8RA9ckUA7wnyJ0/rpTo=; b=eKJkNVQn1ZHyEPvEYYNeuc3D4JBq/Nl6sGZhbjZm1w4gOyZKIaOxb/BmsM1bAe9Fpj UqLrmzlx/PZoz/M4EAchWHQOjMzGCCxg29dKLo8RHM1txfFsziAUZPX3SXBNp10GbQ92 mLzOBxosLYM69HcS8TX7x1L5NYu/S4Oq/THOo0FhhK0XFbIJd59cpfDKJLgvw1R4n9BZ wGJNaBychb+CT2r8Mh4UE1NFgATHq6EFYCJxSLs6eAU6KLHl2c6BqgbB1lNZw1vrDRX3 9xaapziCmARRC/185hjwGbDkitDLNiBegRT5przmiFRsV3314A2HEEG7wW6Nq9a/yHK2 PBNg==
X-Gm-Message-State: ALoCoQlcVh6i6c7ZTH1eddRQFtZ4DOIrAElYOB40ZtXp+IBVybZUA4xY1xupsN82HwPvPEO2gnwR
X-Received: by 10.14.4.200 with SMTP id 48mr1956141eej.38.1384963896992; Wed, 20 Nov 2013 08:11:36 -0800 (PST)
Received: from [10.175.173.38] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id a45sm44357311eem.6.2013.11.20.08.11.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 08:11:36 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <CAEhHF6WxMfa6003je9f_TfwaCoxs90a6g=zy5Uu7emPs+Cmocg@mail.gmail.com>
Date: Wed, 20 Nov 2013 17:11:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0A04AA5-A3A9-48D4-A7AB-48A38D642578@inf-net.nl>
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> <B177F831FB91F242972 D0C35F6A0733106FB0AC9@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> <F5C2EE51-0338-4B2D-B672-6B3D27CBC006@inf-net.nl> <CAEhHF6WxMfa6003je9f_TfwaCoxs90a6g=zy5Uu7emPs+Cmocg@mail.gmail.com>
To: John Dowdell <john.dowdell.ietf@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: "manet-dlep-rg@ietf.org Group, (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>, Martin Duke <martin.h.duke@gmail.com>, Stan Ratliff <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: Wed, 20 Nov 2013 16:11:55 -0000

Op 20 nov. 2013, om 15:38 heeft John Dowdell <john.dowdell.ietf@gmail.com> het volgende geschreven:

> Teco
> 
> I see your need, but I would gently suggest that the data diode and/or
> crypto scenario should be out of scope for the core standard.

That is why I say it is future work.

Teco

> 
> Regards
> John
> 
> On 20 November 2013 07:28, Teco Boot <teco@inf-net.nl> wrote:
>> 
>> Op 20 nov. 2013, om 06:36 heeft Martin Duke <martin.h.duke@gmail.com> het volgende geschreven:
>> 
>>> I actually think it makes implementation simpler. The server sends UDP packets occasionally to a well-known port and listens on a TCP port. The client just has to listen ona UDP port; no other cases to handle. With discovery messages always coming in, there's no need to build TCP retry heuristics.
>> 
>> This is the model I had in mind.
>> No need to specify TCP retry mechanism or wait for a discovery packet, both are fine.
>> 
>> 
>>> Configuration: I agree that there are no problems if client and server are identically configured. But part of an interoperability spec is not providing ways for client and server to get out of sync.
>> 
>> This needs collision handling. When two TCP connections are set up, one has to be cleared. During the period that two connections are active, it is difficult to predict what will happen with order messages.
>> 
>> 
>>> Regardless, I suggest the Peer Discovery contain the TCP server port, and that if there is no Peer Discovery message the configuration must include the server port. That way, we need only get the UDP port number from IANA.
>> 
>> No, I want a passive model supported, where a TCP client can set up the connection on the IANA assigned well known DLEP port. Having the port allocated for UDP and TCP isn't a problem, I think. This enables multi-hop reachability to (or from) the modem. I don't know how to do that _from_ the modem.
>> 
>> 
>> May I repeat one of my use cases, where the DLEP (or derivate) protocol passes a crypto device with built in data diode. TCP will not make it here. See http://tools.ietf.org/html/draft-ivancic-manet-modemlpa Figure 5 for description of this use case (thanks to authors of modemlpa). I have to use some kind of DLEP proxy/tunnel, making the protocol uni-directional tunnel. For now, I see standardization of such mechanism as future work.
>> 
>> 
>> Teco
>> 
>> 
>>> 
>>> On Nov 19, 2013 9:47 AM, "Stan Ratliff (sratliff)" <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
>> 
>> _______________________________________________
>> manet-dlep-rg mailing list
>> manet-dlep-rg@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg