Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 12:11:45 -0400

Hi Carlos,

Thanks for the review and comments.  Responses in-line now that I'm home
and recovered from IETF.

Alia

On Sun, Jul 28, 2013 at 5:07 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I support I2RS adoption of this document.
>
> This is a very nice document. I also wanted to provide a small set of
> review feedback comments (marked with "CMP"):
>
>            Interface to the Routing System Problem Statement
>                  draft-atlas-i2rs-problem-statement-01
>
> Abstract
>
>    In order to enable applications to have access to and control over
>    information in the Internet's routing system, we need a publicly
>    documented interface specification.  The interface needs to support
>
> CMP: Where it says "In order to enable applications", I wonder if we need
> to further qualify "network applications", to differentiate a custom
> routing app versus a db query. Note this comment applies also to the
> Introduction.
>

[Alia] Sure.

>    This document expands upon these statements of requirements to
>    provide a detailed problem statement for an Interface to the Internet
>    Routing System (I2RS).
>
> CMP: The acronym does not expand, "Interface to the Internet Routing
> System" seems to be "I2IRS" (extra Internet).
>

[Alia] Ok - I've taken out Internet.  Really, the interface applies
regardless.

> 2.  I2RS Model and Problem Area for The IETF
>
>                    Figure 1: I2RS model and Problem Area
>
> CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS
> Agent. For model completeness, would it make sense to add another "<-->"
> (i.e., within scope) interface from the leftmost I2RS client into a
> different I2RS Agent? Even something like "<-----> To another I2RS Agent".
>

[Alia] Sure

3.  Standard Data-Models of Routing State for Installation
>
>    There is a need to be able to precisely control routing and signaling
>    state based upon policy or external measures.  This can range from
>
> and
>
>    In addition to interfaces to the RIB layer, there is a need to
>    configure the various routing and signaling protocols with differing
>    dynamic state based upon application-level policy decisions.  The
>
> CMP: It is not clear to me what "signaling" specifically refers to here.
>
> 3.  Standard Data-Models of Routing State for Installation
>
>    This means that, to usefully model
>    next-hops, the data model employed needs to handle next-hop
>    indirection (e.g. a prefix X is routed like prefix Y) as well as
>    different types of tunneling and encapsulation.
>
> CMP: a nit: "indirection", or "indirection and recursion"?
>
[Alia] sure

5.  Desired Aspects of a Protocol for I2RS
>
>    Multiple Simultaneous Asynchronous Operations:   A single application
>       should be able to send multiple operations to I2RS without being
>       required to wait for each to complete before sending the next.
>
> CMP: "via I2RS" instead of "to I2RS".
>

[Alia] sure

   Duplex:   Communications can be established by either the I2RS client
>       (i.e.: that resides within the application or is used by it to
>       communicate with the I2RS server), or the I2RS server.  Similarly,
>
> CMP: Should "I2RS agent" be used instead of "I2RS Server", for
> nomenclature consistency?
>

[Alia] Yes - good catch

>
> 5.  Desired Aspects of a Protocol for I2RS
>
> CMP: I think there are some aspects potentially missing. Specifically:
> CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting for
> the same route)
> CMP: 2. Security (and specifically integrity)
> CMP: 3. Accounting.
>

[Alia] I think that (1) belongs in the architecture.  I agree that it is
important - but I feel that the problem-statement part is covered in the
Multi-Headed Control.
(2) is mostly covered in "Secure Control".  I did add "Such communications
must also have its integrity protected." since we hadn't mentioned
integrity but just authentication and authorization.
For (3), I'm not sure what aspects specifically apply to I2RS...  We have
authentication and authorization and, in the architecture, tracking of
state written.  What knobs or functionality are you looking for in
accounting?

Alia

> Thanks!
>
> -- Carlos.
>
>
> On Jul 24, 2013, at 11:53 PM, Alia Atlas <[email-masked]> wrote:
>
> > Please review draft-atlas-i2rs-problem-statement-01 and comment on
> whether it should be adopted by I2RS.  Detailed technical conversation is
> also most welcome.
> >
> > Authors: Are you aware of any IPR that applies to
> draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed
> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> more details).
> >
> > This WG call for adoption will complete on August 12.
> >
> > Thanks,
> > Alia
> > _______________________________________________
> > i2rs mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 12:23:42 -0400

Hi Kwang-koo,

Thanks very much for your comments.  My responses are in-line.

On Mon, Jul 29, 2013 at 7:54 AM, KwangKoog Lee <[email-masked]>wrote:

> Hi. This is Kwang-koog from kt which is one of major network providers in
> South Korea.
> First, I appreciate a vast of contributions by i2rs members for enabling
> intelligent and simple routing operations.
>
> As Alia mentioned in her draft, many network providers including kt
> today have very huge and complex routing networks
> according to the growth of the IP-based services but they really need
> simple operation and new business model for covering a number of use cases
> on that.
> With the benefit of the distributed routing manner, modern routing systems
> easily plugged into a designated routing network and
> forward user packets to desired destinations. But, in the operator
> perspective, policy-based routing control and necessary optimizations for
> routing are always major issues for them because it is very hard to control
> multi-vendor ruters with their own proprietary functions.
>
> Our company has operated huge routing systems with the size of thousands
> of routing systems during tens of years
> and made a significant effort to optimize routing systems.
> So, current routing systems support preferable service level aggrement and
> traffic utilization is optimized by the our own planning rules.
> However, to this end, there have been even much trial-and-error and many
> times.
> So, I expect that the works of i2rs help network providers to easily
> control their network and also support many usecases from our customers.
>

[Alia] I would welcome your thoughts and feedback on the use-cases that
I2RS is currently discussing.  Additional use-cases would also be quite
welcome (given that they fit in the charter)
to help scope what information in the models are needed.

>
> I also think Alia clearly stated such concerns of modern routing
> systems so that I also support the WG adoption.
> I2RS members pointed out many comments and feedbacks for enhancing that
> document which I also agree with.
>
> In addition, I give a small comment to her draft for "Sec. 5 desired
> aspect of a protocol for i2rs"
> That is "*interoperability between protocol versions*".
> For example, newly defined software define network protocols such as
> openflow rapidly changed and a bunch of functions are added.
> But, nobody does consider the interoperability of such protocols.
> I think providers are very wonderring that different version protocols can
> be inter-working or not.
> So, I want to comment that i2rs protocol has to have this aspect.
>

[Alia]  A good point.  I've added:
  "Extensibility and Interoperability:  Both the I2RS
      protocol and models must be extensible and interoperate between
      different versions of protocols and models."

Thanks,
Alia

> Thanks.
>
> sincerly,
> Kwang-koog Lee (Ph.D)
> the advanced institue of technology of kt, South Korea
>
>
> On Mon, Jul 29, 2013 at 7:52 PM, Jon Mitchell <[email-masked]>wrote:
>
>> On 24/07/13 17:53 -0400, Alia Atlas wrote:
>> whether
>> > it should be adopted by I2RS.  Detailed technical conversation is also
>> most
>> > welcome.
>> >
>>
>> Support adoption.. some small issues to authors direct.
>>
>> -Jon
>>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 12:29:53 -0400

On 8/14/13 12:11 PM, Alia Atlas wrote:
> (2) is mostly covered in "Secure Control".  I did add "Such
> communications must also have its integrity protected." since we hadn't
> mentioned integrity but just authentication and authorization.
> For (3), I'm not sure what aspects specifically apply to I2RS...  We
> have authentication and authorization and, in the architecture, tracking
> of state written.  What knobs or functionality are you looking for in
> accounting? 

I'll comment here, and I'm sure Carlos will chime in with anything I
miss or if he sees things differently.

Coming from a services/support mindset, accountability from a tracing
point of view is important.  I would like to see a history of actions
performed, the client that performed them, when the actions were
performed (with very granular timestamps), and the result code.

Forgive me for using a vendor reference here (as an example), but in
Cisco IOS we have the buffer of CLI commands executed and syslog
messages generated.  This buffer is very useful when it comes to tracing
a crash back to potential triggers.  As we look to incorporate our own
APIs, we want to provide the same kind of history log to try and tie API
calls back to potential problems on the device.

With I2RS in particular, while crashes are certainly possible, being
able to look back at operations and correlate problems like packet loss,
service interruption, performance deviations, etc. will be vital from a
troubleshooting standpoint.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 12:39:11 -0400

Hi Joe,

I certainly agree that keeping logs of the APIs done and their results or,
perhaps, having the ability to mirror the requests and responses to a
collector would be useful.

With CLI, I agree that this is frequently done with syslog today - which
then necessitates vendor-specific code to scrape through.

What would be a meaningful accountability framework that would be
appropriate and, hopefully, not require vendor-specific screen-scraping?

Completely off the top of my head, I can see the following ideas:
   (a) mirror all (or a meaningful subset) messages in/out to a collector
that then stores/sorts/logs the information
   (b) Define an accountability information model that defines what should
be stored and have it stored in the canonical form required by the selected
data-model.  Perhaps mandate it be stored in a file for acquisition?  Have
the ability to read it?

and I'm sure that there are many others...

I do think this is an important area and it could use some good discussion
(and even a draft or a section to go into the architecture).

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 12:45:40 -0400

I believe I have addressed all of the comments about
draft-atlas-i2rs-problem-statement-01 in the updated and just posted
draft-atlas-i2rs-problem-statement-02.  Please let me know if I've missed
anything or if you have more comments on this draft.

Thanks,
Alia (wg-chair hat off)

On Wed, Jul 24, 2013 at 5:53 PM, Alia Atlas <[email-masked]> wrote:

> Please review draft-atlas-i2rs-problem-statement-01 and comment on whether
> it should be adopted by I2RS.  Detailed technical conversation is also most
> welcome.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 13:28:08 -0400

I would expect that kind of kistory creation to be handled by something 
like a syslog event report, rather than by anything internal to I2RS. 
We do not normally specify as part of the protocols all the syslog 
events they should generate, do we?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 13:29:33 -0400

These look like things outside of the scope of I2RS>  I would not want 
to define message mirroring as part of the transport protocol 
requirements, for example.

yours,
Joel

On 8/14/13 12:39 PM, Alia Atlas wrote:
> Hi Joe,
>
> I certainly agree that keeping logs of the APIs done and their results
> or, perhaps, having the ability to mirror the requests and responses to
> a collector would be useful.
>
>     (a) mirror all (or a meaningful subset) messages in/out to a
> collector that then stores/sorts/logs the information
>     (b) Define an accountability information model that defines what
> should be stored and have it stored in the canonical form required by
> the selected data-model.  Perhaps mandate it be stored in a file for
> acquisition?  Have the ability to read it?
>
> I do think this is an important area and it could use some good
> discussion (and even a draft or a section to go into the architecture).
>
> Alia
>
>
> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>         c
>     i s c o  S y s t e m s
>     Email: [email-masked] <mailto:[email-masked]>
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 13:35:09 -0400

Yes, I agree that requiring someyhing like transport mirroring would be
unfortunate.

I also don't think that we should be defining required syslog messages.

But the interesting question is whether something reasonable could be done
for vendor-agnostic traceability...

Alia
On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <[email-masked]> wrote:

> These look like things outside of the scope of I2RS>  I would not want to
> define message mirroring as part of the transport protocol requirements,
> for example.
>
> yours,
> Joel
>
>>     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-**2867>
>> c
>>     i s c o  S y s t e m s
>>     ------------------------------**------------------------------**
>> ----------------
>>
>>
>>
>>
>> ______________________________**_________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>
>>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 13:44:28 -0400

On 8/14/13 1:35 PM, Alia Atlas wrote:
> But the interesting question is whether something reasonable could be
> done for vendor-agnostic traceability...

Yes, that was my point.  This would be data that, in my mind, could be
queriable via I2RS.

Joe

> 
> Alia
> 
> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     These look like things outside of the scope of I2RS>  I would not
>     want to define message mirroring as part of the transport protocol
>         On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>              > important - but I feel that the problem-statement part is
>         covered
>             in the
>              > Multi-Headed Control.
>              > communications must also have its integrity protected."
>         since we
>             hadn't
>              > have authentication and authorization and, in the
>         architecture,
>             tracking
>             Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>
>         <tel:%2B1%20%28919%29%20392-__2867>         c
>             i s c o  S y s t e m s
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>            
>         ------------------------------__------------------------------__----------------
> 
> 
> 
> 
>         _________________________________________________
>         i2rs mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Aug 2013 13:50:01 -0400

Are you asking that the history data itself be readable with I2RS?  I 
really would not want to go there.  Asking "who created the current 
state, CLI or specific named I2RS client, might be reasonable.

Yours,
Joel

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 16:18:41 -0400

> state, CLI or specific named I2RS client, might be reasonable.

I am suggesting the history (as well as current state) be readable via
I2RS itself.  In that manner it could be vendor-agnostic by which
traceability can be done.   Current state could be understand who
installed a route and when (Client identifier and timestamp).  But there
could be conditions where a Client had a route installed then removed
it.  If you wanted to correlate a period of bad performance, you would
like to be able to query I2RS to see what changed in a particular time
frame.

Joe

>>>          With CLI, I agree that this is frequently done with syslog
>>> today
>>>          - which
>>>               > [Alia] I think that (1) belongs in the architecture. 
>>> I agree
>>>              that it is
>>>              APIs, we want to provide the same kind of history log to
>>> try
>>>          and tie API

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 17:35:58 -0400

I can see having it in a file for displaying or sending - but actually
having the I2RS agent crawl through it to report the data back???

Alia

On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke <[email-masked]>wrote:

> >>>               > For (3), I'm not sure what aspects specifically apply
> to
> >>>          I2RS...  We
> >>>              Coming from a services/support mindset, accountability
> from
> >>>          a tracing
> >>>              able to look back at operations and correlate problems
> like
> >>>          packet loss,
> >>>              Phone: +1 (919) 392-2867<tel:%2B1%20%28919%29%20392-2867>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 17:46:30 -0400

> having the I2RS agent crawl through it to report the data back???

A file/buffer is fine, but will lead to vendor-specific ways of getting
at the data.  As I read the architecture concerning information
collection, I thought this might be very useful information for a Client
to collect from the Agent.

I know Joel disagrees in favor of syslog.  I think syslog is okay, but
only if you're receiving messages since the beginning of time (i.e.,
before a problem is identified).  While I very well may be off base
here, having the a record of what Clients did what on a particular Agent
in a vendor-agnostic way as information to be collected via I2RS seemed
reasonable.

Joe

> 
> Alia
> 
> 
> On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke <[email-masked]
>     <mailto:[email-masked]>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>>
>     >>>          I certainly agree that keeping logs of the APIs done
>     and their
>     >>>          results
>     >>>          <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >>>
>     >>>               > (2) is mostly covered in "Secure Control".  I
>     did add
>     >>> "Such
>     >>>               > For (3), I'm not sure what aspects specifically
>     apply to
>     >>>          I2RS...  We
>     >>>               > of state written.  What knobs or functionality
>     are you
>     >>>          looking for in
>     >>>               > accounting?
>     >>>
>     >>>              I'll comment here, and I'm sure Carlos will chime
>     in with
>     >>>          anything I
>     >>>              Coming from a services/support mindset,
>     accountability from
>     >>>          a tracing
>     >>>              point of view is important.  I would like to see a
>     history
>     >>>          of actions
>     >>>              able to look back at operations and correlate
>     problems like
>     >>>          packet loss,
>     >>>              service interruption, performance deviations, etc.
>     will be
>     >>>          vital from a
>     >>>              Phone: +1 (919) 392-2867
>     <tel:%2B1%20%28919%29%20392-2867> <tel:%2B1%20%28919%29%20392-2867>
>     >>>          <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>>
>     >>>
>     >>>
>     >>>
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Aug 2013 18:28:11 -0400

Ah - I meant a structured file - so the contents are the written
data-model.  Thus, a tool could get the file and parse through it to find
what was desirable.  The structured file would be described in the schema,
extensible as always, to provide something better than syslog - without
asking the I2RS agent to add in that file parsing and reading and such.

Alia

On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke <[email-masked]>wrote:

> >     >>>          or, perhaps, having the ability to mirror the requests
> and
> >     >>>          responses to
> >     >>>          Completely off the top of my head, I can see the
> following
> >     >>> ideas:
> >     >>>              (a) mirror all (or a meaningful subset) messages
> in/out
> >     >>> to a
> >     >>>          should be stored and have it stored in the canonical
> form
> >     >>>          required by
> >     >>>          the selected data-model.  Perhaps mandate it be stored
> in a
> >     >>> file for
> >     >>>              Cisco IOS we have the buffer of CLI commands
> executed
> >     >>> and syslog
> >     >>>              messages generated.  This buffer is very useful
> when it
> >     >>>          comes to tracing

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 18:38:13 -0400

On 8/14/13 6:28 PM, Alia Atlas wrote:
> data-model.  Thus, a tool could get the file and parse through it to
> find what was desirable.  The structured file would be described in the
> schema, extensible as always, to provide something better than syslog -
> without asking the I2RS agent to add in that file parsing and reading
> and such.

Yep, I understood that.  I was going a step further and saying that
because the I2RS architecture defines this information collection
component, the same file could be collected as information.  Thus one
would always have a vendor-agnostic way to get to the file as well as
parse it.

At least to me, this notion seems as applicable to the scope as using
information collection to get something orthogonal to routing such as
CPU utilization.

Joe

> 
> Alia
> 
> 
> On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke <[email-masked]
>     > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke
>     >     >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern"
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >>> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >>>
>     >     >>>          or, perhaps, having the ability to mirror the
>     requests and
>     >     >>>          responses to
>     >     >>>          What would be a meaningful accountability
>     framework that
>     >     >>> would be
>     >     >>>          appropriate and, hopefully, not require
>     vendor-specific
>     >     >>>          screen-scraping?
>     >     >>>
>     >     >>>              (a) mirror all (or a meaningful subset)
>     messages in/out
>     >     >>> to a
>     >     >>>              (b) Define an accountability information
>     model that
>     >     >>> defines what
>     >     >>>          should be stored and have it stored in the
>     canonical form
>     >     >>>          required by
>     >     >>>          the selected data-model.  Perhaps mandate it be
>     stored in a
>     >     >>> file for
>     >     >>>          discussion (and even a draft or a section to go
>     into the
>     >     >>>          architecture).
>     >     >>>
>     >     >>>          Alia
>     >     >>>
>     >     >>>
>     >     >>>          <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>     >     >>>
>     >     >>>               > important - but I feel that the
>     problem-statement
>     >     >>> part is
>     >     >>>          covered
>     >     >>>              in the
>     >     >>>               > Multi-Headed Control.
>     >     >>>               > mentioned integrity but just
>     authentication and
>     >     >>>          authorization.
>     >     >>>              performed, the client that performed them,
>     when the
>     >     >>> actions were
>     >     >>>              performed (with very granular timestamps),
>     and the
>     >     >>> result code.
>     >     >>>
>     >     >>>              Forgive me for using a vendor reference here
>     (as an
>     >     >>>          example), but in
>     >     >>>              messages generated.  This buffer is very
>     useful when it
>     >     >>>          comes to tracing
>     >     >>>              a crash back to potential triggers.  As we
>     look to
>     >     >>>          incorporate our own
>     >     >>>              With I2RS in particular, while crashes are
>     certainly
>     >     >>>          possible, being
>     <tel:%2B1%20%28919%29%20392-2867>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     >>>          <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >    
>     >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <tel:%2B1%20%28919%29%20392-2867>         c
>     >     i s c o  S y s t e m s

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Aug 2013 09:06:48 +0200

> in a vendor-agnostic way as information to be collected via I2RS seemed

Just for your information: RFC 5277 defines a NETCONF extension for
notification delivery which supports the playback of event streams.
This essentially allows implementations to buffer notifications (which
might be syslog messages) for a certain time (or a certain volume) and
one can request a replay of the notifications from a given start time
until a certain stop time, optionally applying a filter to it.

For debugging purposes, such a mechanism (buffering and selected and
filtered playback) seems a reasonable solution that is also relatively
easy to implement. If, however, complete accountability tracking is
the goal, then you need to stream all notifications to an external
server and you probably also need something like SYSLOG signatures
(RFC 5848) to be able to prove that the notification log is complete
etc.

Personally, I think i2rs is likely better off with postponing work on
event notification logging until the primary goals of i2rs have been
met. For early implementors, protocols like SYSLOG likely are good
enough.

/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: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 10:05:53 -0400

First, I hear and agree with Juergen's point that this is a second order
problem.  Still, if there are those
interested in working on it and documenting what would be desirable, a bit
of discussion isn't a bad thing.

Second, the minimum necessary seems to be an info model describing what
should be saved so that the
files can be structured.

Third, we have the idea of multiple transports and transport channels in
I2RS.  I don't think I2RS wants
to get into the game of file transfer or of reading it out message by
message.  Perhaps an operation to
request the file transfer via a different channel (scp, ftp?) would address
both concerns and allow a bit
of experimentation with the multiple transport channel idea?

Alia

On Wed, Aug 14, 2013 at 6:38 PM, Joe Marcus Clarke <[email-masked]>wrote:

> >     >     >>> Yes, I agree that requiring someyhing like transport
> mirroring
> >     >     would be
> >     >     >>> unfortunate.
> >     >     >>>
> >     >     >>> I also don't think that we should be defining required
> syslog
> >     >     messages.
> >     >     >>>
> >     >     >>> But the interesting question is whether something
> reasonable
> >     >     could be
> >     >     >> Yes, that was my point.  This would be data that, in my
> mind,
> >     >     could be
> >     >     >> queriable via I2RS.
> >     >     >>
> >     >     >> Joe
> >     >     >>
> >     >     >>>
> >     >     >>> Alia
> >     >     >>>
> >     >     >>>      These look like things outside of the scope of I2RS>
>  I
> >     >     would not
> >     >     >>>      want to define message mirroring as part of the
> transport
> >     >     protocol
> >     >     >>>          I do think this is an important area and it could
> use
> >     >     some good
> >     >     >>>              APIs, we want to provide the same kind of
> history
> >     >     log to
> >     >     >>> try
> >     >     >>>          and tie API

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 10:10:23 -0400

Juergen,

Thanks for the useful information.  I agree that a focus on traceability is
not an initial primary goal, but Joe's point that syslog isn't
vendor-agnostic is a good one too.  I'm not sure that I see a network
application doing automated troubleshooting and recovery -
but perhaps I'm insufficiently optimistic.

Alia

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Aug 2013 07:31:20 -0700

Hi,

We are going to run into several long-unsolved NM problems
like "standardized log files".  (Knowing that adding such a huge
task to the charter would be a mistake is the difference between
boiling an ocean or just a lake. ;-)

Notifications may not be a 2nd order problem because the
WG punted on the "I2RS broker" role.  Now it is up to
each I2RS Client to know that the RIB state it injected
got replaced by a higher priority client, or know a higher
priority entry was deleted and now maybe it can try again.

IMO, the notification mechanism will need to be quite
sophisticated to filter just the events relevant to a specific client.
More likely all clients will each get all notifications, creating
N fire-hoses of 'add' and 'delete' events.

At the BoF, the metric "5000 updates a second" was mentioned
as the answer to the question "what is fast-path?"  How many
notifications per second are reasonable for I2RS?

Andy

On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas <[email-masked]> wrote:
> On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
>>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 10:39:23 -0400

Hi Andy,

I meant that the traceability and syslog aspects are a 2nd order problem.

I agree very strongly that notifications are a primary concern.  That's how
clients learn
about network changes, changes affecting their state, etc.  I believe that
we need a
sophisticated mechanism to filter and send just the relevant events to the
specific client.
Sending all notifications to all clients would be bad in terms of scaling
and security.

I don't have a fixed number for the notifications per second.  I'm curious
if others have thought
about it?

Alia

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Aug 2013 09:00:21 -0700

Hi,

Maybe it won't be that hard to automatically setup filters
for common use-cases. E.g., if the 'inject' operation
had parameters like 'notify-when-ready' and 'notify-if-bounced',
then the server can send those notifications (just to that client)
if the "inject" fails or gets deleted later, for the specific data entry.

Andy

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Aug 2013 12:06:35 -0400

Exactly - we need to give some real thought to the notifications and how
the filtering is set up.  There's also a distinction between event
notifications and information streams, even though subscription may be
similar.

For notifications, we have ideas such as:
    register for a notification when state written by client X is changed
    register for a notification when a particular state is changed
    notify when route is installed in FIB
    notify if interface utilization is over high-water threshold or under
low-water threshold

For info streams, one could have:
    subscribe to OSPF peer up/downs
    subscribe to route changes (perhaps by protocol or within a prefix
range)

There's the question of describing the desirable notifications and info
streams - and then figuring out how to support them in protocol mechanisms
(and the practicality for a real implementation).

Alia

On Thu, Aug 15, 2013 at 12:00 PM, Andy Bierman <[email-masked]> wrote:

> >> > Thanks for the useful information.  I agree that a focus on
> traceability
> >> > is

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 08:44:43 -0400

>     notify if interface utilization is over high-water threshold or under
low-
> water threshold

The problem, I think, is that we're still not scoped narrowly enough. This
could well be a set of requirements for a network management system as much
as a set of requirements for an SDN... If we're going to be a new management
system, should we move this WG to the management area, and be done with it?
I think we need to be a little careful about what problems we take on from
day one, so we can really narrow down the work we're actually trying to do,
verses what others are already doing --I don't think we should make our
goal, "we want to be a faster NETCONF."

So, to limit these:

1. So long as the state being written is _routing_ state.
2. So long as the state being changed is _routing_ state.
3. This must include when your route is overwritten by another process.
4. Do we really want to consider everything measurable about an interface a
part of the "routing system," from day one? 

The fourth one is particularly bothersome. I can see where interface state
is part of the "routing state," in some broad sense --in reality, though,
everything that goes on on a "router" or a "switch" is technically part of
the "routing state," including memory fragmentation, memory utilization,
local storage read and write speeds, processor temperature, and even the
color of the box. These things are "routers" and "switches," so everything
they do somehow relates to either "routing" or "switching."

Hence, we need to intentionally underclaim in our scope for the moment,
focusing on a few small areas. We tried to do this with the use cases, but
that's not working so well, so maybe we need to limit our scope in more
intentional ways, like saying, "while we understand that interface state
other than simple up/down can be construed as part of the routing system,
we're simply not going to deal with that right now, because just dealing
with up/down, in combination with all the other stuff we're trying to deal
with, is enough to chew on for about the next 5 years already."

If we don't intentionally scope ourselves, we're going to end up in the
drink --a WG that simply churns on lots of big plans, but won't ever be
actually implemented in any useful way, because no-one is going to build yet
another network management system into their boxes alongside the fourteen or
fifteen they already have. 

At least that's my 2c.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Fri, 16 Aug 2013 08:52:16 -0400

> problem.  Still, if there are those interested in working on it and
documenting
> what would be desirable, a bit of discussion isn't a bad thing.

+1

> should be saved so that the files can be structured.

If the I2RS data structures "on the wire," are efficient, atomic, and built
in such a way as to invite extension where needed, why not just make the
structure, "save off the tlvs as you send and receive, so they can be
reparsed according to the same set of rules by some other process later?" In
other words, do we need another format for the same data, if there's already
one in place for on the wire use?

Just a thought...

> Third, we have the idea of multiple transports and transport channels in
I2RS.

+1 --we're already driving enough complexity into this thing... Too much,
honestly. 

Russ

---

From: Scott Whyte <[email-masked]>
Date: Fri, 30 Aug 2013 13:46:50 -0700

> they do somehow relates to either "routing" or "switching."

Russ,
I do not see same the problem you do.  Getting high-resolution, bulk statistics 
off of network nodes with minimal impact to the nodes is required for SDN,
and I2RS is a subset of SDN.  We do not have a method for doing that today.

> with, is enough to chew on for about the next 5 years already."

I am willing to propose a use case and draft a framework
for generic bulk data collection.

I do agree with taking bite-sized chunks; comparing the complexity of
reading data off of network nodes and writing data to them, reading is
substantially easier and it would be good to get that experience under
our belt.  It may help inform a decision if the two directions even
need separate protocols.

Rather than try and specify each and every thing we think is appropriate 
or necessary for I2RS to advertise, I would instead go with an approach like:
 - a standardized way for network nodes to publish what they have available
 - a standardized way for subscribers to select from that list
 - a method to negotiate both formatting and transport

> fifteen they already have. 

I am, it's in progress.  And rather than make blanket statements one
way or the other maybe we should get some operator input.  Perhaps
they have fifteen NMSes because the IETF has failed to give them a
decent solution, and SDN is only going to exacerbate that.

-Scott