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

[Martin Duke <[e-mail]>]

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
>