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

Martin Duke <martin.h.duke@gmail.com> Tue, 19 November 2013 06:28 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 B055A1A1F62 for <manet-dlep-rg@ietfa.amsl.com>; Mon, 18 Nov 2013 22:28:20 -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 4R-WFFI7BaJX for <manet-dlep-rg@ietfa.amsl.com>; Mon, 18 Nov 2013 22:28:18 -0800 (PST)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BDE371A1F76 for <manet-dlep-rg@ietf.org>; Mon, 18 Nov 2013 22:28:14 -0800 (PST)
Received: by mail-ve0-f175.google.com with SMTP id jx11so1203198veb.6 for <manet-dlep-rg@ietf.org>; Mon, 18 Nov 2013 22:28:08 -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=fOubqZKXnLPl8WhDC+w2OJQ3G7NpikuVhn1B1HdTrBg=; b=ueUGJLfbxqAxs1/2NxwPRfIXAScBL+EQV6qv9aiDRAJ9+Nz4fr1ZKLmKwKQkrkiYqv HIm8xXmdzaJP4vQUbdVbUXxG5Pe3JWWobWkzCiHXDREoIN/F9nEAQeK06PHmiQJG/rk4 Ooa+x7Wescguk7Sf5c5tv6fr6MBMvWKzuhYp1sBygF1YZmsvtVwW+CXqg58J12qDNnfD C4lWBxRBhRW4gKVkU5LuHDFEYq+c866jJNEp75g7ev2MaMPzFN2hLpelFxEwTMF/8SSa f2bMva0TGCYFxUQZm2PLznmNQljoIoXonCqSq3hzkiUMM2sN8ZpEkT7HzOe2VMcODmmg su3A==
MIME-Version: 1.0
X-Received: by 10.52.243.138 with SMTP id wy10mr16567762vdc.2.1384842488629; Mon, 18 Nov 2013 22:28:08 -0800 (PST)
Received: by 10.220.121.198 with HTTP; Mon, 18 Nov 2013 22:28:08 -0800 (PST)
In-Reply-To: <FB72E736-02BF-444B-8B3B-F96E45E4DEA6@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>
Date: Mon, 18 Nov 2013 22:28:08 -0800
Message-ID: <CAM4esxTdh_VkuYH33CMEyqd6u7gY5u9PxPhVd1eGeEBey1N=ig@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c1c4a69acdc204eb81c4d8"
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: Tue, 19 Nov 2013 06:28:20 -0000

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.

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.)

3. The modem has the peer address, but powers up first; the TCP SYN gets no
reply, backs off and times out.

Clearly it is much cleaner for the router to send a UDP packet where we
control the frequency and timeout.

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<javascript:_e({}, 'cvml', '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
>
>
>