Subject: Re: [i2rs] I-D Action: draft-rfernando-i2rs-protocol-requirements-00.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Oct 2013 06:38:16 -0400

This strikes me as an interesting and useful step in our effort.  I am 
however confused by certain aspects of the document.

1) The document introduces new terminology in several regards.  It seems 
to replace the I2RS agent with "server".  It makes no reference to 
Information model, but makes several references to different kinds of 
data models.  And it makes these changes without any comment or 
observation about the change.  Can you please motivate the changes?

2) I think that OP-3 on providing a detailed workflow for bringing about 
new services is a MAJOR new tasking for the WG, and does noit follow 
from the charter.  I understand that it is useful.  But many things are 
useful that are outside our charter.

Detail:
3) GEN-3 and TR-4 seem to contradict each other.  GEN-3 says that the 
client always initiates the transport connection to the server, and TR-4 
says either participant may initiate the transport connection.

4) Is TR-12 intended to require persistent connections between clients 
and servers?  I had thought this was still under discussion, with many 
of us at least wanting to avoid requiring a transport connection during 
the lifetime of the state created by an I2RS client.  It is possible 
that you only mean the keep-alives for as long as the participants want 
the connection alive.  It is not obvious that this is worth the cost, 
since failure will be detected (if communication has failed and not 
recovered) when the participant next attempts to use the transport 
connection.

5) ID-7 implicitly creates the notion of shared identity.  Is that 
really the right model?  Or should we have multi-part identity, one part 
for attribution purposes, and another part for permission purposes? 
(With all of it authenticated of course.)

6) MessageExchangePattern-2 says that capabilities can be exchanged in a 
fire-and-forget fashion that is the same as that used for notifications. 
  fire-and-forget leads this reader to think unreliable.  And capability 
exchange messages would seem to need reliability.

7) MessageExchangePatter-3 seems to require an application level 
acknowledgment even if we use a reliable transport.  This may be 
reasonable, but if so it needs more motivation.  And an explanation as 
to why a reliable transport is not sufficient would be appreciated.  It 
may be that this requirement is merely intended to say that every 
operation should have a success or failure reply.  I would not call that 
an acknowledgment.

8) API-11 seems to be a subset of what is called for in the WG 
architecture document.  Shouldn't we either agree to change the 
architecture or put the full requirement in the protocol requirements?

Minor:
Can we find another term than MEP?  I realize that acronyms are 
overloaded, and some collisions are inevitable.  But MEP and MIP are 
sufficiently pervasive and confusing on their own in the OAM space, I 
would really like to avoid talking about the MEP (Message Exchange 
Pattern) for performing manipulation of the MEP (Maintenance End Point.) 
  Could we use Communication Pattern or COmmunication Exchange Pattern?

On 10/21/13 4:33 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : I2RS Protocol Requirements
> 	Author(s)       : Rex Fernando
>                            Jan Medved
>                            Edward Crabbe
>                            Keyur Patel
> 	Filename        : draft-rfernando-i2rs-protocol-requirements-00.txt
> 	Pages           : 21
> 	Date            : 2013-10-21
>
...
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-rfernando-i2rs-protocol-requirements
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00
...

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Tue, 29 Oct 2013 05:21:22 +0000

Hi Joel,

Thanks a lot for the review & comments. Please see inline.

/Jan

>observation about the change.  Can you please motivate the changes?

This is an oversight. The draft's terminology will be aligned with the
I2RS terminology

>useful that are outside our charter.

I agree. We can leave it out of the draft for now.

>says either participant may initiate the transport connection.

Thanks for catching this. My preference would be a client connecting to
the server (I2RS Agent), but there are examples of each behavior deployed
in real world (client connecting to server: Netconf, server connecting to
client: OpenFlow). 
 
>and servers?  

Yes.

>I had thought this was still under discussion, with many
>the connection alive.

We were requiring a persistent transport connection during the state's
lifetime. I can understand the desire to ease this requirement, but this
introduces complexity in other parts of the system. For example, we have
to allow either the Agent or the client to initiate the transport
connection (The Agent in case it wants to notify to the client about a
state change). Also, the state cleanup/timeout procedures & policies will
likely be more complex.

I agree that this is something that we should discuss and consider all the
pros/cons.

> It is not obvious that this is worth the cost,

Failure detection w/o keepalives can take a long time. Detecting a failure
early is critical in some applications. But, I think we could make
keepalives optional.

>really the right model?

We need to have something to support redundant clients implementation.
Alternatively, we could have explicit state delegation (similar to PCEP) -
but that's probably more complex.

> Or should we have multi-part identity, one part

That's a viable model too. But how would it support redundant client
implementation?

>exchange messages would seem to need reliability.

I think you're right. For capabilities exchange we need app-level
reliability, which can only be achieved by request-response (where the
reply is an ACK), not by fire-and-forget.
>to why a reliable transport is not sufficient would be appreciated.

Ok. A reliably delivered request does not mean an operation has truly been
performed - a positive 'ACK' response is needed. The document will be
updated.

> It may be that this requirement is merely intended to say that every
>operation should have a success or failure reply.

That's another way to describe it.

> I would not call that an acknowledgment.
>

I'd rather put the full requirements in one place - the protocol
requirement document.

>  Could we use Communication Pattern or COmmunication Exchange Pattern?

I like that, will be changed in the next rev of the document.

>_______________________________________________
>i2rs mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Oct 2013 03:48:39 -0400

Thank you for the detailed reply.
Looks like there are some items worth discussing, but no major disconnects.

In particular, I agree that we should put all the requirements together, 
and this document seems a good place to do so.

Yours,
Joel