[manet-dlep-rg] DLEP multicast address

Teco Boot <teco@inf-net.nl> Wed, 13 November 2013 18:31 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 6A23811E813D for <manet-dlep-rg@ietfa.amsl.com>; Wed, 13 Nov 2013 10:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 IFMcR-DK17tR for <manet-dlep-rg@ietfa.amsl.com>; Wed, 13 Nov 2013 10:31:18 -0800 (PST)
Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id D481521E818A for <manet-dlep-rg@ietf.org>; Wed, 13 Nov 2013 10:31:12 -0800 (PST)
Received: by mail-ee0-f46.google.com with SMTP id c4so398190eek.5 for <manet-dlep-rg@ietf.org>; Wed, 13 Nov 2013 10:31:11 -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=EGaery8yBbiHztlY3wUFpEPXwH7bRiQWa/POuKGPwC4=; b=CM2aCV7Xe4ZxbNaW6GwWE8nAibjnmxeiL3JOnv1Zs5DmyPiLhq2muPyQbcxST2ceLB Tq78OdfBTCWc1a8WpbsuOKd8iyEcHeUTaKim+P23LWvXV3iHbgLDRaA6yh6xkWjiHXVq Y26UZI+lPyb2A2Q5tKCVXV2woNaj4iCTzXcPNFDk5CK5dM2VTwfRIhMpfhbsqjumGCwo 9pcFc//Q1hmt5PYR3+mhowBF5Z5fmPpM7mDO8vkAUWLb8UWO8i7VdT8xwdgf2uxPkoGi kvMqOe2mr3xELK1DI2xEe+J1Pjb7mLjkhBkvoP/R8Ld2r57nK2uQ/g3RWojWYY6JJIBk wgDw==
X-Gm-Message-State: ALoCoQkFd2qEF/V8PSoROBbFDB3QZOeqK4n0wMbwGldCvR30HacveVM0SNyWuxxFkv5g/sUlwzGn
X-Received: by 10.15.24.142 with SMTP id j14mr8134293eeu.52.1384367471894; Wed, 13 Nov 2013 10:31:11 -0800 (PST)
Received: from [10.87.201.84] ([88.128.80.6]) by mx.google.com with ESMTPSA id w6sm90781027eeo.12.2013.11.13.10.31.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 10:31:11 -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: <B177F831FB91F242972D0C35F6A0733106FB0AC9@SUCNPTEXM01.com.ad.uk.ds.corp>
Date: Wed, 13 Nov 2013 19:31:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <331538E2-23D3-4642-80FB-3309398BCC1C@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>
To: "Taylor, Rick" <Rick.Taylor@cassidian.com>
X-Mailer: Apple Mail (2.1822)
Cc: Henning Rogge <hrogge@googlemail.com>, "DLEP Research Group (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, Stan Ratliff <sratliff@cisco.com>
Subject: [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 18:31:24 -0000

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