Subject: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

From: "Susan Hares" <[email-masked]>
Date: Wed, 3 Jun 2015 20:49:41 -0400

The minutes for the I2RS meeting are at: 

www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-201
5-i2rs-8

These minute provide a lengthy of issues in the requirements.  From these
minutes, there are the following 6 conclusions on the protocol requirements
that Jeff stated: 

1)      There will be no consideration of an overlay model unless a fully
formed proposal is presented. 

Jeff and I appreciate Ken Watsen's comments on the list, but we have had
lots of suggestions regarding 

an overlay proposal - but no full proposal.  At this time, the WG will only
consider full proposals and not 

suggestions toward a proposal. 

2)      Jeff's document provides details on ephemeral state requirements
that have not changed.  These requirements include:

a.       Highly reliable notifications (but not perfectly reliable
notifications) 

b.      High bandwidth, asynchronous interface, with real-time guarantees on
getting data, 

c.       Node identification of clients that write by client identity,
secondary identity, and priority.  Data models will determine what is the
"node" unit.  For example, the I2RS RIB node unit is the route. 

d.      There is one priority per client. 

e.      Priority is kept in the NACM at the client level [rather than path
level (5/27 meeting) or group level (list discussion).  

3)      Joel suggests that large data write may be best done in netconf with
guarantees

a.       I2RS will be focused on highly asynchronous interfaces with less
than full routing tables. 

b.      A client whose large data is interrupted by a notification has a
difficult time determine when the notification happened in the stream - so
the I2RS client must ask the agent again. 

c.       Logging for traceability is different than event notification. 

4)      Secondary identity data is meta-data that is stored in the agent.
Agent does not do anything with the meta-data. The client has to do one edit
per secondary at a time.

5)      Secondary identity data is read-only meta-data that is stored in the
agent associated with a data model node that is being created or updated
(write-access) in the data store.  

6)      I2RS Client and Agent Identities are mutually authenticated by
Authentication server (AAA), 

The values of identities are originally set by operators.   

Does anyone have any concerns regarding these requirements? 

Sue Hares

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jun 2015 18:10:22 -0700

Hi,

Re 2(a) and (b):

Are changes to RFC 5277 being proposed to make notifications
highly reliable, or is there an assumption that implementations
will just provide adequate memory to buffer notifications?

Real time guarantees on getting data sounds like RAI work
is needed?  Are any changes needed to RESTCONF or
NETCONF to support this requirement?  Or is there just
an expectation that implementations will be fast.

IMO, the standard should be silent on response times
and packets per second issues.  Unless a certain speed
is required for interoperability, then it seems inappropriate
to mention in an RFC.

Andy

On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares <[email-masked]> wrote:
> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-2015-i2rs-8
>
>
>
> Jeff and I appreciate Ken Watsen’s comments on the list, but we have had
> an overlay proposal – but no full proposal.  At this time, the WG will only
> 2)      Jeff’s document provides details on ephemeral state requirements
> “node” unit.  For example, the I2RS RIB node unit is the route.
>
> difficult time determine when the notification happened in the stream – so
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Jun 2015 08:24:26 +0200

On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote:
> Jeff and I appreciate Ken Watsen's comments on the list, but we have
> had lots of suggestions regarding an overlay proposal - but no full
> proposal.  At this time, the WG will only consider full proposals
> and not suggestions toward a proposal.

For the record: I am highly concerned about solutions that require (i)
separate data models for ephemeral state and (ii) data model specific
merge logic. While this may work for I2RS, this approach does not
scale or has a very high cost of scaling to other ephemeral state
editing needs.
 
> "node" unit.  For example, the I2RS RIB node unit is the route.

I am concerned about adding protocol mechanisms that are specific to a
certain data model. It is unclear what a "node" unit it, terms like
'highly reliable notifications' and 'high bandwidth, asynchronous
interface, with real-time guarantees' are somewhat unclear - how do we
determine we have met any of these requirements?

> level (5/27 meeting) or group level (list discussion).  

Why does this mapping of username to priority have to be maintained in
NACM?

> c.       Logging for traceability is different than event notification. 

Except c), I do not understand this. What are these 'guarantees' 3)
is about?

> (write-access) in the data store.  

Ehem, what is read-only data that is created or written? Did you want
to say that the identity meta-data is immutable once a data node has
been created? And if so, has priority the same property: Is priority
of a data node is determined at creation time and then immutable?

> The values of identities are originally set by operators.   

I am not sure how agent identity authentication via AAA works. Can
someone point me to the right direction if I assume a secure transport
such as SSH or TLS?
 
/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: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 15:41:49 -0400

Andy: 

2a and 2b:

·         This is just a highly reliable requirement as we talked about in the interim.   It is not perfect, but highly reliable. 

·         No specific changes are being suggested to RFC 5277, but setting this requirement will cause the NETCONF group to consider changes need to be made or can be made.  Implementations must be fast and highly reliable for the normal I2RS data.  We expect the NETCONF group to provide some details on what “fast and highly reliable” means for their protocols.  In the past FORCES proponents gave those numbers. 

·         Joel mentioned that large RIB pulls were not the normal I2RS data. 

I will ask the working group the larger question – Do we need to specify “fast and highly reliable” in terms of response time or packets per second? 

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 9:10 PM
To: Susan Hares
Cc: [email-masked]; Jeffrey Haas; Joel M. Halpern; [email-masked]; Alia Atlas
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

Hi,

Re 2(a) and (b):

Are changes to RFC 5277 being proposed to make notifications highly reliable, or is there an assumption that implementations will just provide adequate memory to buffer notifications?

Real time guarantees on getting data sounds like RAI work is needed?  Are any changes needed to RESTCONF or NETCONF to support this requirement?  Or is there just an expectation that implementations will be fast.

IMO, the standard should be silent on response times and packets per second issues.  Unless a certain speed is required for interoperability, then it seems inappropriate to mention in an RFC.

Andy

>  <http://www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter

> im-2015-i2rs-8

> These minute provide a lengthy of issues in the requirements.  From 

> these minutes, there are the following 6 conclusions on the protocol 

> requirements that Jeff stated:

> Jeff and I appreciate Ken Watsen’s comments on the list, but we have 

> had lots of suggestions regarding

> an overlay proposal – but no full proposal.  At this time, the WG will 

> only consider full proposals and not

> secondary identity, and priority.  Data models will determine what is 

> the “node” unit.  For example, the I2RS RIB node unit is the route.

> difficult time determine when the notification happened in the stream 

> – so the I2RS client must ask the agent again.

> Agent does not do anything with the meta-data. The client has to do 

> one edit per secondary at a time.

> agent associated with a data model node that is being created or 

> updated

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 15:52:15 -0400

Juergen: 

I understand your technical point on being concerned about 

"solutions that require (i) separate data models for ephemeral state and
(ii) data model specific merge logic. While this may work for I2RS, this
approach does not scale or has a very high cost of scaling to other
ephemeral state editing needs."

If you have full  overlay model proposal, we would be glad to receive it.
However, no one else has proposed a full overlay model. 

Other answers are below.

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Joel M. Halpern'; [email-masked];
'Alia Atlas'

On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote:
> proposal.  At this time, the WG will only consider full proposals and 
> not suggestions toward a proposal.

For the record: I am highly concerned about solutions that require (i)
separate data models for ephemeral state and (ii) data model specific merge
logic. While this may work for I2RS, this approach does not scale or has a
very high cost of scaling to other ephemeral state editing needs.
 
> the "node" unit.  For example, the I2RS RIB node unit is the route.

I am concerned about adding protocol mechanisms that are specific to a
certain data model. It is unclear what a "node" unit it, terms like 'highly
reliable notifications' and 'high bandwidth, asynchronous interface, with
real-time guarantees' are somewhat unclear - how do we determine we have met
any of these requirements?

> level (5/27 meeting) or group level (list discussion).  

Why does this mapping of username to priority have to be maintained in NACM?

> - so the I2RS client must ask the agent again.
> 

Except c), I do not understand this. What are these 'guarantees' 3) is
about?

[Sue]: The large database pulls of a I2RS RIB (1 million routes) may receive
a change notification for one of the routes while the rest of the stream is
in progress. If the change notification does not include the data, the  I2RS
client must poll the I2RS agent to determine if the route change
notification occurred before or after that route's data was sent. 
Change notifications are reliable, but not perfectly reliable.  Logging is
different than change notifications as logging for tracing includes all
change data reliably. 

> updated  (write-access) in the data store.  

Ehem, what is read-only data that is created or written? Did you want to say
that the identity meta-data is immutable once a data node has been created?
And if so, has priority the same property: Is priority of a data node is
determined at creation time and then immutable?

[sue]: Secondary identity data is read-only meta-data that is only changed
when created or written. It is immutable unless the whole node is changed.
Priority is linked to I2RS client.  Priority remains unchanged with the
identity of the client.  Priority of an entry (route1 from client-1,
priority2) remains immutable with the writing of this entry from this
client.  If a new client (route-1 from client-2, pririty3), then the node
and the meta-data changes. 

> The values of identities are originally set by operators.   
I am not sure how agent identity authentication via AAA works. Can someone
point me to the right direction if I assume a secure transport such as SSH
or TLS?

The identities used in SSH are passed via AAA (diameter or radius).  The
identities are not standardized but sent in AAA (diameter or radius)
messages based on operator assignment. 
 
/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Jun 2015 14:35:33 +0200

> However, no one else has proposed a full overlay model.

Frankly, there is no full alternate proposal either. The overlay model
has been discussed at quite some detail at a NETMOD interim. I am
happy to point at the meeting minutes. The question perhaps really is
whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF
looks at solutions or whether (b) I2RS casts a solution into stone to
be run through the NETCONF working group or whether (c) creates a
solution on its own independently of any other NETMOD/NETCONF
requirements.

> any of these requirements?

Apparently no answer here...

> Why does this mapping of username to priority have to be maintained in NACM?

Apparently no answer here...

> different than change notifications as logging for tracing includes all

I am still confused what the requirement here is.

> identity of the client.

You can't ever change the priority of a client? I doubt this is
practical.

> Priority of an entry (route1 from client-1, priority2) remains
> immutable with the writing of this entry from this client.  If a new
> client (route-1 from client-2, pririty3), then the node and the
> meta-data changes.

So I understand the priority is determined at write time but then
sticking until the next write. Or in other words, to change the
priority I have to write the data again using a client with a
different priority (or using the same client in case priority of a
client turns out to be configurable).

> messages based on operator assignment.

I know how I can pass the client identity via AAA using SSH, I like to
see an explanation how that is supposed to work for server identities
(and which operational problem that solves).

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 05 Jun 2015 08:39:04 -0400

I would describe it somewhat differently from any of the choices you list.

A) I2RS has some a set of architectural requirements.  These were not as 
cleanly described as one might like but they were very clearly accepted 
by the working group and understood to be needed for the protocol choice.
B) The working group has decided that it will use NetConf/RestConf if 
that can meet the requirements.

The corrolary is that if neither NetConf nor RestConf can meet the 
requirements, then the working group will, in my opinion, have to do 
something else.

Yours,
Joel

---

From: "Russ White" <[email-masked]>
Date: Fri, 5 Jun 2015 08:54:49 -0400

> cleanly described as one might like but they were very clearly accepted by
> the working group and understood to be needed for the protocol choice.
> B) The working group has decided that it will use NetConf/RestConf if that
> can meet the requirements.
> 

Agreed.

Russ

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Jun 2015 09:38:05 -0700

> can meet the requirements.

I would say the arch is a mixture of architecture and functional requirements.
Almost as if the authors had a design in mind and reverse-engineered the
requirements from the design.

As Juergen pointed out, the requirement to assign a priority
to a client does not require NACM.  NACM is a design choice
for that requirement.

I have some concerns about the tight notification control loop
that is proposed.  IMO, this is going to be too slow and too
complicated.  It seems to me that the only company that has
implemented something close to I2RS is using a design
that does not rely on a near real-time reliable notification loop.

I don't have a strong preference for ephemeral datastore
vs. tagging non-config data.  The current NETCONF datastores
only apply to config=true objects.  YANG design allows for
the config=false data to be further partitioned, but this is
not required for I2RS to work.

> requirements, then the working group will, in my opinion, have to do

That would be OK too, if you want to completely
decouple I2RS from configuration.   This simplifies some
things if was invisible to NETCONF/RESTCONF and YANG.

Andy

>>> merge
>>>> b.      High bandwidth, asynchronous interface, with real-time
>>>> guarantees
>>>
>>> on
>>>>
>>>> getting data,
>>>>
>>> 'highly
>>>> 3)      Joel suggests that large data write may be best done in netconf
>>>
>>> with
>>>>
>>>> guarantees
>>>>
>>>> 5)      Secondary identity data is read-only meta-data that is stored in
>>>
>>> the
>>>>
>>> someone

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 14:46:53 -0400

Juergen:

<chair hat on> 
The agreement with the NETCONF WG chairs was to bring requirements to
NETCONF.  The I2RS  is working to bring a full-set of requirements for I2RS
protocol based on 

draft-ietf-i2rs-traceability-03 (WG LC) 
draft-haas-i2rs-ephemeral-state-reqs-00 (WG Adoption)
draft-ietf-i2rs-pub-sub-requirements-02 (WG LC) 
and mutual-authentication/transport text from
draft-haas-i2rs-netmod-netconf-requirements-01 (draft forthcoming).   

This work is based on technology proposed by authors of traceability,
pub-sub, and Jeff's co-workers on ephemeral state (Juniper).   While
draft-haas-i2rs-ephemeral-state-req-00 is not 100% complete, it has gotten a
lot of discussion and has the form of a proposal.  

I2RS is taking choice (a) below  - to state its requirements to the
NETCONF/NETMOD group and to evaluate the solutions they propose.   Based on
feedback from members of the NETCONF WG, the I2RS WG is trying to a best
effort in specifying its requirements including the I2RS ideas of solutions
so that we may transmit as much information to NETCONF/NETMOD as possible.
We are not adopting choice b or c at this time.  Choice (a) does not
constrain I2RS to accept the solution NETCONF/NETMOD proposes, but says the
I2RS will review the resulting technology from NETCONF/NETMOD based on the
I2RS requirements.  

If you feel the overlay model discussed at the NETMOD interim is a viable
candidate, I suggest you write a draft outlining the details for I2RS WG.
If you publish draft, I will put you on the agenda on 6/10/2015 for the WG
to consider before we close on the ephemeral state.  As you know from being
a WG chair, the floor is open now for the overlay alternative but the
adoption call of Jeff's draft (draft-haas-i2rs-ephemeral-state-reqs-00)
signals a direction that the WG will take. 
<chair hat off> 

It would please me personally if you had time to published a draft with
details for the overlay model published in a draft prior to 6/9/2015 so we
can consider overlay model concepts.   Perhaps you can chat with Kent Watsen
about creating the draft together.  
 
Sue Hares 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, June 05, 2015 8:36 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Joel M. Halpern'; [email-masked];
'Alia Atlas'

On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote:
> (ii) data model specific merge logic. While this may work for I2RS, 
> this approach does not scale or has a very high cost of scaling to 
> other ephemeral state editing needs."
> 

Frankly, there is no full alternate proposal either. The overlay model has
been discussed at quite some detail at a NETMOD interim. I am happy to point
at the meeting minutes. The question perhaps really is whether (a) I2RS has
requirements to be addresses and NETMOD/NETCONF looks at solutions or
whether (b) I2RS casts a solution into stone to be run through the NETCONF
working group or whether (c) creates a solution on its own independently of
any other NETMOD/NETCONF requirements.

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> Cc: [email-masked]; [email-masked]; 'Joel M. Halpern'; 
> [email-masked]; 'Alia Atlas'
> > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-int
> > er
> > im-201
> > 5-i2rs-8
> > 
> >  
> > 
> scale or has a very high cost of scaling to other ephemeral state editing
needs.
guarantees
> > secondary identity, and priority.  Data models will determine what 
> > is the "node" unit.  For example, the I2RS RIB node unit is the route.
> 

NACM?

> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may 
> receive a change notification for one of the routes while the rest of 
> the stream is in progress. If the change notification does not include 
> the data, the  I2RS client must poll the I2RS agent to determine if 
> the route change notification occurred before or after that route's data
was sent.
> Change notifications are reliable, but not perfectly reliable.  
> Logging is different than change notifications as logging for tracing 
> includes all change data reliably.

> to say that the identity meta-data is immutable once a data node has been
created?
> And if so, has priority the same property: Is priority of a data node 
> is determined at creation time and then immutable?
> 
> [sue]: Secondary identity data is read-only meta-data that is only 
> changed when created or written. It is immutable unless the whole node is
changed.
> Priority is linked to I2RS client.  Priority remains unchanged with 
> the identity of the client.

You can't ever change the priority of a client? I doubt this is practical.

> client (route-1 from client-2, pririty3), then the node and the 

So I understand the priority is determined at write time but then sticking
until the next write. Or in other words, to change the priority I have to
write the data again using a client with a different priority (or using the
same client in case priority of a client turns out to be configurable).

> The identities used in SSH are passed via AAA (diameter or radius).  
> The identities are not standardized but sent in AAA (diameter or 
> radius) messages based on operator assignment.

I know how I can pass the client identity via AAA using SSH, I like to see
an explanation how that is supposed to work for server identities (and which
operational problem that solves).

/js

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:43:42 -0400

Andy and Joel: 

As my chair note stated, the chairs know they are providing extra details with the requirements.  However, in the past the feedback from various NETMOD/NETCONF participants has been not enough detail.  The use of NACM to control input to a I2RS agent and assign priority to a client - is one of those extra info.  I believe the tight notification guarantees to support a I2RS control loop is a requirement rather than extra suggestions. 

Hopefully, that the NETMOD/NETCONF chairs will review through the initial ephemeral state document and describe what they feel is requirements versus added suggestions.   The I2RS chairs will clean-up that requirements document next week. 

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, June 05, 2015 12:38 PM
To: Joel M. Halpern
Cc: Susan Hares; [email-masked]; Jeffrey Haas; [email-masked]; Alia Atlas
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern <[email-masked]> wrote:
> A) I2RS has some a set of architectural requirements.  These were not 
> as cleanly described as one might like but they were very clearly 
> accepted by the working group and understood to be needed for the protocol choice.

I would say the arch is a mixture of architecture and functional requirements.
Almost as if the authors had a design in mind and reverse-engineered the requirements from the design.

As Juergen pointed out, the requirement to assign a priority to a client does not require NACM.  NACM is a design choice for that requirement.

I have some concerns about the tight notification control loop that is proposed.  IMO, this is going to be too slow and too complicated.  It seems to me that the only company that has implemented something close to I2RS is using a design that does not rely on a near real-time reliable notification loop.

I don't have a strong preference for ephemeral datastore vs. tagging non-config data.  The current NETCONF datastores only apply to config=true objects.  YANG design allows for the config=false data to be further partitioned, but this is not required for I2RS to work.

Andy

>> Frankly, there is no full alternate proposal either. The overlay 
>> model has been discussed at quite some detail at a NETMOD interim. I 
>> am happy to point at the meeting minutes. The question perhaps really 
>> is whether (a) I2RS has requirements to be addresses and 
>> NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a 
>> solution into stone to be run through the NETCONF working group or 
>> whether (c) creates a solution on its own independently of any other 
>> NETMOD/NETCONF requirements.
>>
>>> Other answers are below.
>>>
>>> Sue
>>>
>>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in
>>>> ter
>>>> im-201
>>>> 5-i2rs-8
>>>>
>>>>
>>>>
>>>> these minutes, there are the following 6 conclusions on the 
>>>> protocol requirements that Jeff stated:
>>>>
>>>>
>>>>
>>>> Jeff and I appreciate Ken Watsen's comments on the list, but we 
>>>> have had lots of suggestions regarding an overlay proposal - but no 
>>>> full proposal.  At this time, the WG will only consider full 
>>>> proposals and not suggestions toward a proposal.
>>>
>>>
>>> For the record: I am highly concerned about solutions that require 
>>> (i) separate data models for ephemeral state and (ii) data model 
>>> specific merge logic. While this may work for I2RS, this approach 
>>> does not scale or has a very high cost of scaling to other ephemeral 
>>> state editing needs.
>>>
>>> I am concerned about adding protocol mechanisms that are specific to 
>>> a certain data model. It is unclear what a "node" unit it, terms 
>>> like 'highly reliable notifications' and 'high bandwidth, 
>>> asynchronous interface, with real-time guarantees' are somewhat 
>>> unclear - how do we determine we have met any of these requirements?
>>
>>
>>> receive a change notification for one of the routes while the rest 
>>> of the stream is in progress. If the change notification does not 
>>> include the data, the I2RS client must poll the I2RS agent to 
>>> determine if the route change notification occurred before or after 
>>> that route's data was sent.
>>> Logging is different than change notifications as logging for 
>>> tracing includes all change data reliably.
>>
>>
>>> Ehem, what is read-only data that is created or written? Did you 
>>> want to say that the identity meta-data is immutable once a data 
>>> node has been created?
>>> And if so, has priority the same property: Is priority of a data 
>>> node is determined at creation time and then immutable?
>>>
>>> changed when created or written. It is immutable unless the whole 
>>> node is changed.
>>> someone point me to the right direction if I assume a secure 
>>> transport such as SSH or TLS?
>>>
>> I know how I can pass the client identity via AAA using SSH, I like 
>> to see an explanation how that is supposed to work for server 
>> identities (and which operational problem that solves).
>>
>> /js
>>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Jun 2015 19:28:16 -0700

Hi,

IMO NETCONF notifications are probably not the best choice for
the high-performance low-latency signalling that I2RS wants
between agent and client.  There is a lot of overhead in
the filtering, replay, YANG schema processing, XML encoding, etc.

Binary notifications that contain hard-wired standard messages
specially written to implement the I2RS protocol would be much faster
and less expensive to implement.  If this is to be as fast as a signalling
protocol then it would be wise to consider protocol performance issues.

Andy

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 7 Jun 2015 20:38:33 +0000

Andy;
You are making an excellent point. I totally agree. I also wonder if the same logic applies ( and I'd say much more so) for the opposite direction - when pushing routes real time from I2RS Client to Agent.
If Yes, isn't this is what FORCES folks (Jamal especially) have been saying all along?
NETCONF/RESTCONF are great for a lot of stuff, but maybe not so much for I2RS?
What's the point of "raping" NETCONF if:
a) it was never designed for architectures like I2RS;
b) it's properties do not square (at least easily enough) with I2RS requirements,
c) no other NETCONF based applications are going to benefit from the proposed by I2RS modifications.

Cheers,
Igor

________________________________________
From: i2rs [[email-masked]] on behalf of Andy Bierman [[email-masked]]
Sent: Friday, June 5, 2015 10:28 PM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; Joel M. Halpern; [email-masked]; Alia Atlas
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

Hi,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Jun 2015 15:46:45 -0700

> c) no other NETCONF based applications are going to benefit from the proposed by I2RS modifications.

I don't think it applies in the other direction.
The issue is that notification delivery is not instantaneous after
an edit occurs.   Edits initiated from the client are not
affected by a loosely coupled notification delivery system.

Also, edits from the client can contain data model fragments
that need to be validated and need to pass access control.
There is no extra processing done on the input.
All this processing is needed.

But if the agent needs to tell a client that path "/foo/bar"
has been deleted by a higher priority edit, none of the
extra processing required for RESTCONF notifications
is useful.  It is all overhead.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Jun 2015 20:34:44 -0400

Juergen,

> solution on its own independently of any other NETMOD/NETCONF

During that interim, we did discuss a number of details regarding overlays.
We also discussed a number of issues that overlays have when ephemeral state
was not disjoint from static configuration state.  

As a result of that discussion and further presentation at a later I2RS
meeting regarding the Venn diagram interactions of static and ephemeral
configuration state, my latest draft attempts to codify behaviors that
shouldn't be problematic in either proposed form or in overlay.

The point of frustration for all parties seems to be that while the
paragraph from you above seems to indicate that there is some understanding
of the requirements, I am unable to provide text that illustrates either
requirement or potential solution to the matter.  All parties are spending
their resources saying "I think I understand this point, but this is wrong."
If the points are understood well enough to disagree with potential
solutions, I would suggest that they may be clear enough for both protocol
and data modeling experts to contribute text that either clarifies the
requirements to the collective experts' needs or similarly a proposal
documenting a solution.

These fundamental failures suggest a few possibilities:
1. There is a complete failure to properly communicate.  If so, we should
   find replacement parties to carry on the work.  We had some declared
   interest in a design team.  Sue has, I believe, contacted people about it.
   Those individuals should take over the work.
2. Netconf/restconf/yang are inappropriate tools and we have wasted the
   Working Group's time.  I don't believe this as my employer has 
   ephemeral datastores in an upcoming release.  It does not, however, have
   full I2RS properties such as priority or secondary-id.
3. The relevant experts are trying to get I2RS ephemeral state work to die.
   If so, let's have the relevant discussion either publicly or privately so
   we can stop wasting people's IETF cycles.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 14:44:36 +0200

>    we can stop wasting people's IETF cycles.

I can assure you that, at least from my side, 3. is not the case.

My perspective is likely slightly different from yours since I (not
surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS
itself: If we add writable ephemeral state to NETCONF/RESTCONF (and
perhaps YANG), I believe we will have to envision more usages of that
feature than just I2RS. Looking at things from a wider and longer term
perspective, I am concerned about (i) duplicated data modeling work
and I am concerned about (ii) use-case specific merge logic that needs
to be supported. From this perspective, the overlay model has been
prety attractive because it comes with a single merge logic and it
minimizes (or even eliminates) duplicated data modeling work.

/js

PS: Out of curiosity: Can you disclose what your employer's ephemeral
    datastore solution coming out as a product soon looks like? Is it
    closer to an overlay approach or is it closer to what you
    described in your I-D?

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 10 Jun 2015 10:52:51 -0400

Juergen:

<chair hat on> 
The I2RS WG still needs a written draft proposing how this would work to
have an effective discussion. 
<chair hat off> 

If it has these benefits you mention, it would be good to write itup. 

Best wishes, 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2015 8:45 AM
To: Jeffrey Haas
Cc: Susan Hares; [email-masked]; 'Joel M. Halpern'; [email-masked];
'Alia Atlas'

On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote:
> > am happy to point at the meeting minutes. The question perhaps 
> > really is whether (a) I2RS has requirements to be addresses and 
> We also discussed a number of issues that overlays have when ephemeral 
> state was not disjoint from static configuration state.
> 
> As a result of that discussion and further presentation at a later 
> I2RS meeting regarding the Venn diagram interactions of static and 
> ephemeral configuration state, my latest draft attempts to codify 
> behaviors that shouldn't be problematic in either proposed form or in
overlay.
> paragraph from you above seems to indicate that there is some 
> understanding of the requirements, I am unable to provide text that 
> illustrates either requirement or potential solution to the matter.  
> All parties are spending their resources saying "I think I understand this
point, but this is wrong."
> solutions, I would suggest that they may be clear enough for both 
> protocol and data modeling experts to contribute text that either 
> clarifies the requirements to the collective experts' needs or 
> similarly a proposal documenting a solution.
> 

My perspective is likely slightly different from yours since I (not
surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS
itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps
YANG), I believe we will have to envision more usages of that feature than
just I2RS. Looking at things from a wider and longer term perspective, I am
concerned about (i) duplicated data modeling work and I am concerned about
(ii) use-case specific merge logic that needs to be supported. From this
perspective, the overlay model has been prety attractive because it comes
with a single merge logic and it minimizes (or even eliminates) duplicated
data modeling work.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Jun 2015 11:43:38 -0400

Juergen:

Mahesh Jethanandari indicated that he wanted to make sure the comment after
2c below has been responded to the following comment:

>"I am concerned about adding protocol mechanisms that are specific to a
certain data model.

> It is unclear what a "node" unit it, terms like 'highly reliable
notifications' and 'high bandwidth,

> asynchronous interface, with real-time guarantees' are somewhat unclear -
how do we 

> determine we have met any of these requirements?" 

I want to thank you and Mahesh for making sure this question gets asked. 

You are correct that I2RS is data-model focused, and the unit of
notification is data dependent. Below my best estimate of the units with
times, notifications,  normal groups of the units with times.  See
Definitions for the info, I2RS Model info, Notifications and read/write
groupings. 

Would it be helpful to have this information on a wiki-page for now?  I will
query each model author to provide their input to the wiki page, and start a
discussion on the mail list. 

I think it is useful to put these requirements in their drafts.  What do you
think? 

Sue Hares

===================================

Definitions

A few repetitions of the definitions may help from the architecture document
and interims may help: 

Highly reliable notifications: are notifications which provide notifications
which align with the current status.  In the I2RS interim notes, we noted
notifications are not logging which is covered by the traceability draft.
Notifications are status changes and each model provides the status changes.
If the changes come too quickly (E.g. route changes), then the change will
give the latest status. Highly reliable notifications are guaranteed to
arrive normally, but buffer overrun or system issue may cause a few to be
lost.  Perfectly reliable notifications are possible in high-available
systems which duplicate streams of data.  The I2RS WG is not asking for
perfectly reliable data streams.  

High-bandwidth:  It is assumed that the pull of a full RIB, full topology
model (all topologies), and a full FB-FIB is possible.  However, the normal
mode is a query of a portion of these models.  As discussed in the 5/27/2015
interim, a full pull may find that portions of the RIB change during the
pull.  Joel Halpern suggest NETCONF may be a better mechanism for the full
dump.  However, the portions of the models - must be reported quickly so
that programmatic changes can be made.

Asynchronous: means that multiple streams of data from different transport
sessions can query/write different portions of any of the I2RS models in
parallel - AND these read/write portions of the model can  operates in
parallel along with pub/sub, traceability.   Writes operate in parallel
operating on portions of the model.  Exact definition of locking of the
portion of a model for a write has been discussed, but this should be
discussed per module.  

Real-time guarantees:  Real time guarantees means that the processing and
response must be listed under a certain time per module.  The module can
give general ranges, but the specific definition is left to the
implementation.   I will start a mail thread on these guarantees per module.
My understanding is that we are looking for seconds or sub-second in routes,
portions of topology, and in the filter rule.  

I2RS Module information 

 ===============================

This node will provide you the unit of focus for the protocol independent
modules (I2RS RIB, I2RS topology, and I2RS Filter-Based RIB Model).    The
I2RS RIB and I2RS Topology have yang modules, and the I2RS Filter-Based RIB
Model has an Information al model so we can provide the unit of focus.
(Hopefully, the I2RS Filter-based RIB Model will have the yang model read by
6/24) 

Protocol independent models (info/yang) were developed for BGP, OSPF, ISIS,
MPLS and SFC. These yang modules are being revised and could be reviewed at
the 6/24/2015 interim.  These drafts are in flux so I need to query the mail
list on the use cases, and the authors on their changes.  I can get more
detail by the end of next week so we can talk about it at the 6/24/2015
interim.  Some of the flux is the also base yang modules (as an example BGP)
that impacts derivatives (EVPN, L2VPN, L3VPN).   

I have reference the explanation sections in the I2RS drafts.  As a yang
doctor, I hope it is evident which yang language parallel to these sections.
(if not, please post suggestions for corrections so the authors can fix
these drafts). 

 Model       Unit                type                              reference
Frequency of reference            

=======    ========     ============            =========
===============================

I2RS RIB    Route              main   key unit           section 2.3    high
R/W   

                    Next-hop      dependent subunit    section 2.4   high to
medium R/W 

                      RIB                 grouping of routes     section 2.2
Initial start-up (mostly R/ some W)  

                      RIB list           grouping of RIBS         section
2.1    Initial start-up (mostly R/ some W)  

The topology nodes are out for the non-TE version.  TE version will not
arrive until IETF time-frame. 

I2RS Topology        Unit             Type           Reference
Frequency of Reference 

==============  ========  =======       ===========
===========================

Generic Topology  Node          main unit    section 3.1           R/W or W
from agent data  

                                  Link                main unit      section
3.2           R/W or W from agent data 

                                     Network    main unit    section 3.1/3.2
R/W or W from Agent 

Full pull query  

                                  Termination sub-unit   section 3.1 

                                    - point   

L2 Topology            same as generic              section 2 - see note on
TE additions      

L3 Topology           same as generic              section 3.2 for IGP - see
note on TE Additions 

Section 3.3 for OSPF

L1 Topology            same as generic                See note: draft being
overhauled to align 

to TEAS link & TE models     

Service Topology  same as generic               See note:  draft being
overhauled to link to

L3SM style of service topologies 

Module:        Unit              Type                       Section
Frequency 

========      ======         ======                 ====================
==========

FB-RIB          policy-rule       main unit              section 4.2 info
module    R/W main unit  

                      FB-RIB_          Ordered list of     see section
4.1-4.3           R/W policy rule inserted

       ordered-list          filters
into ordered list 

       interface-list    ordered list       see section 4.2-4.3
Initial start-up /config  

                                 of interface
+ interface status 

                                     references

       FB-RIB               RIB group             see section 4.1 to 4.2
Groups policy-rule +  

Interfaces 

Note on Topology modules 

.         All topology will be augment by TE modules with structure in
draft-ietf-teas-yang-te-topo-00  as updated by
https://github.com/ietf-mpls-yang/te.

.         L1 topology draft - will be overhauled based on decision on
ephemeral state (just completed), and the TE drafts which have topology.  It
may take portions of other TEAS drafts (
<https://datatracker.ietf.org/doc/draft-saad-teas-yang-te/>
draft-saad-teas-yang-te-01) 

.         Service module needs to provide link to work from service.  Only
one service model is being designed:  

o   L3SM - protocol independent service module for L3 services
(https://datatracker.ietf.org/doc/draft-l3vpn-service-yang/

o   L2SM - is not yet started.

o   Service forwarding topologies - initial draft done  

Notifications                 Status
Timing      

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

I2RS RIB                             nexthop-resolution-status-change
second or less

                                            Route-change
second or less

L3 Topology                        igp-node-event
second or less

                                          igp-link-event

                                           igp-prefix-event 

                                                igp-termination-point-event 

L2 Topology                        TBD - but likely the same)
second or less

                                                (l2-node-event,
l2-link-event, l2-prefix-event, 

                                             L2-termination-point-event) 

L1 Topology                        TBD- but likely the same
second or less

Service Topology              Unknown - too much in flux 

FB-RIB                                   FB-RIB interface loss
second or less 

                                                Policy-Rule interface loss
second or less

                                                Policy-Rule
second+

Query/Write 

Groupings                  Normal           High
Normal Time      High BW time    

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

I2RS RIB: Routes      1-10Ks              100K to 1Million        < 1 second
1-5 second   

I2RS RIB: RIBs          1-20 RIBs          100-300 RIB                 TBD
TBD                        

                                  (10K-100K RT)   (10K-100k)

Topology                   1-5K node        not really sure
TBD                        TBD   

                                    300-10K links

                                       1K - 50K topology

FB RIB                           1-10K rules        not really sure
<1 second          TBD   

*tp = termination point  

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Joel M. Halpern'; [email-masked];
'Alia Atlas'

<http://www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-int
er> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter

with

the

/js

-- 

Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Jun 2015 16:31:00 -0700

Hi,

I think I understand Juergen's concerns about I2RS requirements.
Some of them are not specified as functionality, but rather as solutions.

Most notably, the NETCONF WG needs to decide the best way to
integrate ephemeral configuration into the existing framework.
That may end up being a query-tag or a datastore or something new, but that
is
a standards implementation detail, not a requirement.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Jun 2015 20:03:59 -0400

There are at least two dimensions to your comment.

One aspect is that I2RS should not, and has tried not to, prescribe the 
implementation mechanism to meet the requirements.  The requirement is 
ephemeral config, with a descriptive definition and identity and 
priority aspects.  The mechanism to meet that is up to whatever protocol 
is to be used.

The other aspect that strikes me is that the NetConf WG is perfectly 
free to conclude that they think that what is needed is a mechanism that 
does not fully meet the I2RS requirements.  If so, the I2RS group will 
have to decide between changing its requirements and picking another 
protocol.

As long as those points are understood by each side, we are fine.

Yours,
Joel

On 6/16/15 7:31 PM, Andy Bierman wrote:
> That may end up being a query-tag or a datastore or something new, but
> that is
> On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Juergen:
>
>     <chair hat on>
>     [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     Cc: Susan Hares; [email-masked] <mailto:[email-masked]>; 'Joel M.
>     Halpern'; [email-masked] <mailto:[email-masked]>;
>     'Alia Atlas'
>      >    interest in a design team.  Sue has, I believe, contacted
>     people about
>     it.
>      >    ephemeral datastores in an upcoming release.  It does not,
>     however,
>     have
>      > 3. The relevant experts are trying to get I2RS ephemeral state
>     work to
>     die.
>      >    If so, let's have the relevant discussion either publicly or
>     privately
>     so
>     perhaps
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Jun 2015 17:29:57 -0700

On Tue, Jun 16, 2015 at 5:03 PM, Joel M. Halpern <[email-masked]>
wrote:

> ephemeral config, with a descriptive definition and identity and priority
> aspects.  The mechanism to meet that is up to whatever protocol is to be
> used.
>
>
The impact on the existing documents needs to be examined by the WG.
This is where datastore vs. tag details could be quite different.

The other aspect that strikes me is that the NetConf WG is perfectly free
> to conclude that they think that what is needed is a mechanism that does
> not fully meet the I2RS requirements.  If so, the I2RS group will have to
> decide between changing its requirements and picking another protocol.
>

I don't know what the WG consensus will be, but IMO I2RS needs to
distinguish the parts that need signalling events from the
parts that need access to the YANG notifications.  These are not the same.
I know the implementation requirements for RFC 5277 fairly well and I
am recommending against its use for signalling events.
Other than that I see no issues supporting I2RS requirements.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Jun 2015 08:46:30 +0200

> have an effective discussion. 

My understanding is that I2RS formulates requirements and the solution
is done in NETCONF. If this is correct, then there is in principle no
point in sending solution drafts to I2RS.

Yes, I understand that requirements are often written with certain
solutions in mind and this is why requirement processes usually are
frustrating.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Jun 2015 11:08:57 -0400

While I would expect most of the detail work on a solution to be done in 
NetConf, it would be very unusual to treat the requirements as something 
thrown over the wall, with the ensuing work done only in NetConf.  If 
NetConf wants its work to be suitable to meet the I2RS requirements, 
then experience with many cross-WG activities tells us the proposal will 
need to also be reviewed and discussed with I2RS.

If NetConf wants to do what it judges is best, and merely hope that I2RS 
adopts it when it is done, then the NetConf WG is certainly free to do 
that.  But the odds of meeting the requirements are low, and the odds of 
I2RS waiting around on the assumption that the right magic will be 
thrown back over the wall is also low.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Jun 2015 09:27:28 -0700

Hi,

It is all too easy for IETF work to fall apart because of charter overlap.
It's way too easy to confuse process with progress.

Since the IETF is comprised of volunteers, it usually takes the involvement
of stake-holders all the way through to RFC publication to get work done.
My guess that unless I2RS people are involved and doing most of the work,
the NETCONF WG is not likely to make much progress or even get started.

Andy

On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern <[email-masked]>
wrote:

> NetConf wants its work to be suitable to meet the I2RS requirements, then
> experience with many cross-WG activities tells us the proposal will need to
> also be reviewed and discussed with I2RS.
>
> I2RS waiting around on the assumption that the right magic will be thrown
> back over the wall is also low.
>
> Yours,
> Joel
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Jun 2015 14:12:10 -0400

Juergen:

Is your email  a request for information regarding the I2RS process or a
concern regarding the process? If you wished additional information about
the process, as a chair - I am glad to repeat the process to make it clear.
Please see the restatement of the process below.   

The I2RS chairs chose to provide additional input on solutions to guide
NETCONF in understanding the I2RS requirements.   Based on earlier feedback
on too little details on our requirements, the I2RS chairs choose to provide
extra details.  If you are concerned about our providing extra detail, I
have noted your concern.  The chairs choose this direction knowing the
pros/cons.  We hope it will help NETCONF. 

If you wished to influence the I2RS requirements, you were invited to
provide a proposal that would influence the I2RS WG requirements.   Since
you did not, you are welcome to influence the NETCONF process in providing a
solution.  In the IETF, you have the freedom choose where you volunteer your
efforts. 

Best wishes for a wonderful day, 

Sue Hares 

=====================================================================

Process restated: 

At the end of IETF 92, the NETCONF chairs agreed with the I2RS chairs on the
following cycle of work to resolve the I2RS/NETCONF work on the I2RS re-use
of an NETCONF protocol 

a) I2RS would create a set of requirements for the I2RS protocol,

b) I2RS would send these requirements to the NETCONF, and

within a month of sending the requirements NETCONF would provide

a review of those requirements and an initial suggestion to those solutions 

c) After NETCONF  suggests a solution, I2RS will review it to see if it
accept it. 

There is no requirement for NETCONF solution to be selected as an I2RS
protocol. There is no requirement for the NETCONF solution to be the only
protocol I2RS selection to support the I2RS interface. 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, June 19, 2015 2:47 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'; [email-masked];
'Alia Atlas'

> The I2RS WG still needs a written draft proposing how this would work 

> to have an effective discussion.

My understanding is that I2RS formulates requirements and the solution is
done in NETCONF. If this is correct, then there is in principle no point in
sending solution drafts to I2RS.

Yes, I understand that requirements are often written with certain solutions
in mind and this is why requirement processes usually are frustrating.

/js

--

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Jun 2015 14:23:39 -0400

Andy: 

The NETCONF chairs promised an initial response within a month.  I hope NETCONF can at least provide a scope during that time period. 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, June 19, 2015 12:27 PM
To: Joel M. Halpern
Cc: Susan Hares; Jeffrey Haas; [email-masked]; [email-masked]; Alia Atlas
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

Hi,

 

Andy

 

On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern <[email-masked]> wrote:

While I would expect most of the detail work on a solution to be done in NetConf, it would be very unusual to treat the requirements as something thrown over the wall, with the ensuing work done only in NetConf.  If NetConf wants its work to be suitable to meet the I2RS requirements, then experience with many cross-WG activities tells us the proposal will need to also be reviewed and discussed with I2RS.

If NetConf wants to do what it judges is best, and merely hope that I2RS adopts it when it is done, then the NetConf WG is certainly free to do that.  But the odds of meeting the requirements are low, and the odds of I2RS waiting around on the assumption that the right magic will be thrown back over the wall is also low.

Yours,
Joel

Juergen:

<chair hat on>

/js