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

Teco Boot <teco@inf-net.nl> Wed, 13 November 2013 21:03 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1F511E8179 for <manet-dlep-rg@ietfa.amsl.com>; Wed, 13 Nov 2013 13:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.324
X-Spam-Level:
X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 JVDSyJOJm3N4 for <manet-dlep-rg@ietfa.amsl.com>; Wed, 13 Nov 2013 13:03:43 -0800 (PST)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4CC21E80B3 for <manet-dlep-rg@ietf.org>; Wed, 13 Nov 2013 13:03:34 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id b57so441691eek.12 for <manet-dlep-rg@ietf.org>; Wed, 13 Nov 2013 13:03:33 -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=C61fCqDVUo3ZKTNDwYstrfoQ+tsYle7ADf3RVQyefJY=; b=GL3427I+niCk9iyqvUbG2l1Jceo/5sl/vMGA/hw6F55JOgPx6QrFpbv34Su2fWc/GN h61oFiVJ4/8/PSLuH6PYSkDcylzMfB/W8xqH7bneYg3fv2oXVzI3HcqGTvwa9xDMmiJD yduMYAWy0P0SsZ0xjzu0LxaTMWAYAQy11fe2Ort5xBYJ0iEHNKATVt6qq1G+QjT66Nx6 84vk1zwFuFqQm49hs9QdJbSf8Y9+cytjVZ5SHF9QWrQzYE0Xms6QeuSKG7gkDOhiiwX5 Hrv3Uk3xhnhFUO6U96qjd0ZTyT3Zvfqf8id7H6N7Q9W47AgbAodWPVeCm8ebNkMOEDSs wKsA==
X-Gm-Message-State: ALoCoQkoQxZornw1ewFUsZiZ86PkjShRCDvhYAhzfRJC/WCuQNj4ycE+9/dRDwjkdbIwNkLp/spe
X-Received: by 10.15.111.196 with SMTP id cj44mr1052709eeb.94.1384376613605; Wed, 13 Nov 2013 13:03:33 -0800 (PST)
Received: from [10.175.173.29] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id 44sm11659957eek.5.2013.11.13.13.03.31 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 13:03:32 -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: <577D2FCC-2B44-4D6C-B29F-BAE898AC867F@cisco.com>
Date: Wed, 13 Nov 2013 22:03:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D623941-C326-43C7-AFEB-EFD6F2F29DBE@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> <2dde64e4-2a 4a-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> <577D2FCC-2B44-4D6C-B29F-BAE898AC867F@cisco.com>
To: Stan Ratliff <sratliff@cisco.com>
X-Mailer: Apple Mail (2.1822)
Cc: "manet-dlep-rg@ietf.org Group (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>
Subject: Re: [manet-dlep-rg] DLEP multicast address
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: Wed, 13 Nov 2013 21:03:48 -0000

Op 13 nov. 2013, om 21:08 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:

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

I think you mix up multi-hop L2 and multi-hop L3.

Teco


> 
> Stan
> 
> On Nov 13, 2013, at 2:45 PM, Henning Rogge <hrogge@googlemail.com> wrote:
> 
>> Why should we need to ask IEEE? Just use the standard IP mac addresses
>> for the linklocal IPs.
>> 
>> The Modem can filter them based on IP content out of the bridge.
>> Henning Rogge
>> 
>> On Wed, Nov 13, 2013 at 7:31 PM, Teco Boot <teco@inf-net.nl> wrote:
>>> Changed subject.
>>> 
>>> Op 13 nov. 2013, om 17:37 heeft Taylor, Rick <Rick.Taylor@cassidian.com> het volgende geschreven:
>>>> 
>>>>> 
>>>>> Sending the multicast from router to modem (and having the TCP server on
>>>>> router) adds some complexity on the modem, in that this multicast packet
>>>>> shall not be forwarded over the modem link (e.g. RF path). Cannot be done
>>>>> with L2 MAC filter, as this would block a set of multicast addresses. The
>>>>> filter has to block the assigned IANA DLEP multicast address.
>>>>> LLDP better fits our requirement for discovery. It doesn't take away the
>>>>> need for the multicast Peer_Discovery. On the other hand, LLDP is not
>>>>> widely implemented, I think. And would be bridged on modems that doesn't
>>>>> support it.
>>>> 
>>>> I agree, but I imagined Peer_Discovery being link-local multicast/broadcast.  You are right that a multi-hop scoped multicast is a nightmare.
>>> 
>>> Link-local is not sufficient. We need L2-link-local multicast address. We have to go to IEEE802 to allocate such. Even then, it takes ages to get it implemented.
>>> 
>>> The best we can do is specify the modem MUST NOT forward the DLEP link-local multicast packets to the link to the remote nodes. If the modem has an ethernet bridge function (as devices I have), this DLEP link-local multicast filter MUST NOT be implemented on the ethernet ports.
>>> 
>>> I’m still puzzled how it can work with cascaded devices, for example to connect a satcom system somewhere further away from the router using an Ethernet extender. Maybe use DLEP link-local for the local attached device and configure something on router (keep the satcom modem a dummy device) to reach the satcom modem with a unicast Peer_Discovery.
>>> 
>>> 
>>>> 
>>>> And yes, perhaps we should be using mDNS/Bonjour for discovery rather than re-inventing the wheel here.
>>> 
>>> Not these ones. These shall be forwarded to remote nodes, to keep existing stuff going.
>>> 
>>> 
>>>> 
>>>> Should we put in some text: "Unless there is an alternative discovery protocol in use, such as a-priori static configuration or mDNS, then Peer_Discovery messages SHOULD be sent every X seconds to the link-local multicast address”
>>> 
>>> Or:
>>> The Router SHOULD send Peer_Discovery messages every Peer_Discovery_Interval seconds to the DLEP assigned link-local multicast address on DLEP enabled interfaces. Alternative mechanism may be used, such as a-priori static configuration or alternative discovery protocol.
>>> The Modem initiates a DLEP TCP connection on reception and successful validation of a DLEP Peer_Discovery message, either received with a DLEP assigned link-local multicast address or on a Modem configured unicast address.
>>> 
>>> This unicast Peer_Discovery packet is a disadvantage of having TCP server on the router. If one finds an improvement, I’m all ears.
>>> 
>>> 
>>> Teco
>> 
>> 
>> 
>> -- 
>> 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