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

[Teco Boot <[e-mail]>]

Op 13 nov. 2013, om 21:12 heeft Henning Rogge <[e-mail]> het volgende geschreven:

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

Maybe stick to what we already have: 802.1D L2 (a.k.a. Ethernet) and L3 connections to Internet or private backbone.

Are you aware of L2 VPNs other than 802.1D that needs DLEP?

Teco


> 
> 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
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg