Subject: Re: [i2rs] Architecture Discussion 5: Client Redundancy

From: Alia Atlas <[email-masked]>
Date: Tue, 5 Nov 2013 01:22:10 -0500

Hi Kwang-koog,

I apologize for the long delay in responding.

On Fri, Oct 4, 2013 at 5:14 AM, KwangKoog Lee <[email-masked]>wrote:

> Hi Alia. This is Kwang-koog from KT.
>
> I checked many opinions from i2rs experts about the client redundancy.
> Thanks for very meaningful discussion to more advance i2rs.
>
> From service provider perspective, active/standby operation of network
> elements through dualization is mandatory for reliable operation from any
> failure. So, I am welcoming for the addition of the client redundancy part.
> Thank you.
>
> Regarding to this, I ask you something for clarifying the understanding of
> the i2rs architecture :-)
>
> As seen in Figure 1 of the architure document, a network application has
> to have a client? Or multiple network applications can attach to a single
> client. Referring to Sec. 4, an I2RS client can interact with multiple
> network applications. The next question is that network applications and
> client can be physically separated?
>

Yes, the architecture supports both models.  Either the network application
has the I2RS client as part of itself (basically a library or the like) or
the network application could talk via some protocol  to an I2RS client.

>  Additionally, in Sec. 6.5 Connectivity, you state that "There are three
> different assumptions that can apply to handling dead clients. The first is
> that the network applicaions or management systems will detect a dead
> network application and iether restart that network application ....".
> Network applications can check the status of other network applications
> each other? What is the management system? The first sentence is saying the
> handling of dead clients, but the second sentence says the dead network
> application. I want to cleary understand those matters.
>

The idea here is that there is some monitoring capability to determine that
a application has failed - that could be the network application with an
I2RS client, a network application without an I2RS client, or the
standalone I2RS client.  This could probably use some clean-up in the text.

>   Those might be simple questions for you. If so, appologize my lack of
> comprehension :p
>

Not at all!  This is how we get a better and clearer draft.

Thanks,
Alia

> Thank you in advance and I also appreciate your efforts for i2rs.
> Bye.
>
> best regards,
> Kwang-koog Lee
>
>
> On Thu, Sep 12, 2013 at 11:59 PM, Alia Atlas <[email-masked]> wrote:
>
>> In draft-ietf-i2rs-architecture-00 Sec 6.4.1:
>>
>> "I2RS must support client redundancy. At the simplest, this can be
>>
>>    handled by having a primary and a backup network application that
>>    both use the same client identity and can successfully authenticate
>>    as such.  Since I2RS does not require a continuous transport
>>    connection and supports multiple transport sessions, this can provide
>>    some basic redundancy.  However, it does not address concerns for
>>
>>    troubleshooting and accountability about knowing which network
>>    application is actually active.  At a minimum, basic transport
>>    information about each connection and time can be logged with the
>>    identity.  Further discussion is necessary to determine whether
>>    additional client identification information is necessary.[[Editor's
>>    note: This requires more discussion in the working group.]]"
>>
>>
>> I would like to start this discussion.  During and after the Berlin IETF, there
>>
>> was significant discussion on the list.  I tried to capture the ideas that were
>>
>> expressed then.  Is what is in the draft now sufficient?  How should it be improved
>>
>> upon?
>>
>>
>> Thanks,
>>
>> Alia (WG-Chair hat off)
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>