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

[Rick Taylor <[e-mail]>]

+1 - Good point, I think we need to suggest some final text for this whole discovery process soon or we will forget our rough consensus.

Rick (on his other email address)

________________________________
From: [e-mail] [[e-mail]] on behalf of Martin Duke [[e-mail]]
Sent: 14 November 2013 15:16
To: Taylor, Rick
Cc: [e-mail] Group ([e-mail]); Stan Ratliff (sratliff)
Subject: Re: [manet-dlep-rg] DLEP multicast address


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]<mailto:[e-mail]>> wrote:
> From: [e-mail]<mailto:[e-mail]> [mailto:manet-dlep-rg-<mailto:manet-dlep-rg->
> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:
> >> Changed subject.
> >>
> >> Op 13 nov. 2013, om 17:37 heeft Taylor, Rick
> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet-dlep-rg