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

[Martin Duke <[e-mail]>]

That would certainly work as well.


On Tue, Nov 19, 2013 at 11:08 PM, Henning Rogge <[e-mail]>wrote:

> Wouldn't it be easier if we demand that the UDP source port of the
> multicast is the same than the TCP server port?
>
> Henning Rogge
> On Nov 20, 2013 6:36 AM, "Martin Duke" <[e-mail]> wrote:
>
>> I actually think it makes implementation simpler. The server sends UDP
>> packets occasionally to a well-known port and listens on a TCP port. The
>> client just has to listen ona UDP port; no other cases to handle. With
>> discovery messages always coming in, there's no need to build TCP retry
>> heuristics.
>>
>> Configuration: I agree that there are no problems if client and server
>> are identically configured. But part of an interoperability spec is not
>> providing ways for client and server to get out of sync.
>>
>> Regardless, I suggest the Peer Discovery contain the TCP server port, and
>> that if there is no Peer Discovery message the configuration must include
>> the server port. That way, we need only get the UDP port number from IANA.
>> On Nov 19, 2013 9:47 AM, "Stan Ratliff (sratliff)" <[e-mail]>
>> wrote:
>>
>>>
>>>  On Nov 19, 2013, at 1:28 AM, Martin Duke <[e-mail]>
>>> wrote:
>>>
>>> I don't think we want to rely just on TCP if we have OOB detection. Here
>>> are some cases where we need the peer discovery anyway:
>>>
>>>  1. The router is configured with the modem address but the modem does
>>> not have the router address.
>>>
>>>
>>>  In the general case, the TCP client needs the address/port of the TCP
>>> server.
>>>
>>>
>>>  2. The modem has the router IP address but not the port. (I believe
>>> the latest concept requires zero standard TCP ports, and the Peer Discovery
>>> can simply include the port number.)
>>>
>>>
>>>  I don't think we should even try to cover all bases of
>>> mod-configuration. Your either provide a-priori config, or you don't. If
>>> you do, and it's wrong, then shame on you. ;-)
>>>
>>>
>>>  3. The modem has the peer address, but powers up first; the TCP SYN
>>> gets no reply, backs off and times out.
>>>
>>>
>>>  "Heuristics for retrying the TCP session are left to the discretion of
>>> the implementation"… ;-)
>>>
>>>
>>>  Clearly it is much cleaner for the router to send a UDP packet where
>>> we control the frequency and timeout.
>>>
>>>
>>>  This looks like a backup for bad a-priori config, or to address timing
>>> issues. IMO, it increases complexity of the implementation, and doesn't
>>> provide a whole lot of value-add. But I could be missing something.
>>>
>>>  Regards,
>>> Stan
>>>
>>>
>>> On Thursday, November 14, 2013, Stan Ratliff (sratliff) wrote:
>>>
>>>> If you've already got the the peer's address via some out-of-band
>>>> mechanism, then why "discover" him? I've tried to separate things out so
>>>> that the *only* thing discovery does is… wait for it… 'discover'. It tells
>>>> you the address/port of where you need to go connect up. Pretty much all
>>>> other init gets pushed back into the new Peer Initialization message. About
>>>> the only thing that makes sense to me in discovery is the software level of
>>>> the peers - If, for instance, I'm at DLEP Version 19, and I discover a
>>>> potential DLEP peer at Version 1, I *might not* want to connect up in the
>>>> first place.
>>>>
>>>>  Regards,
>>>> Stan
>>>>
>>>>
>>>>  On Nov 14, 2013, at 10:56 AM, Rick Taylor <
>>>> [e-mail]>
>>>>  wrote:
>>>>
>>>>   +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]>
>>>> 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
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>
>>