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

[Henning Rogge <[e-mail]>]

Are we still talking about switching the tcp-server socket and the
originator of the multicast discovery packet?

Henning Rogge

On Thu, Nov 14, 2013 at 4:16 PM, Martin Duke <[e-mail]> wrote:
> 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" <[e-mail]> wrote:
>>
>> > From: [e-mail] [mailto:manet-dlep-rg-
>> > [e-mail]] 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
>> >
>> > 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
>> The information contained within this e-mail and any files attached to
>> this e-mail is private and in addition may include commercially sensitive
>> information. The contents of this e-mail are for the intended recipient only
>> and therefore if you wish to disclose the information contained within this
>> e-mail or attached files, please contact the sender prior to any such
>> disclosure. If you are not the intended recipient, any disclosure, copying
>> or distribution is prohibited. Please also contact the sender and inform
>> them of the error and delete the e-mail, including any attached files from
>> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
>> http://www.cassidian.com
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>
>
> _______________________________________________
> 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