Re: [Dime] Questions regarding RFC 6733

Hi,

I specifically said that you would need to instantiate new peer state
machines.. otherwise it does not really work.

- Jouni

On Wed, Mar 8, 2017 at 1:36 AM, Ajinkya Joshi <ajoshi@definitionnetworks.com
> wrote:

>
>
> On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <jouni.nospam@gmail.com>
> wrote:
>
>> hi,
>>
>> > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <
>> ajoshi@definitionnetworks.com> wrote:
>> >
>> > Hello,
>> >
>> > I have following questions regarding diameter RFC 6733, I would really
>> appreciate if someone can help me with these.
>> >
>> > 1. Regarding diameter peer state machine -
>> >
>> >     Section 5.6.1 (Peer State Machine --> Incoming connections)
>> mentions that Origin-host is used for     identifying peer state machine
>> and as per state machine, once it moves into I-Open, new CER is
>>  rejected. This concludes, that there can't be more than one transport
>> connections with same               diameter host (as specified by
>> Origin-host).
>> >
>> >     Section 2.1 (Transport) mentions that "A given Diameter instance of
>> the peer state machine MUST      NOT use more than one transport connection
>> to communicate with a given peer, unless multiple        instances exist on
>> the peer, in which, case a separate connection per process is allowed."
>> >
>> >      Questions --
>> >       • Does section 2.1 implicitly assumes that multiple diameter
>> instances (within a peer) would correspond to different diameter host ?
>> Otherwise, it could contradict with section 5.6.1
>>
>> it assumes one peer connection per peer state machine. so if you have a
>> way to ‘fork’ a new peer instance with its own peer state machine per
>> incoming connection then having “multiple instances’ is possible even if
>> the diameteridentity is the same.
>>
>
> [ajoshi] If we fork a new peer instance with same diameteridentity, won't
> it create problems as per peer state machine? Because, you would have
> separate transport connection for each of them and each transport
> connection needs capability exchange and as per peer state machine, there
> can be only one capability exchange. I am inferring this based on section
> 5.3 which says "When two Diameter peers establish a transport connection,
> they MUST exchange the Capabilities Exchange messages". Am I missing
> something here? Or is it the case that two peers (identified based on their
> respective diameter host-names) would perform capability exchange only
> once, irrespective of number of transport connections they have?
>
>
>>
>> >       • If multiple transport connections (towards the same peer) are
>> allowed per diameter host, is it expected that peer would do load balancing
>> between them? (There is a connection load balancing section in RFC 3539 -
>> Section 3.4.3)
>>
>> what you do and how you manage ‘multiple instances’ if more or less left
>> for implementation to decide. i always considered it as a node internal
>> compute load balancing mechanism i.e., to distribute the compute to
>> separate cores/blades etc.
>>
>>
>> > 2. Regarding diameter peer failback procedure -
>> >
>> >       Section 5.5.4 mentions "a connection request should be
>> periodically attempted with the failed              peer in order to
>> re-establish the transport connection"
>> >
>> >       Question --
>> >
>> >       • If the failed peer is dynamically discovered via DNS lookup, is
>> it expected that peer would perform DNS query before trying to establish
>> the connection again? Or DNS lookup is driven only by TTL field received in
>> the prior DNS answer ?
>>
>> up to your implementation and dns resolver implementation.
>>
>> - jouni
>>
>>
>> > --
>> > Regards,
>> > Ajinkya Joshi
>> > _______________________________________________
>> > DiME mailing list
>> > DiME@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dime
>>
>>
>
>
> --
> Regards,
> Ajinkya Joshi
>