Subject: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

From: Jeffrey Haas <[email-masked]>
Date: Thu, 5 Jun 2014 16:29:38 -0400

Working Group,

The original deadline for comments on WGLC for the problem statement and
architecture drafts of May 30 has passed with no comment whatsoever.

While we all realize that there's a bit of exhaustion going on with regard
to these drafts, they are a bit of process we simply must get done in order
to fully move forward with our agenda of putting together data models.  

We are *NOT* going to hold that work up further - it is clear that there is
consenus to start making that progress.

To assist us with putting this work behind us, please respond to the
following questions:

http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
Have you read the problem statement draft?
Do you think it is ready to be published as a RFC?
(If no, please respond to the list with issues.)

http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
Have you read the architecture draft?
Do you think it is ready to be published as a RFC?
(Ditto.)

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Jun 2014 16:46:16 -0400

Comments in line with questions:

> Have you read the problem statement draft?
Yes

> Do you think it is ready to be published as a RFC?
Yes

> Have you read the architecture draft?
Yes

> Do you think it is ready to be published as a RFC?
Yes.  While I would prefer to see the template material removed, I 
accept that the working group wants the material.

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 19:56:31 -0400

Jeff:

Problem statement: read, suggested changes (repeated 4X), Ok for WG LC, and
RFC. 
Architecture document: wrote, edited other people changes (repeated 10X), Ok
for WG LC, RFC.

Documents ready to ship to IESG for blessed RFCdom. 

Thanks Jeff for the reminder to comment! 

Sue  

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, June 05, 2014 4:30 PM
To: [email-masked]
Subject: [i2rs] Working Group Last Call on architecture and problem
statement drafts (redux)

Working Group,

-- Jeff

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 6 Jun 2014 13:57:29 +0000

Jeff, 

Problem statement:  suggested changes, several times, still waiting for those to be addressed in the draft. As my comments are not addressed, I don't think draft is ready for WGLC or RFC. 

Architecture document: ready for WGLC, ready for RFC

Dean

---

From: Alia Atlas <[email-masked]>
Date: Fri, 6 Jun 2014 10:10:42 -0400

Dean,

On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic <[email-masked]> wrote:

> Jeff,
>
> Problem statement:  suggested changes, several times, still waiting for
> those to be addressed in the draft. As my comments are not addressed, I
> don't think draft is ready for WGLC or RFC.
>

Just a reminder - I have the changes ready to go as discussed.  We were
waiting on any other comments from the WGLC before updating the draft.
 Given the paucity of such comments and the
availability of integers, I'll just submit it.

Alia

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Jun 2014 17:27:48 +0200

> (If no, please respond to the list with issues.)

I have read <draft-ietf-i2rs-problem-statement-01.txt> (and the diff
for -02). I have a couple of comments that I like to see addressed,
some are purely editorial (and may be left to the RFC editor), others
are I think clarification or suggestions for more appropriate wordings.

- Please make sure the central figure fits on a single page since a
  page break in the middle is kind of disturbing.

- What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'.

- What are "_semantic-aware_ data models"? Either remove
  _semantic-aware_ or define it.

- s/MIBs/MIB modules/

- s/MIB Notifications/MIB notifications/

- This is not quite correct:

    [...] nor is there the
    standardized ability to set up the router to trigger different
    actions upon an event's occurrence so that a rapid reaction can be
    accomplished.

  I believe the MIB modules that were created by the Distributed
  Manaement (DISMAN) working group provide this functionality. You may
  want to rephrase this so that it says that such MIB modules were not
  successfully deployed or something like that, but it is not correct
  that there are no standardized MIB modules for this.

- I find some of the high throughput "desired aspect" of the protocol
  problematic, e.g. "should be able to handle a considerable number of
  operations per second above what basic Netconf or a propretiary CLI
  can". I find this ill defined. I see this got fixed in -02 which
  just got posted and I appreciate that fix.

- s/NetConf/NETCONF/

- The NETCONF community was forced to follow a sequential process and
  it took us time to create YANG after NETCONF and we are now getting
  core data models out (some published, some in the RFC queue, some in
  the hands of the IESG). Hence I like the following to be rephrased:

  OLD:

    However, the lack of
    standard data models have hampered the adoption of NetConf.

  NEW:

    However, the initial lack of
    standard data models has hampered early adoption of NETCONF.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 06 Jun 2014 11:51:11 -0400

On 6/6/14, 10:10 AM, Alia Atlas wrote:
> Dean,
>
> On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Jeff,
>
>     Problem statement:  suggested changes, several times, still waiting
>     for those to be addressed in the draft. As my comments are not
>     addressed, I don't think draft is ready for WGLC or RFC.
>
>

I also had some comments on the last architecture draft.  While some of 
them were silently addressed, there were a couple where I expected the 
authors to respond.  I can resend the email if you missed it.  It was a 
while ago.

Joe

>     On Jun 5, 2014, at 4:29 PM, Jeffrey Haas <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      > Working Group,
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 6 Jun 2014 15:15:07 -0400

Hi Juergen,

Please see my responses/resolutions below.  I'll be submitting
a version -03 with these changes (plus a couple wording changes from Dean).

Thanks for the review!
Alia

> - What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'.

Replaced "clear" with "concise"...

>   _semantic-aware_ or define it.

Replaced with "meaningful"

> - s/MIBs/MIB modules/

Done

> - s/MIB Notifications/MIB notifications/

Done

>   just got posted and I appreciate that fix.

Replaced with "While a few of these (e.g. link up/down)
      may be available via MIB notifications today, the full range is
      not - nor has there been successfully deployed the standardized
      ability to set up the router to trigger different actions upon
      an event's occurrence so that a rapid reaction can be
      accomplished. "

>     standard data models has hampered early adoption of NETCONF.

Done.

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 6 Jun 2014 19:22:59 +0000

Jeff,

Alia answered my concerns and am fine with the draft for WGLC and RFC

Dean

On Jun 6, 2014, at 3:15 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Juergen,

Thanks for the review!
Alia

On Fri, Jun 6, 2014 at 11:27 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

- s/MIBs/MIB modules/

Done

Done

    [...] nor is there the

- s/NetConf/NETCONF/

  OLD:

    However, the lack of

  NEW:

Done.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Jun 2014 21:41:44 +0200

> a version -03 with these changes (plus a couple wording changes from Dean).

Thanks for the changes.

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 6 Jun 2014 16:54:49 -0400

Joe,

On Fri, Jun 06, 2014 at 11:51:11AM -0400, Joe Marcus Clarke wrote:
> I also had some comments on the last architecture draft.  While some
> of them were silently addressed, there were a couple where I
> expected the authors to respond.  I can resend the email if you
> missed it.  It was a while ago.

Would you please review your comments and re-post the ones still waiting for
action?

Thanks!

-- Jeff (who's hoping to avoid the need to use the trac system..)

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 06 Jun 2014 17:33:57 -0400

> Do you think it is ready to be published as a RFC?

Here is a list of my previous comments that didn't get addressed in the 
text or on the list.

In section 1.1, the first paragraph states:

...Second is the access to structured information and state that is 
frequently not directly configurable...

Then in paragraph four:

...I2RS will only permit modification of state that would be safe, 
conceptually, to modify via local configuration...

While you do use the word "conceptually," it's hard to conceive of 
something that is at the same time safe to modify via the configuration 
but is not exposed via the configuration.  That is, how would one know 
what is safe?  This might benefit from an early example to clarify what 
is meant and perhaps it is good enough to drop the bit about modifiable 
via local configuration and just say that modification of protocol 
internal state is out of scope.

===

In section 1.2, the new text helps to show how App, Client, and Agent 
fit together, but I wonder if this same new text wouldn't benefit from a 
statement that App to Client communication is out of scope.  That is, 
you state that the Client and Agent communicate via an asynchronous 
protocol, but nothing is said about, for example, how apps C, D, E 
communicate with Client P.  You do mention this further down in the doc, 
so it's a minor thing, but perhaps worth a sentence here.

===

Section 2, in the I2RS Client paragraph, I can't get my head around this 
text:

Based on the information and the policy oriented interactions, the 
I2RS client may also interact with I2RS agents to modify the state
of the routing system the client interacts with to achieve
operational goals.

The first part makes sense, but then it starts to sound muddled, at 
least to me.  Maybe you want to say:

Based on the information and the policy oriented interactions, the 
I2RS client may also interact with I2RS agents to modify the state
of the routing system in order to achieve operational goals.

===

Section 4.  While streaming OSPF prefix announcements MAY NOT require 
confidentiality, some users may want it.  Paragraph 4 starts out, Other 
communications via I2RS will not...  I think this should say may not 
just to make it clear that this can be optional based on specific 
environmental requirements.

===

Section 7.1.  This is mainly an editorial, but in looking back at things 
like NETCONF over BEEP, one goal might be to make sure the transport 
chosen is both operator and implementor friendly in terms of ease of 
adoption.

===

Section 7.5.  Would a supervisory application work in this case?  I 
suppose it could if it shared the same ID, but that wouldn't work for 
multiple applications.  Likely a better approach would be to allow the 
Client to accept some meta-instructions at the beginning of a session as 
to what to do if the app goes away (as you state in paragraph 4).

Thanks.

Joe

---

From: ramki Krishnan <[email-masked]>
Date: Sat, 7 Jun 2014 11:05:18 -0700

http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
Have you read the problem statement draft? yes
Do you think it is ready to be published as a RFC? yes

http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
Have you read the architecture draft? yes
Do you think it is ready to be published as a RFC? yes

Thanks,
Ramki

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, June 05, 2014 1:30 PM
To: [email-masked]
Subject: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

Working Group,

The original deadline for comments on WGLC for the problem statement and architecture drafts of May 30 has passed with no comment whatsoever.

While we all realize that there's a bit of exhaustion going on with regard to these drafts, they are a bit of process we simply must get done in order to fully move forward with our agenda of putting together data models.  

We are *NOT* going to hold that work up further - it is clear that there is consenus to start making that progress.

To assist us with putting this work behind us, please respond to the following questions:

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jun 2014 17:19:48 +0200

Hi Jeff,

Late but still few comments on the draft-ietf-i2rs-architecture-03:

1.
> This I2RS architecture recognizes that the routing
> system and a router’s OS provide useful mechanisms
> that applications could harness to accomplish
> application-level goals.

What happens if multiple applications have mutually exclusive needs ?
It is not really an error as applications and clients by design are
independent. Where is the arbitration to take place ? In I2RS Client,
in I2RS Agent or in global router's RIB ?

2.
Fundamental question ...

Is the I2RS protocol communication to take place in-band, out-of-band
or both of the data plane ? If we are including in-band I presume
there is serious risk that the information carried within the protocol
may cause in-band channels to stop working hence the device becomes
unreachable (at least for the I2RS system).

It may be good for architecture document to be able to comment on it.

3.
> Anticipated I2RS Services

Is OEM hidden within the "Dynamic Data & Statistics" or is it just
plain missing ? ;)

Many thx,
R.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 9 Jun 2014 13:19:58 -0400

>Do you think it is ready to be published as a RFC?

Yes, but with two relatively minor comments:
Section 2: It would be useful to clarify the scope of the proposed data
model. I realize there’s a separate draft for data model, but since this
is the primary draft that one should read before diving into the gory
details, some clarity would be helpful. The big diagram includes a lot of
interfaces and objects that are "out of scope for I2RS", but it’s unclear
to me whether you also mean that all of those would be out of scope when
it comes to the data model, or if you actually mean that they are simply
out of scope when referring to which interface we’re trying to build
between which objects. I think it’s the latter, since you need to
represent a much larger range of things in the data model than in the
interface, but you may want to be more explicit in the latter half of
section 2, as well as replacing “I2RS" with something more descriptive in
the diagram to avoid naming confusion since “I2RS” can mean IETF WG/effort
OR the actual interface to the routing system and related protocol.

Since section 3 discusses MIBs and configuration, a reference to the
recent statement about writeable MIBs might also be appropriate here as
one more bolster to the need for a different protocol to do this work.

>Do you think it is ready to be published as a RFC?
Yes, again with a couple of comments:

1.2 - are we considering flow data as a part of dynamic system state and
available to I2RS, or not? Would be useful to clarify, especially since
availability of flow data is often limited (not typically stored in large
amounts on-box), and similarly to the other stats mentioned, may be
available via other sources.

6.2 - I recommend that you explicitly call out the need to be able to
review (e.g. via CLI) the changes made by the I2RS agent and its state
data without a dependency on the client itself. The simplest
implementation case for making onboard CLI and I2RS agents play together
is that the router CLI is simply another application that uses the I2RS
agent in order to represent the necessary information, but I think that
dependency might be problematic. I think what is needed here is a way to
verify what is going on with the I2RS agent via separate means, such that
if the I2RS agent goes insane, I can use another method to figure out what
its particular psychosis might be. It may not be practical to assume that
making the onboard CLI a client of the same agent will produce valid
results. i.e. I may not get a useful answer if I query the I2RS agent
“tell me why you’re insane” but I might be able to figure out what the
agent was doing when it went insane if I can get access to the info about
what actions it took/what data it manipulated once it went insane, or look
directly at its underlying state database without its “help". I think this
is a pretty important thing from a traceability and failure management
perspective.

Thanks

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 9 Jun 2014 13:58:34 -0400

Joe:

Yes, I did try to send you off-list the comments the "silent" comments.
Next time I will send onlist.   Thank you for resending the comments. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Marcus Clarke
Sent: Friday, June 06, 2014 11:51 AM
To: Alia Atlas; Dean Bogdanovic
Cc: Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Working Group Last Call on architecture and problem
statement drafts (redux)

On 6/6/14, 10:10 AM, Alia Atlas wrote:
> Just a reminder - I have the changes ready to go as discussed.  We 
> were waiting on any other comments from the WGLC before updating the
draft.
>   Given the paucity of such comments and the availability of integers, 
> I'll just submit it.

I also had some comments on the last architecture draft.  While some of them
were silently addressed, there were a couple where I expected the authors to
respond.  I can resend the email if you missed it.  It was a while ago.

Joe

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 09 Jun 2014 14:21:00 -0400

> Next time I will send onlist.   Thank you for resending the comments.

Hmmm, sorry, then Susan.  I don't think I saw your email.  I have been 
traveling a lot lately, so maybe it just slipped through the cracks.

Joe

---

From: t.petch <[email-masked]>
Date: Tue, 10 Jun 2014 12:12:35 +0100

Architecture

After reading this, I struggle to see the point of I2RS:-(  As was said
two months ago,
"And the basic premise of I2RS is that there are requirements for the
work that were not addressed properly by the existing configuration
protocols. "
but reading Architecture, the examples I see are ones that seem to fall
within the remit of NETCONF (being config) as and when a suitable data
model has been defined (e.g. for OSPF or BGP).  Initially I had thought
of several things that I2RS might do but these have been ruled out,
either on the  list or in this I-D, so I am left wondering what it is
that I2RS will do that NETCONF potentially cannot.

I do find the I-D quite hard to follow as the terminology seems
inconsistent - the word 'state' is much used but it is unclear to me if
the term can be given a single definition in this context; and even if
it can, the word seems an unfortunate choice since the IETF Ops Area has
given it a precise definition which is at odds with its use here.

Tom Petch

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 10 Jun 2014 12:35:09 +0000

A document clearly stating the reqs would help me understand the need I2RS is addressing. I would suggest writing the reqs info doc first

Jim Uttaro

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of t.petch
Sent: Tuesday, June 10, 2014 7:13 AM
To: Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

Architecture

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 09:41:33 -0400

Tom,

Thanks for the comments.

> of several things that I2RS might do but these have been ruled out,

It'd help if you listed the ones in question.  Some of these things may be
part of the work that is left currently out of scope to attempt to constrain
the WG to things we have decided to get done first.  (Don't bite off more
than you can chew.)

> that I2RS will do that NETCONF potentially cannot.

The longer term question and netconf/yang continue to evolve (perhaps with
impetus from our use cases) will generally be what work belongs in various
groups.  Yang modules are being proposed in the various working groups to
cover protocol specific configuration and general management.  This is
great!  The question then becomes, where does I2RS fit into that sort of
picture.

One of the reasons I think nailing down specific requirements (as Jim Uttaro
raised in a separete response) has come down to the somewhat nebulous
ability to interact with functionality that is either not quite a fit for
standard config/query or interact with models that are one or more levels of
abstraction above a given protocol component.

The degenerate case - the ability to ephemerally inject static routing
information - certainly seems like work that could be done outside of I2RS.
Definitely so if it is decided that the ephemeral model is something that
becomes core to netconf/restconf.  (The question of how this is represented
in the data model is the longer question.)

Where the use cases start getting more substance are when we get somewhat
more abstract: 
- An API to the traffic engineering state in a routing system.  This is not
  just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view.  Which working
  group produces that model if done on a per-protocol basis?
- A policy layer on top of BGP.  That's perhaps in-scope for IDR or GROW.
  As you definitely know (:-) ) such a policy layer will interact with a lot
  of non-BGP components and potentially other databases.
- A management layer to provision VPN instances (service layer routing).
  Does that work get done in IDR? MPLS? L2/L3VPN?

And of course, there's the whole matter of how do you bring together
contributors with expertise in modeling, operations and the mix of routing
and other protocols in question and where do you do it?  From the first BoF,
it was clear there are a lot of people who want to work on the things that
fall in these nebulous gaps between working groups.  

I2RS is here to be the big tent to let us gather people under to do that
sort of work.  Maintaining enough focus to make progress on a constrained
number of items is the main early challenge.  A survey of the use case
documents should definitely suggest there's a lot more that people would
like to work on.

> given it a precise definition which is at odds with its use here.

Are there specific edits you would suggest to clarify the document?

-- Jeff

---

From: t.petch <[email-masked]>
Date: Tue, 10 Jun 2014 16:25:53 +0100

---- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2014 2:41 PM

> the WG to things we have decided to get done first.  (Don't bite off
more

e.g.
6.2.3.  Reversion "In all such cases, the state will revert to what it
would have been without the I2RS; that state is generally whatever was
specified via the CLI, NETCONF, SNMP, etc."
which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it
to Y then disappears so it reverts to X, for all values of 'it' - i.e.
'it' is what NETCONF would call config and so could have been set by
NETCONF, no need for I2RS!

6.3.  Interactions with Local Config "Changes may originate from either
Local Config or from I2RS."
Taking Local Config to be what NETCONF/YANG calls 'config' then again,
nothing there it seems that C/N/S cannot do

6.4.2"  o  writing policy information such as interface attributes that
are
      specific to the routing protocol or BGP policy that may indirectly
      manipulate attributes of routes carried in BGP.

   o  writing routes or prefixes to be advertised via the protocol"
I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the
I-D goes on to say
" direct modification of the link-state database MUST NOT be allowed"
(which I have seen on the list w.r.t. the BGP RIB).

or

8" The interaction of state installed via the I2RS and via a router's
configuration needs to be clearly defined."
which again implies that I2RS and C/N/S are writing to the same data.

The examples of data that can be changed are few, such as
"For example, the interaction with OSPF might include modifying the
   local routing element's link metrics, announcing a locally-attached
   prefix, .."
which leaves me wondering, do you expect an OSPF YANG model to be unable
to change a link metric:-)

Whereever I look, I struggle to see what I2RS will write that C/N/S will
not.

If I2RS were aiming at a higher level, say specifying policy and have
the system translate that into actual config changes I would understand
that, but I do not see I2RS going that far, rather when I2RS says
policy, I think it means changing a community (config again) or some
such ie more of an implementation detail than a high level strategy.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 12:52:25 -0400

Robert,

Thanks for the review!

> > system and a router???s OS provide useful mechanisms

You should find this addressed in section 7.8.

> It may be good for architecture document to be able to comment on it.

This seemed like one of those sort of things that were too obvious to state,
but perhaps it's worth stating it.

Authors, would you consider a few sentences in section 7 to cover this
point?

> Is OEM hidden within the "Dynamic Data & Statistics" or is it just

The usual derivation of:
Architecture -> Models + Protocol -> XXX -> Profit!

is left as an exercise to the implementor.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 13:21:36 -0400

Wes,

Thanks for taking the time to supply your review.

On Mon, Jun 09, 2014 at 01:19:58PM -0400, George, Wes wrote:
> model. I realize there???s a separate draft for data model, but since this
> interfaces and objects that are "out of scope for I2RS", but it???s unclear
> out of scope when referring to which interface we???re trying to build
> between which objects. I think it???s the latter, since you need to
> interface,

The way I've interpreted the diagram is basically:
- I2RS defines the client and agent and the interactions (protocol)
- The Agent, by necessity, interacts with system components in a black-box
  implementation-specific fashion.

While I understand you're looking for "where does a data model box fit into
the diagram", I'm not sure there's enough flexibility in the ASCII diagram
to cover that. :-)  If this were UML (which would balloon the diagram an
order of magnitude), we'd have Interface lollipops all over the place and
even then, that's probably the best we'd have for the high level
description.

>  but you may want to be more explicit in the latter half of
> section 2, as well as replacing ???I2RS" with something more descriptive in
> the diagram to avoid naming confusion since ???I2RS??? can mean IETF WG/effort

I think it's meant to cover both cases: Within the scope of the WG effort
and also protocol interactions.

> one more bolster to the need for a different protocol to do this work.

I agree.

Authors, would you please add an appropriate reference?  The URL is:
http://www.ietf.org/iesg/statement/writable-mib-module.html

> available via other sources.

Flow data isn't specifically in-scope to chartered work - today.  When the
Working Group was formed, the ADs realized that we could easily take on a
massive amount of work and thus dilute the attention of the group.  Today we
have a charter with a limited number of cases:

http://datatracker.ietf.org/wg/i2rs/charter/

Once we've gotten some traction on those cases, I suspect a re-chartering to
cover such things can occur.

> ???tell me why you???re insane??? but I might be able to figure out what the
> directly at its underlying state database without its ???help". I think this

[Please note: Discussion, not necessarily disagreement.]

I think there's a few challenges with this.  The biggest one is that no
matter how carefully we try to word such an architectural requirement, we're
going to end up making demands on implementations that either will be
difficult to standardize or perhaps even impossible. 

For what it's worth, this isn't much uglier (and probably is a case that
brought this to mind for you) than configuration state imposed by SNMP
rather than the CLI.  Configuration constructs in SNMP may not have good
mappings to those in the CLI and vice versa.

A trivial comparison might be if your I2RS agent was implemented by doing
CLI translation, then it might be possible to do CLI comparisons.  But if
it's not, such comparison may be hard.

Given the above, what would you suggest?  I realize what we want is a way to
troubleshoot, but I'm not sure there can be any specific recommendation that
will span the architectures well enough to be standardized.
-- JeffO

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 13:41:57 -0400

Joe,

Thanks for re-sending the comments.  A few clarifying points:

On Fri, Jun 06, 2014 at 05:33:57PM -0400, Joe Marcus Clarke wrote:
[...]
> Section 7.1.  This is mainly an editorial, but in looking back at
> things like NETCONF over BEEP, one goal might be to make sure the
> transport chosen is both operator and implementor friendly in terms
> of ease of adoption.

I think we're leaving this broadly open because "easy to implement" will
vary depending on your environment.  PHP webserver based environments may
prefer BEEP environments if you have the right tool chain, as an example.
I'd probably prefer to just do it in SSH if I were writing it.

But I think we're all generally aware that the client environment and
ecosystem and the agent environment and ecosystems may be wildly different.
Clients will be highly variable since they're user applications.  Agents in
many cases will have to co-exist with routing applications that have
(near) real-time constraints.  This disparity of environments will likely
lead to some constraints on what a given vendor may care to deploy.

Given the above, do you still think 7.1 needs additional clarification?

> Section 7.5.  Would a supervisory application work in this case?

This seems like an implementation detail - and potentially a common one.
However, I'm not sure if it's one we'd want to mandate in the architecture.

> I
> suppose it could if it shared the same ID, but that wouldn't work
> for multiple applications.  Likely a better approach would be to
> allow the Client to accept some meta-instructions at the beginning
> of a session as to what to do if the app goes away (as you state in
> paragraph 4).

I believe such details will hopefully fall-out very early on in the gap
analysis work that is ahead of us.  Perhaps even something like "Graceful
restart" type semantics, if appropriate.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 14:07:47 -0400

Tom,

[retaining lots of content for context]

> nothing there it seems that C/N/S cannot do

This is much of what I had suggested about the semantics of introducing
ephemeral config into netconf.  Our requirement is that these things are
ephemeral.  (Although Tom Nadeau presents some nice cases as to why we may
want the equivalent of "write running-config" to permit persistence.)

At this point, overlapping ephemeral configuration isn't something that
netconf supports.  If you scan mail from the last month or so, you'll also
see some back and forth between Juergen and Andy and I about how we go about
representing such a thing in the yang model/modules.  (And we never fully
converged.)

>From the config perspective, this ephemeral state wasn't something that I
believe was part of the config semantics of netconf/yang; it's an I2RS
requirement.  Admittedly, once we have such a think then clearly
applications other than I2RS can make use of it. :-)

Choosing a solution space will be the next challenge we have:
- Overlapping modules with i2rs context?
- Parallel modules?
  - How to ensure maximum re-use of the yang modules for config in an i2rs
    context if they are determined to have heavy overlap?

> which again implies that I2RS and C/N/S are writing to the same data.

*Maybe.*

In some cases, the overlap with config state will be quite obvious and your
observation will strongly hold.

In other cases, I think a better perspective is that I2RS injected state is
effectively like that of another routing protocol.

If you'd like to argue that BGP is effectively the same as C/N/S... well, if
we're talking Flowspec I might agree. :-)

> to change a link metric:-)

Sure.  In a highly dynamic fashion? With a fallback to a default config when
the application is done?

By comparison to some vendor specific features, it's somewhat the difference
between a policy database (config) and the dynamic policy API that doesn't
require a system reconfiguration event.  If you want to point out that the
relationship is strong and that the defining differences are shallow - you
could very well be right in those contexts.

Again, we don't expect I2RS work to supplant netconf/yang.  We expect to
leverage the work.

> such ie more of an implementation detail than a high level strategy.

I hesitate to frame it this way, but one example application is a form of
SDN.  The front end says "provision this VPN" to a data model for that
purpose.  The fact that it may go behind the covers via client->agent and
eventually install ephemeral netconf state is an implementation detail.

If you want to argue that such a higher level model is simply netconf, then
perhaps we should de-charter and do all of the work in that group. I was,
however, under the impression that work for various models was being pushed
to be done in appropriate working groups. :-)

-- Jeff

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 10 Jun 2014 12:08:52 -0700

> Have you read the problem statement draft?

Yes.

> (If no, please respond to the list with issues.)

Yes.

> Have you read the architecture draft?

yes

> Do you think it is ready to be published as a RFC?

A question in sec 7.8. Second para. There is a sentence starting with "The
mechanism for this is to ..." and later it says "In order for this approach
to  ...". The first sentence seems to imply that this is the only mechanism
allowed by this architecture whereas the second sentence seems to imply
that this is one possible mechanism and agents can choose other mechanisms
too. Which one is correct ? I would suggest that the language be updated to
reflect that.

Otherwise the doc looks good to be published as a RFC.

Sri

---

From: "George, Wes" <[email-masked]>
Date: Tue, 10 Jun 2014 15:53:27 -0400

On 6/10/14, 1:21 PM, "Jeffrey Haas" <[email-masked]> wrote:

Problem statement:
>> model. <snip>

>even then, that's probably the best we'd have for the high level
WG] Not necessarily asking for additional boxes in the diagram, because I
agree that there’s no way to represent it unless you duplicate the same
diagram (with appropriate changes in scope) for the data model. I was more
thinking in terms of making it a bit clearer in the text following the
diagram that the data model may necessarily include things that are listed
as out of scope for the I2RS interface/protocol, because it needs a way to
represent the things that it gets from the I2RS agent based on its black
box interaction with other parts of the routing system.

>and also protocol interactions.
WG] That’s sort of the problem I was pointing out. Maybe this only matters
while we’re in the middle of the discussion and people remember the name
of the WG and are therefore likely to conflate the two, but for right now,
it does have some potential for confusion. I leave it to the WG and
authors to decide whether that’s a trivial concern or not.

Architecture:
>
>Flow data isn't specifically in-scope to chartered work - today.
‘WG] Yes, wasn’t advocating to include it, merely observing that the
document is not explicit one way or the other here, and one could make the
argument that flow data is a type of stats. So if it is indeed out of
scope, I think there’s value in calling that out specifically.
>> data without a dependency on the client itself. <snip>

>mappings to those in the CLI and vice versa.
WG] and as noted, we recommend against using SNMP to impose state anymore
for lots of good reasons, so I’m not at all convinced that “not much
uglier than SNMP” is a feature…
>it's not, such comparison may be hard.
WG] The reality is that operators have been dealing with this disconnect
for years, where a vendor implements a feature that is either fully
supported in CLI but not simultaneously in $magic_management_interface du
jour, or vice versa. It can be a temporary gap due to mismatches in
release cadence, or it could be a permanent gap based on a conscious
decision, but either way those gaps make it difficult for operators to
implement the feature, because either you don’t have a way to verify and
troubleshoot it outside of the primary (systematic) interface, or you
don’t have a way to systematically interact with it and you have to screen
scrape or swivel seat. This can’t be an either-or, because for the
foreseeable future we are not going to be able to assume that if the
agent/systematic interface is present, that no one will ever use or need
the CLI for anything that can be done via the agent, or that the uses for
each can be mutually exclusive. That just makes the system brittle and the
methods for troubleshooting it needlessly complex. There are a lot of
folks in operations with a healthy distrust for large-scale, complex
automation where the system is making a lot of decisions on its own,
because of the risk to experience a major outage due to the "ghost in the
machine” - for them, that makes having a means to observe/manipulate/fix
things independent of the machinery is a non-negotiable requirement, at
least until there is some trust built up that the machine isn’t going to
go insane and nuke the network. There’s a reason I’m using the language
I’ve chosen here, the fears are not totally rational, but they do serve as
a real barrier to deployment, so we ignore them at our own peril.

>will span the architectures well enough to be standardized.
WG] Well, I think there’s a valid traceability and troubleshooting
requirement in the form of needing the ability to do verification and
examination of the state and actions taken by I2RS agent(s) without
invoking the agent being examined. We don’t need to be prescriptive on the
format for that information, nor the method for providing that independent
avenue for accessing it, we must only note that it needs to be available.
For example, in a routing element that doesn’t really have a CLI, the
independent method doesn’t have to be via CLI, it could be via a web UI or
some pretty GUI if that’s the other method to manage the device. I mention
CLI as an example because for the most part, the fail-safe method for
interacting with the routing system today is indeed CLI.

Thanks
Wes George

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 16:14:27 -0400

Wes,

[snipping a lot of very good commentary that the authors should pay
attention to.]

On Tue, Jun 10, 2014 at 03:53:27PM -0400, George, Wes wrote:
> WG] Well, I think there???s a valid traceability and troubleshooting
> invoking the agent being examined. We don???t need to be prescriptive on the
> For example, in a routing element that doesn???t really have a CLI, the
> independent method doesn???t have to be via CLI, it could be via a web UI or
> some pretty GUI if that???s the other method to manage the device. I mention

The traceability draft should hopefully give you the "what was requested"
end of the auditing spectrum.  (Please comment in that thread, if
otherwise.)

What I believe you're asking is roughly something like the following text in
the architecture draft:

X. Operational Considerations

In order to facilitate troubleshooting of routing elements implementing I2RS
agents, those routing elements should provide for a mechanism to show
actively provisioned I2RS state.  Note that this information may contain
highly sensitive material subject to the Security Considerations of any data
models implemented by that Agent and thus must be protected according to
those considerations.

?

-- Jeff

---

From: t.petch <[email-masked]>
Date: Wed, 11 Jun 2014 12:53:34 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2014 2:41 PM

> Thanks for the comments.
<snip>
> Are there specific edits you would suggest to clarify the document?

I think that the problem is pervasive.  'State' appears everywhere,
starting with the Abstract in this I-D, and also on the list, and I
really
do not know what it means. It gets qualified -
protocol state, active state, programmed state, routing-related state,
operational state, structured information and state that is frequently
not directly configurable, ephemeral state, dynamic system state, static
system state etc.
- but perhaps the killer phrase comes in 6.2 I2RS State Storage with
"These sets of data form the I2RS data store."

The model in the Ops Area, which might be familiar to those enthusiastic
about YANG and NETCONF, is a split into 'config' and 'state' as in
RFC6241, a split that was explicitly requested by Operators (RFC3535) so
using the term state in a different sense here I struggle with.  At
least a definition is needed to contrast it with the Ops Area usage (but
I am too unclear to offer such a definition).

Tom Petch

---

From: t.petch <[email-masked]>
Date: Wed, 11 Jun 2014 16:14:58 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Jeffrey Haas" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2014 7:07 PM
> [retaining lots of content for context]

now elided as it is not so much about references to extracts of the
architecture I-D

<snip>
>     context if they are determined to have heavy overlap?

Jeff

Yes, I saw the thread - I think I started it and ended it!

Leaving aside the question of just what objects I2RS wants to edit that
NETCONF cannot (perhaps none:-), the rest of that thread seems clear to
me.

The architecture I-D talks of data store which I think unclear; I think
that it should be datastore, as used in Ops Area (e.g. by NETCONF).

The view that has evolved, and is reflected in the thread,  is that
NETCONF 'config true' is not really the configuration.  The real
configuration is the operational state, part learnt from protocols and
hardware and part derived from 'config true'; but 'config true' is only
what the operator would like to happen, the operational state is the
reality.

Currently we only have 'config true' written by NETCONF in a
configuration datastore (with operational state not being part of any
datastore, just part of state, using that term in the Ops Area sense).
What I2RS then adds is an I2RS datastore, may be one, may be several,
which is another expression of hope as to what the box will do;
operational state, as ever, tells us what actually happens.  The rules
of persistence for I2RS are whatever I2RS wants them to be with no
impact on NETCONF.

So I suggest that it is wrong, as I and others have said in the past, to
talk of editing operational state; the writing of the basic NETMOD
models have shown that that does not work.  The model that has evolved
is what I call twin trees, one of 'config true' - an aspiration of the
operator - and the other of 'config false' - operational state, the
reality.  You can see signs of this in the NETMOD models of
interfaces-cfg, routing-cfg, system-cfg and so on.

I2RS then adds a third tree to the model, of what it would like the box
to do.  I2RS would also need to specify how to resolve conflicts between
NETCONF and I2RS should they specify different values for the same
object.  This is already an issue, IMO not fully resolved, when the user
and the system have different views of what should happen -  look for
user-controlled and system-controlled in interfaces-cfg.

So one module, three trees, an additional YANG substatement for a leaf
that is writable by I2RS.

Tom Petch

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Jun 2014 11:45:31 -0400

I would agree to calling it a YANG datastore if the archtiecture was to 
be conditioned on the data model.
As I understand it, we are not supposed to put the horse and cart in 
that order.  So I prefer the less specific wording we now use.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Jun 2014 11:15:33 +0200

> what the operator would like to happen, the operational state is the

Yes, although platforms that control all channels through which the operator can interact with the box often try to pretend that config and operational state are the same. It is reflected somewhat in the design of YANG where operational state data (config false) may be embedded within the configuration tree.

> of persistence for I2RS are whatever I2RS wants them to be with no

Agreed.

> interfaces-cfg, routing-cfg, system-cfg and so on.

Yes, and I plan to propose that the relationship of such twin trees be formally stated in YANG models - currently it is only explained in descriptions. 

> user-controlled and system-controlled in interfaces-cfg.

It is necessary to think about some arbitration rules that prevent NETCONF and I2RS (or other means for changing operational state) to stomp on each other's toes. I don't think though this has anything to do with user/system-controlled interfaces. 

> that is writable by I2RS.

Rather than inventing new annotations, I'd rather like to see making YANG less NETCONF-specific so that it could directly define schema and constraints for other datastores such as the one for I2RS.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Jun 2014 09:26:47 -0400

>end of the auditing spectrum.  (Please comment in that thread, if

I’ll read through the draft, at the latest when the adoption call hits,
and make comments with this in mind.

>models implemented by that Agent and thus must be protected according to

Yes, I think the only thing that misses is the need for it to be
independent of the agent itself.

Wes

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 12 Jun 2014 19:37:10 -0400

> Given the above, do you still think 7.1 needs additional clarification?

Yeah, this makes sense.

> However, I'm not sure if it's one we'd want to mandate in the architecture.

Maybe, but I worry about Client A and Client B not being able to write 
to each others state.  If Client B is a supervisory app, wouldn't it 
need to act as Client A?

> restart" type semantics, if appropriate.

That could be.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Jun 2014 20:06:48 -0400

With regard to the question below, I think that there are some corner 
cases regarding authorization sharing that we will probably need to 
discuss.  I am concerned that trying to solve the corner cases for 
non-transparent failover (either to a replacement or to a parent) are 
going to be tricky to get right.

I think that the basic architecture we have is probably a good starting 
point.  For example, it asserts that in normal operation there is no 
such thing as a supervising client (B) with rights to over-write state 
created by regular client.  I think that introducing such a notion 
explicitly would create a lot of complexity.

Note that by using the priority mechanism, such over-riding can be done, 
but it will be considered an indication of an exceptional error 
condition.  Which it seems it is.  I think generally having one client 
guess what another client was trying to accomplish with a change 
(supervision) is simply ripe for trouble.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 17:21:57 -0400

Hi Joe,

I'm sorry I missed this set of comments earlier.  Responses in-line.

Alia

On Fri, Jun 6, 2014 at 5:33 PM, Joe Marcus Clarke <[email-masked]> wrote:

> something that is at the same time safe to modify via the configuration but
> is not exposed via the configuration.  That is, how would one know what is
> safe?  This might benefit from an early example to clarify what is meant
> and perhaps it is good enough to drop the bit about modifiable via local
> configuration and just say that modification of protocol internal state is
> out of scope.
>

[Alia] Many of the aspects of the RIB information model aren't generally
exposed via configuration but are safe to expose.  The full sentence is:
"I2RS will only permit modification of state that would be safe,
conceptually, to modify via local configuration; no direct manipulation of
protocol-internal dynamically determined data is envisioned."

I like the first part because it helps scope what I2RS can do; the second
part is more specific.  I really don't think an example is useful here;
it'd derail the document.

> ===
>
> In section 1.2, the new text helps to show how App, Client, and Agent fit
> together, but I wonder if this same new text wouldn't benefit from a
> statement that App to Client communication is out of scope.  That is, you
> state that the Client and Agent communicate via an asynchronous protocol,
> but nothing is said about, for example, how apps C, D, E communicate with
> Client P.  You do mention this further down in the doc, so it's a minor
> thing, but perhaps worth a sentence here.
>

[Alia]  I've added in " The details of how applications communicate with a
remote client is out of scope for I2RS." to the second paragraph in 1.2.

> Based on the information and the policy oriented interactions, the I2RS
> client may also interact with I2RS agents to modify the state
> The first part makes sense, but then it starts to sound muddled, at least
> to me.  Maybe you want to say:
>
> Based on the information and the policy oriented interactions, the I2RS
> client may also interact with I2RS agents to modify the state

[Alia] Agreed it was awkwardly worded.  Changed to
"Based on the information and the policy oriented interactions, the I2RS
client
may also interact with I2RS agents to modify the state of their associated
routing
systems to achieve operational goals. "

> communications via I2RS will not...  I think this should say may not just
> to make it clear that this can be optional based on specific environmental
> requirements.
>

[Alia] Sure - changed to "may not" from "will not".  The point of the
paragraph is to point out different security requirements on the transport
may apply - not to target what they are or which information may be
targeted.

> like NETCONF over BEEP, one goal might be to make sure the transport chosen
> is both operator and implementor friendly in terms of ease of adoption.
>

 [Alia] Sure - added to the end of the paragraph
"The transports chosen should be operator and
implementor friendly to ease adoption."

[Alia] I also updated this paragraph to refer to the WG's decision to base
I2RS on NETCONF and RESTCONF.

> Client to accept some meta-instructions at the beginning of a session as to
> what to do if the app goes away (as you state in paragraph 4).
>

[Alia] Yes, a supervisory application could work.  This section changed in
-03, but please wait until I publish -04 and then comment on that.

Thanks for the review!  I really do appreciate your careful and thoughtful
work.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 17:34:17 -0400

Hi Robert,

Thanks for the review.  Comments in-line.

> in I2RS Agent or in global router's RIB ?

[Alia] Well, each I2RS Client will have a priority that the I2RS Agent uses
to
determine who wins - but we agreed to set the multiple writers of the same
state as an "error".

[Alia] I'd argue that the applications are set up by network operators to do
something and having them collide is something that an operator would need
to investigate.   In the meantime, the I2RS system would just assure
predictability
and avoid oscillation.

> It may be good for architecture document to be able to comment on it.

[Alia] Good point.  In Sec 7.2 on Communication Channels, I've added:

"I2RS protocol communication can be delivered in-band via the
routing system's data plane.  I2RS protocol communication might be
delivered out-of-band via a management interface.  Depending on what
operations are requested, it is possible for the I2RS protocol
communication to cause the in-band communication channels to stop
working; this could cause the I2RS agent to become unreachable across
that communication channel."

> Is OEM hidden within the "Dynamic Data & Statistics" or is it just

[Alia] Hiding - if you have text that you'd suggest, please do.

Thanks for the careful review,
Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 23 Jun 2014 17:45:56 -0400

On 6/23/14, 5:21 PM, Alia Atlas wrote:
> [Alia] Yes, a supervisory application could work.  This section changed
> in -03, but please wait until I publish -04 and then comment on that.
>
> Thanks for the review!  I really do appreciate your careful and
> thoughtful work.

Thanks, Alia.  I agree with your changes and comments.  I appreciate the 
follow-up.  I will definitely look over -04.

Joe

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:11:21 -0400

Hi Wes,

Thanks for your thoughtful review.  Responses in-line.

Alia

> OR the actual interface to the routing system and related protocol.

[Alia] Before the diagram at the end of the paragraph, I've added:
" The scope of the data-models used by I2RS extends across the entire
      routing system and I2RS protocol."
and updated the text inside the figure under the block-diagram to say

"
  <-->  interfaces inside the scope of I2RS Protocol
  +--+  objects inside the scope of I2RS-defined behavior

  <**>  interfaces NOT within the scope of I2RS Protocol
  +**+  objects NOT within the scope of I2RS-defined behavior

  ....  boundary of a router supporting I2RS
"

> one more bolster to the need for a different protocol to do this work.

[Alia]  Ok - I added to the end of that paragraph:

" Additionally, on March 2, 2014, the IESG issued a statement about
Writeable MIB Modules which is expected  to limit creation of future
writeable MIB modules."

> available via other sources.

[Alia]  Good catch - added in "flow data" to the "Dynamic System State:"
description
so that the sentence now reads:

"Such state may include various counters, statistics, flow
data, and local events.
"

> is a pretty important thing from a traceability and failure management

[Alia]  At the end of Section 6.3, I added

"On a routing element, it is critical that there is a way of
reviewing (e.g. via the CLI) the changes made by each associated I2RS
Agent and its state data.  Preferably, this mechanism should use a
different priveleged mechanism other than simply connecting as an I2RS
client to learn the data.  Using a different mechanism should improve
traceability and failure management."

Thanks again,
Alia

> Thanks
>
> Wes George
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:22:02 -0400

Hi Tom,

> that I2RS will do that NETCONF potentially cannot.

[Alia] Partly, it is a different system model - where the agent can preempt
a written
operation or refuse a request - whether there is the idea and support for
multi-headed
control.   I do think that there will be a lot of similarities with what
RESTCONF can
support - but also that there are gaps.

> given it a precise definition which is at odds with its use here.

[Alia]  As I understand it, state is the operational state in the router -
and that is
what is being discussed in general in this document.  A while ago, I did go
over the
different terminology with Ron Bonica and Dean - when I realized that my
perspective
of "configuration state" was from inside a protocol implementation and so
what was
considered "operational state" different from the "configuration
data-stores".   In this case,
I think that the document can be understood without a precise definition of
state - or having
it match that in the Ops Area and differ from that commonly used in Routing.

[Alia] I do appreciate your review and different perspective.  Thanks for
taking the time and interest!

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:23:07 -0400

Hi Jim,

I would request that you take a look at the various use-cases drafts.  We
did try and pull from those use-cases to motivate the architecture as well.
 I'd be happy to discuss off-line.

Thanks,
Alia

On Tue, Jun 10, 2014 at 8:35 AM, UTTARO, JAMES <[email-masked]> wrote:

> A document clearly stating the reqs would help me understand the need I2RS
> is addressing. I would suggest writing the reqs info doc first
>
> Jim Uttaro
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:40:42 -0400

Hi Tom,

> NETCONF, no need for I2RS!

[Alia] If the state couldn't be set via CLI/NETCONF/SNMP etc, then the
state will revert
to the system default or what was dynamically learned (if that was
something safe to
be overwritten).  This is describing what the behavior should be when
written state is
deleted by I2RS - not making a statement on what the scope of the models
are.

> nothing there it seems that C/N/S cannot do

[Alia] Again - generically changes can originate - but that doesn't mean
that the full scope
will originate from either.  Collisions and interactions are of interest
when they both can.

> (which I have seen on the list w.r.t. the BGP RIB).

[Alia] Right - because doing so seriously risks breaking the routing
protocol and leading
to incorrect behavior.  Let's crawl before we run a marathon!

> which again implies that I2RS and C/N/S are writing to the same data.

[Alia] If C/N/S write to the config which then writes to the operational
data and
I2RS writes to the operational data, what is the final content of the
operational data?
If I2RS can write set A and C/N/S can write set B, saying that A & B overlap
doesn't imply that A == B.

> to change a link metric:-)

[Alia] Remember that low latency, high throughput, and asynchronous
operations are
all aspects of what I2RS is facilitating.  There's a big difference between
change one and
change 1000+ in less than a second.

> not.

[Alia] Personally, I think that I2RS will write lower-level abstractions
(all the details for the
RIB info-model which aren't a standard part of configuration) and subsets
of data that need
to change fast - plus being a good interface for push notifications and
event streams.  If you
are looking for examples, I'd look at the use-cases.

> such ie more of an implementation detail than a high level strategy.

[Alia] True - and if I2RS is designed and implemented well, possibly
higher-level abstractions will also
be possible.  We see the start of that at the desire to have a single
abstract link-state topology for reading,
for instance.  The WG is chartered to crawl first and see what's feasible.
 Getting the problem-statement and
architecture out of the way, along with the language and protocol base
selection that has happened, is
likely to open up the ability to seriously discuss detailed models.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:46:55 -0400

Hi Sri,

Thanks for your thoughtful review!  Responses in-line.

On Tue, Jun 10, 2014 at 3:08 PM, Sriganesh Kini <[email-masked]

> too. Which one is correct ? I would suggest that the language be updated to

[Alia]  I think the confusion is that there are two mechanisms - one to
ensure predictability that the I2RS Agent does and one for the I2RS Client
to use to realize when its operations have been preempted.  I've clarified
the "The mechanism for this is to" to say
"The mechanism for ensuring predictability is to have a simple priority
associated with each I2RS clients, and the highest priority change remains
in effect."

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:53:46 -0400

Hi Wes & Jeff,

The problem with responding to email in order as I update the draft is
finding useful nuggets like this.
I've removed the previously suggested text from the "Interactions with
Local Config" section and updated
the "Manageability Considerations" section to be "Operational and
Manageability Considerations" and plunked
the following as the first paragraph.

"In order to facilitate troubleshooting of routing elements
  implementing I2RS agents, those routing elements should provide for
  a mechanism to show actively provisioned I2RS state and other I2RS
  Agent internal information.  Note that this information may contain
  highly sensitive material subject to the Security Considerations of
  any data models implemented by that Agent and thus must be protected
  according to those considerations.  Preferably, this mechanism
  should use a different privileged means other than simply connecting
  as an I2RS client to learn the data.  Using a different mechanism
  should improve traceability and failure management."

Does that work for you both?

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 18:57:16 -0400

Hi Lada,

On Thu, Jun 12, 2014 at 5:15 AM, Ladislav Lhotka <[email-masked]> wrote:

> Yes, although platforms that control all channels through which the
> operator can interact with the box often try to pretend that config and
> operational state are the same. It is reflected somewhat in the design of
> YANG where operational state data (config false) may be embedded within the
> configuration tree.
>
> >
> Yes, and I plan to propose that the relationship of such twin trees be
> formally stated in YANG models - currently it is only explained in
> descriptions.
>
> >
> It is necessary to think about some arbitration rules that prevent NETCONF
> and I2RS (or other means for changing operational state) to stomp on each
> other's toes. I don't think though this has anything to do with
> user/system-controlled interfaces.
>

[Alia] We described the arbitration rules in Section 6.3 of
draft-ietf-i2rs-architecture-03.

> Rather than inventing new annotations, I'd rather like to see making YANG
> less NETCONF-specific so that it could directly define schema and
> constraints for other datastores such as the one for I2RS.
>

[Alia] Please - I think there are different assumptions...

Regards,
Alia

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Jun 2014 11:53:40 +0200

> draft-ietf-i2rs-architecture-03.

I guess we have to think about a proper representation of operational state and ways for tagging its contents or otherwise signalling what caused a particular change.

For instance, if a configured static route is not present in a RIB (operational state), it may be because

- the next hop wasn't reachable when the static route was configured, or

- the I2RS agent deleted it.

The NETCONF server should be able to discriminate between these two cases because its action (reinstall the route or not)  may depend on it.

Lada

---

From: "George, Wes" <[email-masked]>
Date: Tue, 24 Jun 2014 08:46:09 -0400

WFM

Thanks,

Wes

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 23, 2014 at 6:53 PM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

Hi Wes & Jeff,

The problem with responding to email in order as I update the draft is finding useful nuggets like this.
I've removed the previously suggested text from the "Interactions with Local Config" section and updated
the "Manageability Considerations" section to be "Operational and Manageability Considerations" and plunked
the following as the first paragraph.

Thanks,
Alia

On Thu, Jun 12, 2014 at 9:26 AM, George, Wes <[email-masked]<mailto:[email-masked]>> wrote:

Wes

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Jun 2014 09:42:21 -0400

> Does that work for you both?

Works for me.

-- Jeff

---

From: Alia Atlas <[email-masked]>
Date: Tue, 24 Jun 2014 09:55:43 -0400

Hi Lada,

On Tue, Jun 24, 2014 at 5:53 AM, Ladislav Lhotka <[email-masked]> wrote:

[removing fine conversation]

> I guess we have to think about a proper representation of operational
> state and ways for tagging its contents or otherwise signalling what caused
> a particular change.
>

[Alia] I think that this is actually implementation-dependent and find the
idea of trying to tag operational state to be excessively complex and
downright scary.  IMHO, the interaction needs to be between the config
system and I2RS.

> - the next hop wasn't reachable when the static route was configured, or
[Alia] I think this is a bad example.  The route can still go in - it's
just not active.  Anyway, that's expected to happen in I2RS.

> - the I2RS agent deleted it.

In that case, the I2RS agent should have notified the config, IMHO.

The NETCONF server should be able to discriminate between these two cases
> because its action (reinstall the route or not)  may depend on it.
>

With a better example, yes.

Alia

> >> >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB
> but
> >> > the
> >> >> > I-D goes on to say
> >> >> In some cases, the overlap with config state will be quite obvious
> and
> >> > your
> >> >> require a system reconfiguration event.  If you want to point out
> that
> >> > the
> >> >> relationship is strong and that the defining differences are shallow
> -
> >> > you
> >> >> I hesitate to frame it this way, but one example application is a
> form
> >> > of
> >> >> If you want to argue that such a higher level model is simply
> netconf,
> >> > then