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

[Henning Rogge <[e-mail]>]

And you can always either use a proxy to extend the reach of the
linklocal multicast or use a layer-2 VPN.

Henning Rogge

On Wed, Nov 13, 2013 at 9:08 PM, Stan Ratliff (sratliff)
<[e-mail]> wrote:
> +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.
>
> Stan
>
> On Nov 13, 2013, at 2:45 PM, Henning Rogge <[e-mail]> 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 <[e-mail]> wrote:
>>> Changed subject.
>>>
>>> Op 13 nov. 2013, om 17:37 heeft Taylor, Rick <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg



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