Subject: [i2rs] consensus on I2RS protocol and model

From: Edward Crabbe <[email-masked]>
Date: Fri, 11 Apr 2014 10:50:58 -0700

Dear I2RSers,

  At the last I2RS WG meeting there was a great deal of conversation
regarding selection of both modeling language and underlying transport
protocol.  Consensus at the time was to make use of Yang and (NetConf or
RestConf) (unclear).

  Before coming to a final consensus, we'd like to give people adequate
time to review source material, marshall arguments and discuss on the
mailing list.  To this end, we're asking that interested parties do just
this over the course of the next ~two weeks. Following that period, on
4/28, we'll be initiating a consensus call that will last an additional two
weeks, with the aim of converging modeling language / protocol by Friday,
5/9.

The consensus call should also generate proposals for any material changes
required to the underlying protocols.  These proposals in turn will form
the basis for a later draft including gap analysis and said changes.  Those
strongly in favor of one protocol over another should be prepared to
contribute to this analysis.

best,

  -ed

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 07:27:50 -0400

Ok, since nobody is saying anything i'll bite.
How would you like for this discussion to proceed?

> protocol.  Consensus at the time was to make use of Yang and (NetConf or

And i believe the view, as correctly presented by you, is for folks to go back
and make educated decisions by actually getting knowledgeable about
the different views presented. "Consensus" that you described above
to me looked like  a pageant popularity contest not based on anything
technical ("who likes contestant in the blue shirt? please cheer for them").

In my opinion i dont think the requirements are clear.

Will that get the crickets stop chirping?

cheers,
jamal

>   Before coming to a final consensus, we'd like to give people adequate time
> to review source material, marshall arguments and discuss on the mailing
> list.  To this end, we're asking that interested parties do just this over
> the course of the next ~two weeks. Following that period, on 4/28, we'll be
> initiating a consensus call that will last an additional two weeks, with the
> aim of converging modeling language / protocol by Friday, 5/9.
>
> required to the underlying protocols.  These proposals in turn will form the
> basis for a later draft including gap analysis and said changes.  Those
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 18 Apr 2014 13:17:32 +0000

Jamal,

Here are two criteria to be considered:
1. technical
2. commercial/business

We can discuss pros and cons for both, but have to state that from business perspective for Juniper going with RESTCONF/YANG make more sense. We already built the Junos model in YANG and 
have or are in process of building needed tools. Same goes for RESTCONF. We have NETCONF implemented in Junos and are working on RESTCONF implementation.
Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so this looks like a low hanging fruit from business perspective.

Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm not aware of it), don't see reason to switch from RESTCONF and YANG.
We can find out down the line that RESTCONF/YANG was the wrong way to go, but that can be always changed. From my perspective it looks right today.

Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 10:20:00 -0400

On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic <[email-masked]> wrote:
> We can discuss pros and cons for both, but have to state that from business perspective for
>Juniper going with RESTCONF/YANG make more sense. We already built the Junos model
> in YANG and have or are in process of building needed tools.
> Same goes for RESTCONF. We have NETCONF implemented in Junos and are working
> on RESTCONF implementation.
> Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so >this looks like a low hanging fruit from business perspective.
>

Thanks for being sincere Dean.
First, I will say I empathize with your view above (I understand such
a view is motivation
for many unfortunately often disguised as technical opinion). While i
empathize, I would like
to point that we need to have these discussions which are technical
otherwise there is
no point in having a standard.
In any case I get where you are coming from.

> Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm
>not aware of it), don't see reason to switch from RESTCONF and YANG.

Maybe we'll bring up the topics sequentially as the thread proceeds -
I'll start with
1 or 2 of what i think are requirements against protocol/model so we
dont have to
respond to long emails. If you have issues with ForCES please bring
them up as well
and we can discuss (I brought up a few in my presentation).

One of the issues was throughput and latency.
You stated in London that you want to be able to do a large amount of
updates/sec.
Other than you - I cant get anyone else to say this is a requirement.
I do believe it is.
It will be useful for example to come up with some hand waving numbers against
some agreed-to info model (eg the rib) and see how this requirement is
met by the
different protocols.

As for the model, I'd like to quote from the minutes what Tom Petch
(who i  consider to
be a sage in this space):
"If I was writing an info model I'd use YANG every time.  But if I was
writing a data
model I'd go for ForCES."
And this is rooted in the nature of Yang being intended for Config.

There is also the issue of i2rs ability to describe instances which is
lacking in Yang;
but maybe leave that out to a different email..

cheers,
jamal

> We can find out down the line that RESTCONF/YANG was the wrong way to go, but that
>can be always changed. From my perspective it looks right today.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 11:26:38 -0400

Sorry for the top post, but I wanted to inject that for the record, Brocade is in favor of using RestConf/Yang (or variations of those) for I2RS. We have no interest in using FORCES as the basis for this.

	--Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Apr 2014 10:31:31 -0500

Hi Dean,

I attended i2rs session in London on this issue.

My question is why ONF Management and Configuration protocol (OF-Config
1.2) was not on the table.

Regards,

Behcet

On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic <[email-masked]> wrote:

> We can discuss pros and cons for both, but have to state that from
> business perspective for Juniper going with RESTCONF/YANG make more sense.
> We already built the Junos model in YANG and
> have or are in process of building needed tools. Same goes for RESTCONF.
> We have NETCONF implemented in Junos and are working on RESTCONF
> implementation.
> Many carriers adopted or are adopting NETCONF/YANG, are looking into
> RESTCONF as well, so this looks like a low hanging fruit from business
> perspective.
>
> Looking at technical aspect, unless there is a very compelling reason (and
> there might be, but I'm not aware of it), don't see reason to switch from
> RESTCONF and YANG.
> We can find out down the line that RESTCONF/YANG was the wrong way to go,
> but that can be always changed. From my perspective it looks right today.
>
> time

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 11:42:08 -0400

Behcet: 

Can you tell me how the ONF Management and configuration protocol will interface with the routing system with all the requirements set forth by the architecture document?   Please refer to version 2.0 architecture

Or review to the presentation at IETF.   If you can present these features in email or any substantial way, we will listen.  In my observations, the ONF management protocol was designed for the ONF flows and not the information models required or the use case required.   

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: Dean Bogdanovic
Cc: [email-masked]; Edward Crabbe; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

Hi Dean,

My question is why ONF Management and Configuration protocol (OF-Config 1.2) was not on the table.

Regards,

Behcet 

Jamal,

Dean

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 11:47:12 -0400

I believe its because OF-Config does not meet the requirements we set forth. 

	--Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Apr 2014 10:57:15 -0500

On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <[email-masked]> wrote:

> Behcet:
>
>
>
> Can you tell me how the ONF Management and configuration protocol will
> interface with the routing system with all the requirements set forth by
> the architecture document?   Please refer to version 2.0 architecture
>
>
>

Don't get me wrong.

I am not speaking in favor of OF-Config.

But the point is that a more realistic choice should be between these two
choices.

If the study showed that OF-Config did not meet the requirements, that is
fine but I heard no one said that.
I wonder if the forces protocol meets these requirements?

Behcet

> Or review to the presentation at IETF.   If you can present these features
> in email or any substantial way, we will listen.  In my observations, the
> ONF management protocol was designed for the ONF flows and not the
> information models required or the use case required.
>
>
>
> Sue Hares
>
>
>
> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Behcet Sarikaya
> *Sent:* Friday, April 18, 2014 11:32 AM
> *To:* Dean Bogdanovic
> *Cc:* [email-masked]; Edward Crabbe; Jamal Hadi Salim
> *Subject:* Re: [i2rs] consensus on I2RS protocol and model
>
>
>
> Hi Dean,
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 12:02:50 -0400

I dont think a post like this is useful.
State your reasons please - just cheering on is not helpful.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 12:03:41 -0400

And what are those mysterious requirements it doesnt meet Thomas?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 12:41:07 -0400

On Fri, Apr 18, 2014 at 11:57 AM, Behcet Sarikaya
<[email-masked]> wrote:
>> interface with the routing system with all the requirements set forth by the
>> architecture document?   Please refer to version 2.0 architecture
>>
>>
>
>
> Don't get me wrong.
>

Why?

> I wonder if the forces protocol meets these requirements?

Only set of requirements i could find was what appears to be an abandoned
draft here:
http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00

Not sure i agree with some of the parts but it is what i used to present.

I havent seen anything on the model.

Overall requirements need to be considered.

You know what would be really useful is to show up at the next meeting with
implementations of I2RS - perhaps a few demos and discuss what the
lessons learnt are.

cheers,
jamal

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 18 Apr 2014 09:46:50 -0700

> 
> If the study showed that OF-Config did not meet the requirements, that is fine
> but I heard no one said that.
> 

On Feb 5th, Alia Atlas said:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html

> Gap Analysis for different Protocols:  I2RS needs to select a protocol to use.
I believe that we have volunteers for discussing RESTCONF.
> We'd welcome hearing from others who can provide at least a presentation for
review before IETF and preferably a quick draft as well.

On Feb 27th, Ed Crabbe said:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html
> The I2RS agenda has been posted.

Those who think OF-Config should have been a candidate, should have
presented at the IETF; or at least started a discussion on the mailing list.

My 2 cents
Nitin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Apr 2014 10:36:52 -0700

> State your reasons please - just cheering on is not helpful.
It is as useful as +1, which IMO is useful.

Availability of tools is important to developers who intend to implement
I2RS.

I think there are also some technical reasons to use YANG:

  - YANG is protocol and encoding independent. It can be mapped to a
protocol
    fairly easily.  It supports XML now. A standards effort to support JSON
encoding
    has been started in the NETMOD WG.  A proposal to support EXI exists,
and
    support for CBOR is possible.

 - YANG supports definition of protocol operations, data nodes, and
notification events.
   Data nodes are either configuration or non-configuration. XPath is used
to define
   validation rules such as 'must' and 'when'. There rules apply
differently to
   each context (operation, config data, non-config data, notification).

 - The local config is related to operational state, especially since
operational values may
   include configured values.  YANG is already being used for configuration.
   Using consistent data naming is important. A YANG instance-identifier is
an
   absolute-path (restricted XPath) expression.

 - YANG supports external and conditional augmentation of any data model.
   Each YANG module defines its own namespace.  A module namespace can
   be sub-divided with sub-modules.  All nodes are identified with QNames,
   using the YANG module or namespace as the extended name. This supports
   non-centralized naming authority (i.e., vendor A and vendor B can both
augment
   the same standard data node without any possibility of naming
collisions.)

 - YANG "features" allow optional functionality to be defined in a
data-model specific manner.
   Conformance advertisement information is standardized so clients know
what options
   are supported by each server implementation.

 - YANG "extensions" allow new language statements to be added to the
language,
   These external statements must be parsed by every YANG compiler, even if
   the compiler does not understand the extension.  This allows YANG to be
easily
   adapted for new applications, without the need to revise the language.

jamal

Andy

> >         Sorry for the top post, but I wanted to inject that for the
> record, Brocade is in favor of using RestConf/Yang (or variations of those)
> for I2RS. We have no interest in using FORCES as the basis for this.
> >
> >         --Tom
> >
> >
> business perspective for
> RESTCONF as well, so >this looks like a low hanging fruit from business
> perspective.
> >>>
> >>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 13:39:56 -0400

Why is that not useful? Because I didn't say I was in favor of forces? *) It IS useful to say that my company's products implement Yang/Netconf and will support RestConf, and therefore a derivative of those technologies used for i2rs is preferred. We have no plans to support any of the other discussed options in i2rs such as Forces at this time.  The reasons are simple: our customers asked for Netconf/Yang models and as far as I can tell, have no interest in Forces.  

	From my perspective, continuing to debate which protocol is derived to become i2rs is a waste of everyone's time. Its clear what people want from the meeting, and if you poll interested implementations you'll likely get the same answer: yang/netconf/restconf.  Lets please stop delaying i2rs and get some work done here.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 13:42:26 -0400

On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur <[email-masked]> wrote:

> 
>> 
>> If the study showed that OF-Config did not meet the requirements, that is fine but I heard no one said that.
>> 
> 
> 
> On Feb 5th, Alia Atlas said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html
> 
> > Gap Analysis for different Protocols:  I2RS needs to select a protocol to use.  I believe that we have volunteers for discussing RESTCONF. 
> > We'd welcome hearing from others who can provide at least a presentation for review before IETF and preferably a quick draft as well.
> 
> On Feb 27th, Ed Crabbe said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html
> Those who think OF-Config should have been a candidate, should have presented at the IETF; or at least started a discussion on the mailing list.
> 
> My 2 cents
> Nitin

	I agree %100 with your 2 cents.

	--Tom

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 14:06:07 -0400

> It is as useful as +1, which IMO is useful.

+1 is useful if it points to a technical point - not to "I like the
guy with the blue
shirt" without saying why.

Andy, hate to go over your list and respond to it because that puts you
on the defensive and the other thing is i am not sure what part of this
is "requirements" for I2RS and what is "excellent things Yang has".
Let me try but i worry i will be peppering over probably some of what
you may feel are strong statements that need to be emphasized.

> and support for CBOR is possible.
>

As a modelling language so is ForCES. The language is based on XML.
The ForCES protocol is tied to the model but the model is not tied to the
protocol.

>    validation rules such as 'must' and 'when'. There rules apply differently
> to

ForCES model does not support making protocol definitions. There are some basic
protocol definitions assumed (GET/SET/DEL etc).
Validation of constructs exists by virtue of the data model existing.

>    absolute-path (restricted XPath) expression.

I think this is the point Tom Petch brought up as being problematic.
When you have
config and operational info - very likely end up with two subtrees.

>    the same standard data node without any possibility of naming

ForCES is OO. The main building blocks are Classes known as LFBs.
Each class has a name and an ID.
While Classes define templates, Class instances are used when refering
to components.
Classes can be inherited to define new classes.

>    are supported by each server implementation.

ForCES LFB class has a capability section which is used to advertise features.

>    adapted for new applications, without the need to revise the language.

ForCES modeling does not have this feature.

So while i attempted to address the different points - I am not sure which
are requirements and which are not.

cheers,
jamal

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Apr 2014 18:18:43 +0000

Same here

Cheers,
Jeff

From: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 18, 2014 10:42 AM
To: b nitin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Crabbe Edward <[email-masked]<mailto:[email-masked]>>, Jamal Hadi Salim <[email-masked]<mailto:[email-masked]>>, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] consensus on I2RS protocol and model

On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur <[email-masked]<mailto:[email-masked]>> wrote:

My 2 cents
Nitin

--Tom

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 14:21:51 -0400

On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau <[email-masked]> wrote:
>
>         Why is that not useful? Because I didn't say I was in favor of forces? *)

Not at all. Your statement was more like a high five. It is ok to
raise your hand at
the meeting - but i was hoping the list would have more useful
technical discussion.

>It IS useful to say that my company's products implement Yang/Netconf and will support RestConf, >and therefore a derivative of those technologies used for i2rs is preferred. We have no plans to >support any of the other discussed options in i2rs such as Forces at this time.  The reasons are >simple: our customers asked for Netconf/Yang models and as far as I can tell, have no interest in >Forces.
>

So again it boils down to "bussiness" reasons - am i wrong?
"we have an implementation of Yang/netconf";
"we are going to make it work for I2RS".
If thats the case - then lets just end the discussion.
I am hoping to get the answer to:
What are the technical requirements/arguements?
Why do i have to struggle so much in a technical environment like IETF for
someone to come out and say what the requirements are?

I can assure you that i have no religious conviction that say it has
to be  ForCES.
Lets actually start with you showing me how netconf/yang meets the requirements.
Otherwise - please stop with the high fives.

>         From my perspective, continuing to debate which protocol is derived to become i2rs is a waste >of everyone's time.

Whats the point to having a circus show in pretending we are trying to
get any consensus?

>Its clear what people want from the meeting, and if you poll interested implementations you'll likely >get the same answer: yang/netconf/restconf.  Lets please stop delaying i2rs and get some work >done here.
>

When you go and ask people to raise their hands they will. You need to
ask them why
they are raising their hands. I am hoping this is not a staked
popularity contest.

cheers,
jamal

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 14:30:19 -0400

> So again it boils down to "bussiness" reasons - am i wrong?

	Yes, but not in the way you imply. My company has implemented Yang/Netconf because our customers have asked us to and because when we did, they bought our equipment - not as you imply, because we think its cool. There are a number of other major hardware vendors on this list that have done the same. I think if you poll most of those vendors, you will find that they generally don't  engineering resources to things that people don't buy.  Also, Open Daylight has gone with Netconf/Yang/RestConf as one of its primary interfaces - there are dozens of vendors working on that project too.  As far as I can tell, no one has done any programmable interface based on Forces there.  That seems to be an overwhelming number of implementations that have gone with yang/netconf/restconf. 

> Whats the point to having a circus show in pretending we are trying to

	I am not WG chair, so I will let Ed/Jeff comment on the circus. *)

> they are raising their hands. I am hoping this is not a staked

	Well, at some point it does come down to running code and real, deployed implementations, right?  As I said above, there are many real and significant implementations of yang/netconf in the marketplace *today*. Asking those things to be modified slightly isn't that big of a deal in order to address the requirements. Implementing a completely new protocol is. I am not totally against new protocols - its just that if we can achieve the goals we have by hacking an existing implementation, that makes better engineering and business sense. 

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Apr 2014 11:32:22 -0700

> shirt" without saying why.

I guess I knew that Brocade already uses YANG, and inferred that
what was Tom meant.

> you may feel are strong statements that need to be emphasized.
You stated that YANG only does config, which is incorrect.
It may be useful for people have not bothered to read either
YANG or ForCES RFCs to understand more about both.

But at a certain point it gets to be like debating programming languages.
Much of it is subjective, based on the preferences, tools, training, etc.,
of the people who will be writing the code.

Andy

> differently
> >> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <
> [email-masked]>
> >> wrote:
> >> >
> >> >>> Juniper going with RESTCONF/YANG make more sense. We already built
> the
> >> >>> Junos model
> >> >>> Looking at technical aspect, unless there is a very compelling
> reason
> >> >>> (and there might be, but I'm
> >> >> It will be useful for example to come up with some hand waving
> numbers
> >> >> against
> >> >>> We can find out down the line that RESTCONF/YANG was the wrong way
> to
> >> >>> go, but that

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Apr 2014 11:37:12 -0700

On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau <[email-masked]>wrote:

> >> It IS useful to say that my company's products implement Yang/Netconf
> and will support RestConf, >and therefore a derivative of those
> technologies used for i2rs is preferred. We have no plans to >support any
> of the other discussed options in i2rs such as Forces at this time.  The
> reasons are >simple: our customers asked for Netconf/Yang models and as far
> as I can tell, have no interest in >Forces.
> >>
> >
>         Yes, but not in the way you imply. My company has implemented
> Yang/Netconf because our customers have asked us to and because when we
> did, they bought our equipment - not as you imply, because we think its
> cool. There are a number of other major hardware vendors on this list that
> have done the same. I think if you poll most of those vendors, you will
> find that they generally don't  engineering resources to things that people
> don't buy.  Also, Open Daylight has gone with Netconf/Yang/RestConf as one
> of its primary interfaces - there are dozens of vendors working on that
> project too.  As far as I can tell, no one has done any programmable
> interface based on Forces there.  That seems to be an overwhelming number
> of implementations that have gone with yang/netconf/restconf.
>
>
It would be just as valid for people to chime in "We already use ForCES"
or "we use already OF-Config", as a reason to use it for I2RS.

Andy

> >>        From my perspective, continuing to debate which protocol is
> derived to become i2rs is a waste >of everyone's time.
> >
> > Its clear what people want from the meeting, and if you poll interested
> implementations you'll likely >get the same answer: yang/netconf/restconf.
>  Lets please stop delaying i2rs and get some work >done here.
> >>
> >
>         Well, at some point it does come down to running code and real,
> deployed implementations, right?  As I said above, there are many real and
> significant implementations of yang/netconf in the marketplace *today*.
> Asking those things to be modified slightly isn't that big of a deal in
> order to address the requirements. Implementing a completely new protocol
> is. I am not totally against new protocols - its just that if we can
> achieve the goals we have by hacking an existing implementation, that makes
> better engineering and business sense.
>
>         --Tom
>
>
>
> >
> >
> > cheers,
> > jamal
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 14:43:27 -0400

On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau <[email-masked]> wrote:
> 

	It would, and I think that is what the chairs are trying to assess so chime on in! 

	--Tom

---

From: Carl Moberg <[email-masked]>
Date: Fri, 18 Apr 2014 12:01:30 -0700

> 	It would, and I think that is what the chairs are trying to assess so chime on in! 

 While we (the ONF contributors) have explicitly tried to keep the OF-CONFIG specification language and protocol agnostic, but the only currently available implementation-ready language and transport mapping available is YANG and NETCONF. So in reality, OF-CONFIG is currently NETCONF with a YANG module maintained by the ONF.

--
Carl Moberg
VP Technology
twitter: @cmoberg
http://www.tail-f.com/

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 15:39:43 -0400

On Fri, Apr 18, 2014 at 2:30 PM, Thomas Nadeau <[email-masked]> wrote:
>         Yes, but not in the way you imply.
>My company has implemented Yang/Netconf because our customers have asked us to and because >when we did, they bought our equipment - not as you imply, because we think its cool.

So your customer came to you and said they need you to implement
I2RS using Yang/Netconf? It sounds to me like you had Yang/Netconf -
customer may
have asked for I2RS and in you suggested netconf/Yang.

>There are a number of other major hardware vendors on this list that have done the same. I think if >you poll most of those vendors, you will find that they generally don't  engineering resources to >things that people don't buy.

>Also, Open Daylight has gone with Netconf/Yang/RestConf as one of
>its primary interfaces - there are dozens of vendors working on that project too.

I think you are missing the point. What are the requirements? I will use
netconf/yang when it makes sense. But using it because you can, or some
project decided they want to use it is not an assertion that it meets
the requirements.

>  As far as I can tell, no one has done any programmable interface based on Forces there.

Seriously? I know you decided to leave ForCES out of your book but you are not
entitled to you facts. ForCES has been deployed and vetted. If you are
interested
and not being a troll we can talk.

>That
> seems to be an overwhelming number of implementations that have gone with
> yang/netconf/restconf.

So please explain how it meets the requirements for i2rs.

>  Well, at some point it does come down to running code and real, deployed implementations,
> right?

Sure - so you want to show up at the next IETF meeting with your
implementation of
I2RS and i will show up with me and we can discuss around running code?
For sure you havent deployed I2RS. So lets not talk about deployment.

>As I said above, there are many real and significant implementations of yang/netconf in the
> marketplace *today*. Asking those things to be modified slightly isn't that big of a deal in order to
> address the requirements. Implementing a completely new protocol is. I am not totally against new > protocols - its just that if we can achieve the goals we have by hacking an existing implementation,
> that makes better engineering and business sense.
>

I dont think we have much disagreements there. I am just not convinced
that netconf/yang
will require just a small surgery to deploy I2RS. Lets start with
requirements, shall we?
I may actually end up agreeing with you, who knows.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 15:48:45 -0400

> YANG or ForCES RFCs to understand more about both.

Ok, let me take that back. NETCONF/YANG is about config.

> of the people who will be writing the code.

Or we could have requirements well stated and things vetted against
requirements.

I think then there is a threshold where which approach requires a bigger
surgery. If both ForCES and Yang/netconf/restconf require equivalent
surgeries then by all means Yang/netconf/restconf is the better candidate.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 15:57:43 -0400

> or "we use already OF-Config", as a reason to use it for I2RS.

I will drop the idea of ForCES being the better candidate if there is
actually an analysis of requirements vs what is out there and ForCES turns
only to be slightly better.
I hear what you said earlier on subjectivity as being a factor. This is true.
And i do have my biases for ForCES - but I do hope this turns out to be a
reasonable technical discussion.

cheers,
jamal

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 18 Apr 2014 20:59:32 +0000

Cisco is also implementing Netconf - it¹s available on XR today, and it
will be available on other platforms as well.

For OpenDaylight, we chose Yang as the IDL to describe internal and
external APIs in the controller and so far it has served its purpose
really well. 

Also, as Tom pointed out, Netconf and Restconf have also been implemented
in ODL. I¹d like to stress that we not only have multiple Netconf/Restconf
implementations from multiple vendors (Brocade, Juniper, Cisco, just to
mention those on this thread), but have multiple open source
implementations as well. In addition to ODL, there is libnetconfd and a
few others.  ODL / libnetconfd interop testing is done in the ODL
regression test suite.  Now, since there are multiple independent open
source implementations, we¹ve got a good ecosystem for implementation of
new Netconf/Restconf/Yang features that may be required to meet i2rs¹s
needs (if the need to evolve the protocols/language arises).

In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as
the modeling language.

Thanks,
Jan

On 4/18/14, 6:17 AM, "Dean Bogdanovic" <[email-masked]> wrote:

>business perspective for Juniper going with RESTCONF/YANG make more
>sense. We already built the Junos model in YANG and
>Looking at technical aspect, unless there is a very compelling reason
>(and there might be, but I'm not aware of it), don't see reason to switch
>from RESTCONF and YANG.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 17:12:11 -0400

> external APIs in the controller and so far it has served its purpose

This has nothing  to do with meeting requirements for I2RS.

> regression test suite.

Again - I am not hearing requirements against I2RS.
Have you implemented I2RS with netconf/restconf/yang?

> Now, since there are multiple independent open

I dont think this sounds rational at all. HTTP has a bigger ecosystem than you.
Why not build around that and then refactor as needed?
Why is it so hard to get requirements around here?  What is the point
to a standard again?

cheers,
jamal

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Apr 2014 22:04:54 +0000

+1 for Netconf/YANG for the i2rs protocol and for YANG as
the modeling language.

Cheers,
Jeff

-----Original Message-----
From: "Jan Medved   (jmedved)" <[email-masked]>
Date: Friday, April 18, 2014 1:59 PM
To: Dean Bogdanovic <[email-masked]>, Jamal Hadi Salim
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Edward Crabbe <[email-masked]>
Subject: Re: [i2rs] consensus on I2RS protocol and model

---

From: Geoffrey Mattson <[email-masked]>
Date: Fri, 18 Apr 2014 22:11:01 +0000

+1 for Netconf for the I2RS protocol and YANG for the modeling language.

---

From: "Palani Chinnakannan (pals)" <[email-masked]>
Date: Fri, 18 Apr 2014 22:14:02 +0000

+1
We have been saying this for a quite sometime :-)

pals

On 4/18/14 3:11 PM, "Geoffrey Mattson" <[email-masked]> wrote:

>>>>>> protocol.  Consensus at the time was to make use of Yang and
>>>>>>(NetConf
>>>>>>or
>>>>>> RestConf) (unclear).
>>>>>> 
>>>>> 
>>>>> And i believe the view, as correctly presented by you, is for folks
>>>>>to
>>>>>go back
>>>>>> list.  To this end, we're asking that interested parties do just
>>>>>>this
>>>>>>over

---

From: David Meyer <[email-masked]>
Date: Fri, 18 Apr 2014 15:15:26 -0700

Likewise: +1 for Netconf/YANG for the i2rs protocol and for YANG as
the modeling language.

--dmm

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:10:16 -0400

Mr. Ed, our wonderful and delightful co-chair:  

This thread is address to the basic assumptions I've  of the Yang/Netconf
decision is based on, and not a yes or no on the draft.  However, your
insights will help me cast my vote as an engineer without emotional sway.  

My sources: 

I have been working under an assumption of I2rs informational models and
I2RS data models that I would like to confirm in this discussion.  My
assumption comes from discussion with Benoit Claise (OPS/NM area AD) whose
wisdom on NM guides the yang/netmod/netconf/ipfix world.   I have been
equally listening to Andy Beirman.  and Jamal Salim. I recommend buying
liquid libations to these fonts of wisdom. 

The assumption: 

I am assuming that the information models are not a waste of time. Jeff
Haas' comment was isn't having information models and data models a
duplication of effort.

First of all, RBNF and ABNF seem to be causing redundant issues in the
draft-ietf-i2rs-rib-info-model-02 draft. 

The ABNF the delightful work in
<http://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/>
draft-clarke-i2rs-traceability-01 really difficult to follow.  

My assumption had been the following train would occur:

UML graphic (readable) 

  ||

  VV  (someday via tool) 

UML text  (readable) 

  ||   (via tools - I've already found some) 

  ||

  VV

Yang/Forces Data Model (Yang readable/Forces:Readable)   

    || 

    || (tools to create) 

 XML  syntax (yang/forces) / binary syntax (forces)

  |  |

  |  | (tools to create)

  V V

Code inserted 

For validation of the code in the router

 Code 

  || (tools creates) 

  XML 

  ||  (tool creates) 

 Yang/Forces Data model 

  ||  (tool creates) 

UML syntax 

  ||  (tool creates) 

UML diagrams 

Why is this chain of events important to me?  Validation of Code and
structures.   Is this any different that the tool chains for
Yang/netmod/netconf or  Forces/binary/binary?  Nope.  That's why I hope we
can automate it.  The goal behind picking a data model is to provide
readability as we create these tool chains or to debug it. 

So.. font of wisdom from on high, can you let me know if I have
misunderstood the point for information models and data models. 

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Friday, April 11, 2014 1:51 PM
To: [email-masked]
Subject: [i2rs] consensus on I2RS protocol and model

Dear I2RSers,

best,

  -ed

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:27:56 -0400

Dean:

Could you let me know what tool chains you consider necessary for
RESTCONF/Yang? 

Do you start with informational models in the Yang/RESTCONF world?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Friday, April 18, 2014 9:18 AM
To: Jamal Hadi Salim
Cc: [email-masked]; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

Jamal,

We can discuss pros and cons for both, but have to state that from business
perspective for Juniper going with RESTCONF/YANG make more sense. We already
built the Junos model in YANG and have or are in process of building needed
tools. Same goes for RESTCONF. We have NETCONF implemented in Junos and are
working on RESTCONF implementation.
Many carriers adopted or are adopting NETCONF/YANG, are looking into
RESTCONF as well, so this looks like a low hanging fruit from business
perspective.

Dean

On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <[email-masked]> wrote:

>> regarding selection of both modeling language and underlying 
>> transport protocol.  Consensus at the time was to make use of Yang 
>> and (NetConf or
>> RestConf) (unclear).
>> 
> 
> And i believe the view, as correctly presented by you, is for folks to 
> go back and make educated decisions by actually getting knowledgeable 
> about the different views presented. "Consensus" that you described 
> above to me looked like  a pageant popularity contest not based on 
> anything technical ("who likes contestant in the blue shirt? please cheer
for them").
>>  Before coming to a final consensus, we'd like to give people 
>> adequate time to review source material, marshall arguments and 
>> discuss on the mailing list.  To this end, we're asking that 
>> interested parties do just this over the course of the next ~two 
>> weeks. Following that period, on 4/28, we'll be initiating a 
>> consensus call that will last an additional two weeks, with the aim of
converging modeling language / protocol by Friday, 5/9.
>> 
>> The consensus call should also generate proposals for any material 
>> changes required to the underlying protocols.  These proposals in 
>> turn will form the basis for a later draft including gap analysis and 
>> said changes.  Those strongly in favor of one protocol over another 
>> should be prepared to contribute to this analysis.
>> 
>> 
>> best,
>> 
>>  -ed
>>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:41:07 -0400

Behcet:

The choice between two was because only two protocols groups (IETF protocols at that!) suggested they met the requirements.  The call has been made at last 3+ meetings. Any new protocol that comes in must prepare as much as Andy Bierman did and Jamal Salim did for IETF 89.

One other caveat… the protocol will need to make change so the protocol must be under the change control of the IETF for I2rs use  Since, ONF has its own change control I suspect that also creates a barrier. 

Sue 

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, April 18, 2014 11:57 AM
To: Susan Hares
Cc: Dean Bogdanovic; [email-masked]; Edward Crabbe; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

Behcet: 

 

Don't get me wrong.

But the point is that a more realistic choice should be between these two choices.

Behcet 

Sue Hares 

Hi Dean,

Regards,

Behcet 

Jamal,

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:42:18 -0400

Behcet:

The burden of proof was on the group that proposed the forces/forces or yang/netconf models. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Friday, April 18, 2014 11:57 AM
To: Susan Hares
Cc: [email-masked]; Edward Crabbe; Dean Bogdanovic; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

Behcet: 

 

Don't get me wrong.

Behcet 

Sue Hares 

Hi Dean,

Regards,

Behcet 

Jamal,

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:51:10 -0400

Jamal and Tom:

Dean Bogdanovic and Ron Bonica clearly indicated there were two reasons:
business and technical.   My understanding is that Ed Crabbe's context for
this discussion was to judge technical merit. Did I misunderstand the
context of this discussion to be engineering?  

If this is an engineering discussion -  Tom it would be helpful to discuss
the engineering reasons for Brocade's choice for restconf/yang. 

Some good engineering reasons might be that the Vyatta acquisition provided
them with a tool chain that was ready for the restconf/yang.  You could
further comment on if the Vyatta deployments with restconf/yang were able to
pull massive amount of routes or status? 

Did early deployments of Vyatta's took chain in data centers or WAN networks
encounter any problems?  Did you easily integrate new features?   The web
buzz on this sounds like a bee-hive buzzing,  so ... the engineering details
would be great.  And since Vyatta is open source ... 

 Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, April 18, 2014 12:03 PM
To: Thomas Nadeau
Cc: [email-masked]; Crabbe Edward; Dean Bogdanovic
Subject: Re: [i2rs] consensus on I2RS protocol and model

cheers,
jamal

>>> sense. We already built the Junos model in YANG and have or are in
process of building needed tools.
>>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are 
>> a view is motivation for many unfortunately often disguised as 
>> technical opinion). While i empathize, I would like to point that we 
>> need to have these discussions which are technical otherwise there is 
>>> reason (and there might be, but I'm not aware of it), don't see reason
to switch from RESTCONF and YANG.
>> dont have to respond to long emails. If you have issues with ForCES 
>> please bring them up as well and we can discuss (I brought up a few 
>> in my presentation).
>>
>> numbers against some agreed-to info model (eg the rib) and see how 
>> this requirement is met by the different protocols.
>>
>> (who i  consider to be a sage in this space):
>> "If I was writing an info model I'd use YANG every time.  But if I 
>> was writing a data model I'd go for ForCES."
>> There is also the issue of i2rs ability to describe instances which 
>> is lacking in Yang; but maybe leave that out to a different email..
>>
>> cheers,
>> jamal
>>
>>> to go, but that can be always changed. From my perspective it looks
right today.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:55:03 -0400

Jamal:

Were you looking for details on OF-Config?  I've enjoyed our discussions of
the OF-Config protocol - so this would be fun.  However, my understanding is
that any proposal for i2rs data model language/protocol needs to at least
have one person who is willing to stand up and support it.   

Without someone to propose it, I suspect we are just delaying Mr. Ed's I2rs
deadlines. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, April 18, 2014 12:04 PM
To: Thomas Nadeau
Cc: [email-masked]; [email-masked]; Crabbe Edward; Dean Bogdanovic
Subject: Re: [i2rs] consensus on I2RS protocol and model

cheers,
jamal

>> business perspective for Juniper going with RESTCONF/YANG make more
sense.
>> We already built the Junos model in YANG and have or are in process 
>> of building needed tools. Same goes for RESTCONF.
>> RESTCONF as well, so this looks like a low hanging fruit from 
>> business perspective.
>>
>> (and there might be, but I'm not aware of it), don't see reason to 
>> switch from RESTCONF and YANG.
>> We can find out down the line that RESTCONF/YANG was the wrong way to 
>> go, but that can be always changed. From my perspective it looks right
today.
>> >>  At the last I2RS WG meeting there was a great deal of 
>> >> conversation regarding selection of both modeling language and 
>> >> underlying transport protocol.  Consensus at the time was to make 
>> >> use of Yang and (NetConf or
>> >> RestConf) (unclear).
>> >>
>> >
>> > to go back and make educated decisions by actually getting 
>> > knowledgeable about the different views presented. "Consensus" that 
>> > you described above to me looked like  a pageant popularity contest 
>> > not based on anything technical ("who likes contestant in the blue 
>> > shirt? please cheer for them").
>> >
>> >> consensus call that will last an additional two weeks, with the 
>> >> turn will form the basis for a later draft including gap analysis 
>> >> and said changes.  Those strongly in favor of one protocol over 
>> >> another should be prepared to contribute to this analysis.
>> >>
>> >>
>> >> best,
>> >>
>> >>  -ed
>> >>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:55:45 -0400

Jamal and Behcet:

I will try to dig through the Use cases and get a list of requirement based
on use cases.  It will be a few days. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, April 18, 2014 12:41 PM
To: sarikaya
Cc: [email-masked]; Edward Crabbe; Dean Bogdanovic; Susan Hares
Subject: Re: [i2rs] consensus on I2RS protocol and model

On Fri, Apr 18, 2014 at 11:57 AM, Behcet Sarikaya <[email-masked]>
wrote:
>> Can you tell me how the ONF Management and configuration protocol 
>> will interface with the routing system with all the requirements set
forth by the

Why?

You know what would be really useful is to show up at the next meeting with
implementations of I2RS - perhaps a few demos and discuss what the lessons
learnt are.

cheers,
jamal

>> in email or any substantial way, we will listen.  In my observations, 
>> the ONF management protocol was designed for the ONF flows and not 
>> the information models required or the use case required.
>>
>>
>>
>> Sue Hares
>>
>>
>>
sense.
today.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 19:56:42 -0400

Nitin:

If it was to be a candidate, did you know someone who wanted to be the chief
supporter in the IETF? 

Sue 

From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Friday, April 18, 2014 12:47 PM
To: [email-masked]; Susan Hares
Cc: [email-masked]; Edward Crabbe; Dean Bogdanovic; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

> Gap Analysis for different Protocols:  I2RS needs to select a protocol to
use.  I believe that we have volunteers for discussing RESTCONF. 

> We'd welcome hearing from others who can provide at least a presentation
for review before IETF and preferably a quick draft as well.

My 2 cents

Nitin

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Fri, 18 Apr 2014 23:59:49 +0000

>This has nothing  to do with meeting requirements for I2RS.

Sure it does. I2RS is ultimately about a set of programmatic APIs to the
routing system. The controller programmatic API is a superset of a device
programmatic API, since the controller must be able to proxy the device
and provide programmatic APIs to its own services. Now, if an IDL has
proven to be useful and/or meet the requirements in a environment which is
a superset of the target environment, then by definition it will be useful
and/or meet the requirements in the target environment.

>Have you implemented I2RS with netconf/restconf/yang?

Nobody has implemented I2RS, because the protocol has not been defined
yet. But I was deeply involved with Netconf/Restconf/Yang implementations
on both IOS-XR and on OpenDaylight. In any case, Netconf/Restconf/Yang
gives us today maybe 80-90% of what we need from I2RS for our use cases.

>Why not build around that and then refactor as needed?

Bingo! How about Restconf with JSON encoding? ;-)

>Why is it so hard to get requirements around here?  What is the point

The I2RS requirements have been gathered, and Netconf and Yang have been
analyzed against the requirements by Andy and Dean at the last IETF. I
find no fault in their analysis, so IMHO Netconf / Yang (with possibly
small modifications) will meet the technical requirements of I2RS.

What I and others have been trying to say is that the rest of the world is
moving towards Netconf/Restconf/Yang. Therefore, (besides it being a
good-enough technical choice), it is the pragmatic choice. If I2RS wants
to be relevant to operators, vendors, and the open source community, it
needs to go where all these entities want to be.

>Jamal

Thanks,
Jan

>>>go,
>>>>>transport
>>>>>adequate
>>>>>changes

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Sat, 19 Apr 2014 00:03:33 +0000

Sue,

>context of this discussion to be engineering?

I re-read Ed¹s email: it calls for marshaling of arguments and discussion
on the mailing list. It does not seem to say that the discussion and
arguments ought to be purely engineering.

Thanks,
Jan

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Apr 2014 20:19:43 -0400

Actually Jan, you made a leap there I did not follow.
You assert that "the controller programmatic API iis a superset of a
device programmatic API."
This does not seem to follow.  On the one hand, I would hope that a
controller is exposing abstractions,
which are unrelated to the device API.  And on the other hand, there may
well be many things the device API can do that the controller does not
need.  The I2RS charter makes it clear that I2RS is not intended to
replace other configuration mechanisms.

And the basic premise of I2RS is that there are requirements for the
work that were not addressed properly by the existing configuration
protocols.  Otherwise the WG would not even need to discuss protocol
modifications.  So the fact that NetConf / YANG works for device
configuration does not seem to be evidence that it works for what I2RS
wants to do.

I would actually guess that it is reasonably close, and I will live with
whatever conclusion the WG reaches about protocol and modeling.  But I
would not claim tha thte existing deployment is relevant evidence for
this problem space.

Yours,
Joel

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 19:21:12 -0500

> On Apr 18, 2014, at 6:59 PM, "Jan Medved (jmedved)" <[email-masked]> wrote:
> 
> 
> 

Spot on.

Tom

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 18 Apr 2014 21:13:07 -0400

Jan and Tom: 

Thanks for letting me know.   Thanks for the clarification.  Talk on. 

Ed's comments at IETF 89 inquired about a technical discussion regarding
FORCES and YANG rather than an "emotional" or simply business.     Both
aspects are important to a corporate decision, but it is the WG chairs that
set the constraints for our discussion.   

I am still interested in the technical side of the Brocade decision.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jan Medved (jmedved)
Sent: Friday, April 18, 2014 8:04 PM
To: Susan Hares; 'Jamal Hadi Salim'; 'Thomas Nadeau'
Cc: [email-masked]; 'Crabbe Edward'; 'Dean Bogdanovic'
Subject: Re: [i2rs] consensus on I2RS protocol and model

Sue,

>context of this discussion to be engineering?

I re-read Ed¹s email: it calls for marshaling of arguments and discussion on
the mailing list. It does not seem to say that the discussion and arguments
ought to be purely engineering.

Thanks,
Jan

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Sat, 19 Apr 2014 01:25:42 +0000

Joel,

Please see inline.

On 4/18/14, 5:19 PM, "Joel M. Halpern" <[email-masked]> wrote:

>device programmatic API.”
>controller is exposing abstractions, which are unrelated to the device
>API.  

Yes. I may have stated slightly differently - I called these abstractions
“controller’s own services”.

>And on the other hand, there may well be many things the device API can
>do that the controller does not
>need.  

Again, we are in agreement, with one possible twist: an application may
want to talk to the device not directly, but through the controller (I
think a while back we all agreed that this was a valid use case). I called
it “controller proxying the device”.

The point I was trying to make that Yang, as the IDL in the controller, is
suitable both for defining controller’s own service APIs and for proxying
of device APIs. I spoke from experience: we defined a bunch of controller
services and proxied a bunch of device APIs (netconf itself, PCEP,
OpenFlow) with yang models. It worked really well for all APIs that we
managed to throw at it :-).

To conclude: if yang works well in the controller environment, which is a
more complex API environment than a device, it will surely work well at
the device level. That’s all that I wanted to say.

>The I2RS charter makes it clear that I2RS is not intended to replace
>other configuration mechanisms.
>
>I would actually guess that it is reasonably close,

Again, we seem to be in agreement - I also said that the majority of use
cases that I can think of can be covered with Netconf/Restconf/Yang today.
I did not say we can cover everything. But, through the OpenDaylight
experience I found that Netconf/Yang could cover a lot more than what I
originally anticipated (which was actually quite surprising to me).

>and I will live with whatever conclusion the WG reaches about protocol
>and modeling.  But I would not claim that the existing deployment is
>relevant evidence for this problem space.

I actually think it is - what’s wrong with working code? ;-)

Thanks,
Jan

>>> On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved)
>>><[email-masked]>
>>> wrote:
>>>>>business
>>>>>>>conversation

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 18 Apr 2014 21:33:40 -0400

On Fri, Apr 18, 2014 at 9:25 PM, Jan Medved (jmedved) <[email-masked]> wrote:

[..]

> I actually think it is - what's wrong with working code? ;-)

Unless you have _working_ I2RS code - this is a meaningless statement to
make.
How about we strive to show up with some working I2RS code at the next
meeting?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Apr 2014 22:50:25 -0400

Thank you.
I had misread your note as talking about the (reasonably wide) use of
YANG for configuring routers.
I will agree that the use of YANG by ODL is evidence of the versatility
of the tool.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 19 Apr 2014 05:54:50 -0400

Tom:

On this 100% agreement with you - that those who wished to support OF-Config
should have presented at IETF 89. 

Sue 

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Friday, April 18, 2014 1:42 PM
To: b nitin
Cc: [email-masked]; Susan Hares; [email-masked]; Crabbe Edward; Dean
Bogdanovic; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur
<[email-masked]> wrote:

 

My 2 cents

Nitin

            --Tom

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 19 Apr 2014 14:12:18 +0000

Susan,

For YANG following is necessary:

publish current model in YANG
and
YANG compiler

We are looking at creating some additional tools to make easier for developers to work with YANG and Junos, but the above two are main conditions.

I usually start with informational model and try to see how will it work with data model. And then tweak certain things here and there. For very few things I went directly to data models, but the info model was already very well defined in my head :-)

Dean

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 19 Apr 2014 14:22:29 +0000

Jamal, 

What is working i2rs code? From Juniper perspective, I can claim having PoC i2rs code, as I can dynamically create REST APIs (will not call them RESTconf, as it has only partial compliance with current RESTconf draft) based on the service described on the device. The PoC functionally is very close i2rs architecture document and with that can see what services can be created and abstracted for i2rs.

So for i2rs, as long I can create a data model for a service, where the service is simple as add or delete route and can programmatically consume that service, it is i2rs. Many vendors today can do that with NETCONF/RESTCONF/YANG and we are voicing our preference for that.

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 19 Apr 2014 10:22:31 -0400

Dean:

Thank you for the prompt input.  This really helps me! I'm going through the
informational models this weekend to try to create a common platform.  

If you have time to comment over the next few days on the RIB-info models,
it would help.  I think the RBNF is causing rather than helping with issues.
I've switched over to the UML focus because it helps me find the issues with
the relationships to simplify the models. 

Sue 

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Saturday, April 19, 2014 10:12 AM
To: Susan Hares
Cc: Jamal Hadi Salim; <[email-masked]>; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

Susan,

We are looking at creating some additional tools to make easier for
developers to work with YANG and Junos, but the above two are main
conditions.

I usually start with informational model and try to see how will it work
with data model. And then tweak certain things here and there. For very few
things I went directly to data models, but the info model was already very
well defined in my head :-)

Dean

On Apr 18, 2014, at 7:27 PM, Susan Hares <[email-masked]> wrote:

> process of building needed tools. Same goes for RESTCONF. We have 
> NETCONF implemented in Junos and are working on RESTCONF implementation.
today.

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 19 Apr 2014 14:47:31 +0000

Susan,

I'm currently busy with few other things, but wanted to see how some of my work aligns with rib-info models, so planned to read the rib-info models by mid week anyway. 

Dean

---

From: "Russ White" <[email-masked]>
Date: Sat, 19 Apr 2014 11:22:39 -0400

> And the basic premise of I2RS is that there are requirements for the work
> that were not addressed properly by the existing configuration protocols.
> Otherwise the WG would not even need to discuss protocol modifications.
> So the fact that NetConf / YANG works for device configuration does not
> seem to be evidence that it works for what I2RS wants to do.

Precisely. Otherwise, we could have just looked at the problem, and said,
"let's use YANG." But I think we're starting to confuse the problem set
because we started by trying to boil the ocean. Once you actually get to
town, it's hard to keep in focus that you're just there for a new pitchfork
handle -- that game of checkers over there on the porch of the hotel looks
so interesting, and the hardware store has so much other stuff than just
pitchfork handles, after all. 

So, given we are _supposed_ to be focused on the RIB interface, and not
protocol, configuration, device, etc., etc., what specific points have the
use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of
the primary points was timing -- are these other systems fast enough?

>From my perspective, these two systems don't fulfill the I2RS mandate on the
RIB side for various reasons:

- I'm not convinced on the speed side. YANG feels a bit heavy weigh for what
we want here. The flexibility is there, but so is the cost of that
flexibility.

- I'm not convinced YANG has handled the atomicity issues in a way that
makes sense for the application environment we have in mind. RESTCONF seems
to go that direction, but I'm not certain it's a complete solution (?).

So, IMHO, I think we need to either consider FORCES, or "something new." But
we're going to have a hard time determining if this is true if we can't make
a solid requirements list. For me, these are:

- Atomic operations at the RIB level
- Speed that's comparable to a local routing process installing routes in
the RIB
- An immediate feedback system within the RESTful mold that tells the
installing process what happened, and why, with the route it just tried to
install in the RIB

So, it seems to me that we need to return to the use cases -- there are two
in the charter. If we want to discuss adding others, that's fine, but we
need to gain some focus, and stop trying to boil the ocean, if we want to
make any progress.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Sat, 19 Apr 2014 11:24:11 -0400

Why?

:-)

Russ

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Apr 2014 10:46:00 -0700

Hi,

> we want here. The flexibility is there, but so is the cost of that

Can you explain how an off-line representation of the data model can be
fast or slow?
You mean the YANG compiler takes too long to process a YANG file?
You mean the unspecified I2RS protocol will be too slow on the wire if
it uses XML or JSON encoding of YANG data structures?

> to go that direction, but I'm not certain it's a complete solution (?).
YANG is a data modeling language.
RESTCONF is a protocol.
Atomicity is a property of the protocol.
Which YANG statements prevent this from being accomplished in the TBD I2RS
protocol?

> need to gain some focus, and stop trying to boil the ocean, if we want to
It seems to me this WG needs to start asking the right questions about the
data modeling language requirements.  E.g.:

  - What are the data types needed?  Is this a static set of will it ever
change?
  - What are the high level data modeling constructs needed?
  - Are user defined types needed?
  - Are re-usable data definitions needed?
  - Does the data model need to be modular?  How does it grow over time?
  - Can vendors add data definitions that extend the standard definitions?
  - How are new definitions added in a way that does not break existing
clients?
  - How is mandatory to implement vs. optional to implement functionality
handled?
  - How is mandatory to use vs. optional to use functionality handled?

You are asking about protocol requirements, not data modeling.
IMO it would be near-sighted and extremely impractical to choose
a language that only supported description on RIB info.  I fail to see what
is so special about RIB info that would warrant its own DML.

:-)

Andy

---

From: "Russ White" <[email-masked]>
Date: Sat, 19 Apr 2014 14:06:37 -0400

> Can you explain how an off-line representation of the data model can be
fast
> or slow?

Marshalling can still be fast or slow. I'm not convinced that YANG, being
focused on management, rather than protocol level interaction, doesn't have
a lot of stuff that's not needed, and does have all the stuff that's needed
-- nor do I understand what the overhead of carrying the stuff that's not
needed is going to be. 

> You mean the unspecified I2RS protocol will be too slow on the wire if it
uses
> XML or JSON encoding of YANG data structures?

If I2RS on the wire uses all YANG structures and NETCONF, then it won't be
I2RS -- it'll be YANG. That's okay if we look at the requirements and
determine that YANG resolves all of them. In that case, fold the WG and be
done -- it's a lot of extra work for no net gain. Again, however, I'm not
convinced that YANG fulfills all the requirements at hand.

> Atomicity is a property of the protocol.

Kindof. You can build a model that assumes atomic processing, and hence
includes everything in the model to make certain atomic processing will work
correctly. Or you can assume the data model will be used for just reading
and writing discrete pieces of data, and then say, "we leave how to actually
use the data up to someone else." YANG seems to do the latter, not the
former. 

To put it a different way -- you can look at the problem of interacting with
the RIB in two ways:

- I want to be able to read stuff out of and push stuff into the RIB from
time to time.
- I want to interact with the RIB in parallel with other routing processes
in near real time.

I'm not convinced these are the same question. Can you prove they are? 

> data modeling language requirements.  E.g.:

Data modeling is only half the problem -- part of the issue here is we've
jumped right from a really large number of use cases to, "let's build data
models," then to, "hey, these look a lot like YANG, so let's just use YANG."
The interaction between the RIB and off box processes are important, too --
but we've apparently just left those behind in the rush to models.

> You are asking about protocol requirements, not data modeling.

Right! So let's go back to the protocol work, and once we have protocol and
application level requirements, based on use cases, then we can ask, "hey
does YANG have all the bits we need to make this work?" Right now, we don't
know what the bits we need to make this work really are, so choosing a data
model, or having some sort of competition between data models, doesn't make
a lot of sense, to me.

> IMO it would be near-sighted and extremely impractical to choose a
language
> that only supported description on RIB info.  I fail to see what is so
special
> about RIB info that would warrant its own DML.

So you'd argue that all the requirements in all the different use cases can
be fulfilled with YANG? There is _nothing_ unique in _any_ of those use
cases the YANG model doesn't support? Do the analysis and prove it.

:-)

Russ

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Apr 2014 11:26:29 -0700

> cases the YANG model doesn't support? Do the analysis and prove it.

Perhaps we agree on 1 thing -- this is all speculation without a protocol
definition.  You are confusing the protocol properties and data model
properties with the data modeling language properties.  If you don't like
the sentence, you don't blame the alphabet.  YANG is just the schema
for describing valid instances of conceptual data.  The protocol operations
and server implementation performance depend on how YANG is used.

I am still unclear on this "E is for Engineering, so we don't mention tools"
thing.  That sounds like computer science , not engineering.  Engineers
need to worry about the practical implementation of the design.
The ability to leverage existing technology is extremely relevant
to software engineering.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Apr 2014 14:35:47 -0400

There are a number of modeling and protocol expectations (I think they 
can be reasonable called requirements, and I think they have been agreed 
by the working group) in the architecture draft.  Some of them are a 
stretch for YANG.  Some of them are a stretch for ForCES.

Yours,
Joel

On 4/19/14, 1:46 PM, Andy Bierman wrote:
> Hi,
>
>
> On Sat, Apr 19, 2014 at 8:22 AM, Russ White <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> Which YANG statements prevent this from being accomplished in the TBD
> I2RS protocol?
>
>    - What are the data types needed?  Is this a static set of will it
> ever change?
>    - How is mandatory to implement vs. optional to implement
> functionality handled?

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Apr 2014 12:02:27 -0700

On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <[email-masked]>wrote:

> There are a number of modeling and protocol expectations (I think they can
> be reasonable called requirements, and I think they have been agreed by the
> working group) in the architecture draft.  Some of them are a stretch for
> YANG.  Some of them are a stretch for ForCES.
>
>
I assume you mean sec. 6.4.5?
I did not find anything in there that YANG does not already support or
could not
support with a YANG extension statement.  Since I2RS can define its own
YANG extensions, YANG is ready today to meet all the requirements.
Can you be more specific about the stretch items?

Yours,
Andy

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 19 Apr 2014 15:08:27 -0400

On Sat, Apr 19, 2014 at 10:22 AM, Dean Bogdanovic <[email-masked]> wrote:

>
> What is working i2rs code?

Code that implements, using your choice of model and protocol, the I2RS
semantics. To examplify using your slides at the meeting, iirc,
such semantics would be between the agent  one side and what iirc
you called client (in our case we call them Apps).
i.e  take something like the RIB info model and cast it into your model choice
and make APIs available to message things between a basic agent and
the routing daemon.

>From Juniper perspective, I can claim having PoC i2rs code, as I can dynamically create
>REST APIs (will not call them RESTconf, as it has only partial compliance with
>current RESTconf draft) based on the service described on the device. The PoC functionally
>is very close i2rs architecture document and with that can see what services can be created
>and abstracted for i2rs.
>
> So for i2rs, as long I can create a data model for a service, where the service is simple as add or >delete route and can programmatically consume that service, it is i2rs. Many vendors today can do >that with NETCONF/RESTCONF/YANG and we are voicing our preference for that.
>

Sorry, I dont think that is sufficient. The programmatic APIs part is obvious.
There are bigger issue which shape how a protocol is to be wired and
what model would be
sensible; in my response ealier, one you and I discussed was speed.
How do you do
a 1000 route update or add with JSON?
If it is a requirement then the agent needs to be able to handle
clients of different
latencies etc and deal with congestion issues that are common in proxies when
you have multiple users being considered and probably a single entry
to the routing interface.
If it is not a requirement - should that not be  stated somewhere?

Unfortunately - we are not having that kind of useful discussion and i
feel  like a broken
record asking for requirements.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Apr 2014 15:08:20 -0400

I actually expect that YANG can be extended to do what is needed.  I 
also expect that ForCES protocol can be extended to do what is needed on 
the protocol side.

But that is not the same as saying that either item "as is" meets the 
needs as stated.

It would seem appropriate to at least describe what extensions will be 
needed to YANG before we decide to say "yes, we will use YANG and we 
will extend it to address the needs."

On the ForCES side, I believe Jamal did include that information in his 
presentation.  Is there a similar list for YANG that I have misplaced?

Yours,
Joel

On 4/19/14, 3:02 PM, Andy Bierman wrote:
>
>
>
> On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     There are a number of modeling and protocol expectations (I think
>     they can be reasonable called requirements, and I think they have
>     been agreed by the working group) in the architecture draft.  Some
>     of them are a stretch for YANG.  Some of them are a stretch for ForCES.
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>               > And the basic premise of I2RS is that there are
>         requirements for
>              the work
>               > that were not addressed properly by the existing
>         configuration
>              protocols.
>               > So the fact that NetConf / YANG works for device
>         configuration
>              does not
>              Precisely. Otherwise, we could have just looked at the
>         problem, and
>              said,
>              town, it's hard to keep in focus that you're just there for
>         a new
>              pitchfork
>              handle -- that game of checkers over there on the porch of
>         the hotel
>              looks
>              protocol, configuration, device, etc., etc., what specific
>         points
>              have the
>              - I'm not convinced on the speed side. YANG feels a bit
>         heavy weigh
>              for what
>              So, IMHO, I think we need to either consider FORCES, or
>         "something
>              new." But
>              we're going to have a hard time determining if this is true
>         if we
>              can't make
>              installing process what happened, and why, with the route
>         it just
>              tried to
>              install in the RIB
>
>              So, it seems to me that we need to return to the use cases
>         -- there
>              are two
>              need to gain some focus, and stop trying to boil the ocean,
>         if we
>              want to
>              make any progress.
>
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 19 Apr 2014 12:16:12 -0700

Hi,

On Sat, Apr 19, 2014 at 12:08 PM, Joel M. Halpern <[email-masked]>wrote:

> I actually expect that YANG can be extended to do what is needed.  I also
> expect that ForCES protocol can be extended to do what is needed on the
> protocol side.
>
> needed to YANG before we decide to say "yes, we will use YANG and we will
> extend it to address the needs."
>
>
I did that already.  See the I2RS slides from IETF #89.

>>               >From my perspective, these two systems don't fulfill the
>> I2RS
>>              mandate on the
>>              - Speed that's comparable to a local routing process
>> installing
>>              routes in
>>              the RIB

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 19 Apr 2014 15:36:05 -0400

I think this progress.
I would be more than happy to go over the requirements listed there
and whatever more for an "stretch" analysis needed for both protocol
and model. In other words, some process. A joint draft perhaps.

cheers,
jamal

---

From: Dean Bogdanovic <[email-masked]>
Date: Sat, 19 Apr 2014 20:11:47 +0000

> a 1000 route update or add with JSON?

It comes down how many transactions are required? Will you updated 1000 routes in single transaction or in 1000 transactions.

>From my perspective there are two important metrics for i2rs
throughput
and
latency

IMO, I2RS agent has to provide as high as possible throughput and add minimal latency to the process. What is the throughput required? Don't know at the moment. I saw some request in high single digit thousands per second, but not sure about use cases. On the latency side, you want it as close to 0 as possible, but that will be highly platform dependent.

I have to start doing some PoCs to see what can and can not do with existing tools. If those tools work, then good. If those tools don't work, then back to the drawing board. Until things work, keep on moving with what works and try to find break points.

> If it is not a requirement - should that not be  stated somewhere?

You can add your comments to the existing drafts.

> record asking for requirements.

I believe we have a set of requirements. It is in draft-rfernando-i2rs-protocol-requirements. You can always comment that draft and argue pro and con each requirement.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 19 Apr 2014 20:49:34 -0400

On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <[email-masked]> wrote:

> It comes down how many transactions are required? Will you updated 1000
> routes in single transaction or in 1000 transactions.
>

Take your pick. The point is it boils down to how that is modelled and carried
over the wire (and influences those decisions).

> From my perspective there are two important metrics for i2rs

Now we are talking.

>
> IMO, I2RS agent has to provide as high as possible throughput and add minimal latency to the >process. What is the throughput required? Don't know at the moment. I saw some request in high >single digit thousands per second, but not sure about use cases. On the latency side, you want it as >close to 0 as possible, but that will be highly platform dependent.
>

Agreed.

> I have to start doing some PoCs to see what can and can not do with existing tools. If those tools >work, then good. If those tools don't work, then back to the drawing board. Until things work, keep on >moving with what works and try to find break points.
>

But i do believe there are limitations which are not obvious without
contrasting against requirements.

> You can add your comments to the existing drafts.

I would gladly do - but i worry whether the discussion is about crowning some
solution instead of meeting such objectives;  if the WG decides to move in that
direction i would be happy to contribute.
There's material floating, the old protocol draft; Joel pointed to the
architecture
draft covering model requirements. Andy mentioned  possible "stretch"
requirements. I think what would be appropriate is one draft for the model
and one for the protocol with gap analysis.

> I believe we have a set of requirements. It is in draft-rfernando-i2rs-protocol-requirements.
>You can always comment that draft and argue pro and con each requirement.

Glad we are bringing that draft into play;-> How does restconf fair against it?
Note: The draft is a good starting point but is missing as an example
the issue of
latency and throughput.

cheers,
jamal

---

From: ramki Krishnan <[email-masked]>
Date: Sun, 20 Apr 2014 12:53:41 -0700

Thanks,
Ramki (Brocade Communications Systems, Inc.)

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Geoffrey Mattson
Sent: Friday, April 18, 2014 3:11 PM
To: Jeff Tantsura; Jan Medved (jmedved); Dean Bogdanovic; Jamal Hadi Salim
Cc: [email-masked]; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

On 4/18/14 3:04 PM, "Jeff Tantsura" <[email-masked]> wrote:

>>Cisco is also implementing Netconf - it¹s available on XR today, and 
>>it will be available on other platforms as well.
>>
>>Also, as Tom pointed out, Netconf and Restconf have also been 
>>implemented in ODL. I¹d like to stress that we not only have multiple 
>>Netconf/Restconf implementations from multiple vendors (Brocade, 
>>Juniper, Cisco, just to mention those on this thread), but have 
>>multiple open source implementations as well. In addition to ODL, 
>>there is libnetconfd and a few others.  ODL / libnetconfd interop 
>>testing is done in the ODL regression test suite.  Now, since there 
>>are multiple independent open source implementations, we¹ve got a good 
>>ecosystem for implementation of new Netconf/Restconf/Yang features 
>>that may be required to meet i2rs¹s needs (if the need to evolve the 
>>protocols/language arises).
>>
>>In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang 
>>as the modeling language.
>>
>>
>>
>>Thanks,
>>Jan
>>
>>
>>>process of building needed tools. Same goes for RESTCONF.
>>>go, but that can be always changed. From my perspective it looks 
>>>right today.
>>>
>>>>>and said changes.
>>>>>Those
>>>>> strongly in favor of one protocol over another should be prepared 
>>>>>to  contribute to this analysis.
>>>>> 
>>>>> 
>>>>> best,
>>>>> 
>>>>>  -ed
>>>>>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 21 Apr 2014 05:46:22 +0000

On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email-masked]> wrote:

>> IMO, I2RS agent has to provide as high as possible throughput and add
>>minimal latency to the >process. What is the throughput required? Don't
>>know at the moment. I saw some request in high >single digit thousands
>>per second, but not sure about use cases. On the latency side, you want
>>it as >close to 0 as possible, but that will be highly platform
>>dependent.
>>
>
>Agreed.

Both throughput and latency are meaningless from the standardization point
of view - they both largely depend on the underlying system.

Speaking for NC/Y implementations that I¹ve been involved with, the
throughput of the Netconf Agent itself is much larger than the rest of the
system, and its latency is negligible compared to the rest of the system.
This happens to be true both for an embedded agent (XR), where ultimately
both throughput and latency are determined by how fast you can program
hardware, and for the controller, where both throughput and latency depend
on how fast you can shove things into a data store.

Rather than focusing on devising a super fast binary encoding for the
protocol (which will speed up maybe 2-5% of the overall CPU cycles), we
need to have a self-describing schema-based message encoding which allows
for creation of tools that generate most of the agent and client code.
NC/RC/Y gives us exactly that. The raw speed of the agent (optimized
protocol processing, message encoding, etc.) must be weighed against the
ease and speed with which new APIs can be added to system - we have
Moore¹s law for CPUs, but not for human brains ;-)  We need to compensate
for that with tooling/automation.

>
>> I have to start doing some PoCs to see what can and can not do with
>>existing tools. If those tools >work, then good. If those tools don't
>>work, then back to the drawing board. Until things work, keep on >moving
>>with what works and try to find break points.
>>
>
>> I believe we have a set of requirements. It is in
>>draft-rfernando-i2rs-protocol-requirements.

Reasonably well. When we evaluated restconf against these requirements (I
am a co-author), the major deficiency found was lack of notifications in
restconf, which was addressed in a subsequent restconf revision. There are
still things that would have to be added (for example, client identities),
but this can be addressed either in the protocol or in models. There is
nothing *structural* in restconf that would prevent it from satisfying the
requirements set. 

And as I said earlier in this thread, about 80-90% of what I can think
that we can do with I2RS (and it¹s much, much more than just RIB
programming ;-) ) can be addressed with NC/RC/Y today.

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 21 Apr 2014 06:15:16 +0000

Russ,

On 4/19/14, 11:06 AM, "Russ White" <[email-masked]> wrote:

>>language that only supported description on RIB info.  I fail to see
>>what is so special about RIB info that would warrant its own DML.
>

What you are asking for would be a lot of work for no practical purpose.
Yang has been proven to work in practice for everything that we managed to
throw at it. I have two data points:

 - In XR, we generated yang models from internal CLI schemas - we
generated models 
   for the entire CLI, for all features supported by XR, some 200 models
overall. 
   The entire system can be managed by NC/Y.

- In OpenDaylight, we define APIs as yang models. We created yang models
for
  OpenFlow, ACLs, BGP protocol and BGP RIB, PCEP Protocol and tunnel
programming 
  service, network wide services such as topology and inventory, etc.
Overall, 
  about 110 models in production code (overall, over 300 models have been
  defined, but a lot of them are for testing)

In addition, we have started to create models for new service definitions
both on device and off-device, such as policies, analytics, subscribers,
security, new protocol definitions, Š We have not really run into any
limitations. Also, as Andy pointed out, if yang does not cover something
you need, you can define your own extension. So far, we only had to define
a couple.

Thanks,
Jan

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 21 Apr 2014 07:36:44 -0400

> of view - they both largely depend on the underlying system.

I am sorry, I disagree. Understanding latency and throughput needs is
fundamental.
We are talking about a part of the system that is optimized for speed typically
(at least I hope your RIB manager is) that you will now need to interact with.
We are not talking about you banging at some 8 bit PIO bus on a
micro-controller.

> on how fast you can shove things into a data store.

You have a single user in that case. Factor in the many users.
Your focus in that case is  provisioning. I2RS is not a CLI replacement.
It is not a provisioning system. If i am mistaken and it falls under
the auspicies
of either CLI replacement or provisioning - then by all means Netconf/Yang is
a clear selection and lets end the discussion.
Even if say a few tens/transactions per second is what the requirement says
then I would go with your approach.

> protocol (which will speed up maybe 2-5% of the overall CPU cycles),

I'd like to argue your 2-5% (as i am sure papers which have been written on how
to speed up string processing will), but lets just ignore that for a sec:
Lets say your approach takes 1000 cycles. You can say only 2-5% of those cycles
are used for encoding/decoding ascii. That would be a correct statement to make.
What it is ignoring is: you are spending 1000 cycles instead of 50 for
the overall
computation.

>we
> NC/RC/Y gives us exactly that.
>

So does ForCES. BTW, Ive heard you repeat this statement above a few times
(as well as from Thomas);
Programmatic APIs are a given. We've had them in ForCES
implementations for a few
years. We were told IETF is not about APIs - just protocols; so nobody bothered.
I will make that clear again: We have programmatic APIs.

>The raw speed of the agent (optimized
> Moore¹s law for CPUs, but not for human brains ;-)

Agreed - but within reason. There is a cross-over where it is abuse of human
intelligence i.e there is a threshold where it is not sensible to
optimize for efficiency
at the expense of usability - but if i can get both; what is the problem?
I dont think  we are that different from a usability perspective.

We have different perspectives. You have been doing provisioning
systems where latency and throughput require to be better than humans;
I have been working on systems where i need to failover or have a board
with a few hundred thousand table rows boot up very fast.
My view is I2RS is closer to my perspective.

>We need to compensate for that with tooling/automation.
>

Jan, how about this:
You show up with your tools and i will show up with mine. The starting point
would be an information model that none of us have seen before.
Lets convert that to a data model, output code and start using it via an app.
If I beat you by <5 minutes - you win. Lets do this live at the next meeting;->

> nothing *structural* in restconf that would prevent it from satisfying the

As i said earlier, the draft is a good starting point but not
sufficient (It also
delves into areas that are not protocol specifics).
To be honest, I dont recall seeing it when i published my gap analysis here:
http://datatracker.ietf.org/doc/draft-hadi-i2rs-forces-gap-analysis/
I was going to update my draft (in which case I will reference it); but i am
not sure if it will be worth it.

> programming ;-) ) can be addressed with NC/RC/Y today.

Lets take that hammer and use it to fix everything we see on our way.

Note: I am not even arguing ForCES is the way to go - this may be
a totally different protocol.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 21 Apr 2014 07:51:08 -0400

> What you are asking for would be a lot of work for no practical purpose.

Sigh. I thought there was some process that we needed to follow.

Here's a proposition:
How about we settle to just an information model to begin with?
This is what approaches like openstack do.
You can use Yang. We'll use ours. You can use netconf/restconf and
we'll use whatever modification we need on ForCES. We both publish
our results after real code exists.

cheers,
jamal

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 05:56:30 -0700

> for that with tooling/automation.

Great points.

There are some specific areas where the data modeling language can
impact protocol performance.  The most significant is the handling
of default leafs.  A well-designed data model will pick reasonable
default values for most leafs.  Since defaults are mandatory-to-implement
in YANG, a client can omit defaults when creating a new data structure.
This can have a much bigger impact on throughput than binary encoding.

A protocol can be fast by being clever, not always just by brute strength
compression.  For example, clever use of PATCH to update the absolute
minimum set of  objects is smaller and faster than replacing entire
subtrees with PUT.

The biggest impact a data modeling language can have on the protocol
is wrt/ human usability and tool automation.

Andy

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 21 Apr 2014 13:01:49 +0000

Jamal,

Majority of the people are using today NC/RC/YA (because it is available) and it provides necessary functionality. Many people, including myself, didn't find any issues so far with it and we believe it is the right choice.
If you remember, at the beginning I mentioned two criteria, technical and business. NC/RC/YA are satisfying both of them for lot of people in this group.
You are trying to explain why ForCES is better then NC/RC/YA and I appreciate it, but it is not better for my case and why should I go ahead and implement ForCES on the company platform, when there is no request from the market and the existing tools are working satisfactory.

People do not have to explain their vote, they can just cast it, as it is their opinion.

Dean

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 21 Apr 2014 13:07:57 +0000

Hi Jan,

You said:

" Both throughput and latency are meaningless from the standardization point
of view - they both largely depend on the underlying system.

for that with tooling/automation."

I have a couple of questions:
1. AFAIK we don't have yet a routing protocol whose speakers exchange XML encoded messages, why is that?
2. Do you think we could replace BGP transport with Netconf RPCs? (I am pessimistic about what Yakov would say about this idea :=))
3. If I am to develop an i2rs client that can learn or generate route updates at the speed and volume  of a regular BGP speaker, can it, using Netconf, instal these updates in the i2rs agent's RIB in a timely manner? What if i2rs client is twice as fast as the BGP speaker? What if there are two or more such i2rs clients talking to the same i2rs agent? Are these are reasonable use cases at all ?
4. Could we replace BGP transport with ForCES? 
5. Is it not possible that for some things i2rs will end up using Netconf, while for others ForCES and/or something else? 

IMHO we can not give convincing answers for 3. and 5. until we see the requirements agreed upon by all interesting parties. In this I totally agree with Jamal.
My personal answer to 4. is why not? It is binary and hence as fast. I happen to like the granularity at which ForCES protocol allows for incremental updates and how the messages could be limited both in size and CPU processing to just the very things that have changed.

Regards,
Igor

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 21 Apr 2014 09:21:33 -0400

Dean,

On Mon, Apr 21, 2014 at 9:01 AM, Dean Bogdanovic <[email-masked]> wrote:
> Jamal,
>
> Majority of the people are using today NC/RC/YA (because it is available) and it provides necessary >functionality. Many people, including myself, didn't find any issues so far with it and we believe it is >the right choice.

You have NOT implemented the spec to justify that technical arguement.
As an example, In your last posting you said latency and throughput
was important.
Jan claims they are irrelevant. Is it a requirement? My answer and your is yes.

> If you remember, at the beginning I mentioned two criteria, technical and business.

I know "business" reasoning is a BIG driver; unfortunately often made
to appear like the
reasoning is technical (Ive said before i appreciate your sincerity).
Dean, I think you should look at this with "bussiness" outside the picture.
If you were to be given a chance to get this right from a technical
pov - what would
you do? There is an "E" in IETF (no "B"); yes i am trying my best to
be pragmatic
and not ignoring the "B" - but only when all is equal that becomes a
clear decider.
To be noted again: I am not even pushing for ForCES, but it definetely
aint netconf
or restconf - sorry.

> NC/RC/YA are satisfying both of them for lot of people in this group.
> You are trying to explain why ForCES is better then NC/RC/YA and I appreciate it, but it is not better >for my case and why should I go ahead and implement ForCES on the company platform, when >there is no request from the market and the existing tools are working satisfactory.
>

sure - so what is wrong then with letting you go and do restconf and
me do ForCES.
Lets just have the "market" decide? All i am asking for is the process
be followed or
have the tyranny of the majority take over.

> People do not have to explain their vote, they can just cast it, as it is their opinion.

There is a difference between a vote and a discussion. I believe we
are in discussion
mode right now. In discussion mode people voice opinions not cast a ballot.

cheers,
jamal

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 06:32:59 -0700

On Mon, Apr 21, 2014 at 6:21 AM, Jamal Hadi Salim <[email-masked]> wrote:

> > Majority of the people are using today NC/RC/YA (because it is
> available) and it provides necessary >functionality. Many people, including
> myself, didn't find any issues so far with it and we believe it is >the
> right choice.
>
> > You are trying to explain why ForCES is better then NC/RC/YA and I
> appreciate it, but it is not better >for my case and why should I go ahead
> and implement ForCES on the company platform, when >there is no request
> from the market and the existing tools are working satisfactory.
> >
>

It looks to me like the market already has decided.
NETCONF started in 2002 and was first published as an RFC in 2004.
Now, 12 years later, it is finally being significantly deployed.
(Delay is mostly because converting legacy systems from ad-hoc hand-made
CLI is hard.)

Will it take 10 more years for vendors to deploy ForCES?
Are any vendors shipping it now? If not, how soon?

Ignoring the tool-chains and the history and claiming that both
NETCONF/YANG and ForCES
are at the same level of maturity is not really fair.

Andy

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 21 Apr 2014 09:54:52 -0400

Sigh - ok, I guess we need to address this elephant in the room.
Feel free to change the subject line.

On Mon, Apr 21, 2014 at 9:32 AM, Andy Bierman <[email-masked]> wrote:
> (Delay is mostly because converting legacy systems from ad-hoc hand-made CLI
> is hard.)
>

The _big box vendors have decided_ as is evident in this thread.
The market used to be driven by vendors deciding. New rules.
If the "market" had decided all along then OF wouldnt be making the dent
it did. We wouldnt even have an I2RS working group or this discussion today.
If OF (regardless of its deficiencies) had come to the IETF it would have been
dead on arrival because the "market" would decide differently.

> Will it take 10 more years for vendors to deploy ForCES?

Traditional vendors have refused to deploy ForCES. That is their choice
and i can empathize with their point of view.
Look - the old rules of "vendor needs to deploy" equalling success is
what held back ForCES by deciding to do this at the IETF.
OTOH, I know without coming to the IETF we would be not as complete as
i believe we are. Tapping into the great system of expertise at the
IETF has been
extremely invaluable. Death by +1 - not so much.

> Are any vendors shipping it now? If not, how soon?

Your definition of  "vendor" may vary. Andy, Yuma is a vendor; we are
a vendor. The rules have changed. We dont need the vertical supply chains
to define a protocol.
Hacking the system using old rules will make the IETF irrelevant.

> Ignoring the tool-chains and the history and claiming that both NETCONF/YANG
> and ForCES

respectfully disagree.
Jan keeps talking about all these great APIs they have. We've been
doing that for a decade.

cheers,
jamal

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 07:54:10 -0700

On Mon, Apr 21, 2014 at 6:54 AM, Jamal Hadi Salim <[email-masked]> wrote:

> CLI

I think Jan and others have explained why they think they can leverage
the NC/RC/YANG technology to implement I2RS. There are tool
and data model management requirements in addition to the protocol
in order to have a workable solution.

Unless the RIB data is one monolithic blob implemented without
variation on every router, then issues such as modularity, conformance
model,
data lifecycle, distributed naming authority, data augmentation,
and language extensibility are going to matter.

Andy

> NETCONF/YANG

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 21 Apr 2014 11:10:14 -0400

On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman <[email-masked]> wrote:
> model, data lifecycle, distributed naming authority, data augmentation,

So lets put all that in a requirement list somewhere and work around a gap
analysis.

cheers,
jamal

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 21 Apr 2014 16:55:48 +0000

Hi Igor,

>encoded messages, why is that?

I am not talking about routing protocols, but protocols that constitute
“APIs” into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ...

>2. Do you think we could replace BGP transport with Netconf RPCs? (I am
>pessimistic about what Yakov would say about this idea :=))

I am not suggesting that, although it’s doable. In ODL we internally
normalize protocol messages on yang-encoded NC RPCs and Notifications
before putting them on an internal message bus. We defined yang models for
OF, PCEP and BGP messages. BGP, PCEP, OF, etc is used externally, though.

When running benchmarks & profiling, the normalization is barely a blip on
the radar… The advantage is that we present a uniform view of protocols to
apps running in the controller and have  bunch of tools that generate a
lot of the app code that needs to interact with the respective protocol.
It also allowed us to re-use not only code, but design patterns as well.

>3. If I am to develop an i2rs client that can learn or generate route
>updates at the speed and volume  of a regular BGP speaker, can it, using
>Netconf, instal these updates in the i2rs agent's RIB in a timely manner?

As I said before, the protocol by which you learn the route updates is a
small fraction of the overall CPU cycles. For a large scale deployment
it’s more about the right organization of data in the RIB for fast updates
and scale; after that it’s about the speed at which you can install the
routes in hardware.

>What if i2rs client is twice as fast as the BGP speaker?

I don’t understand the question - how can an i2rs client interact with a
BGP Speker?

>What if there are two or more such i2rs clients talking to the same i2rs
>agent? Are these are reasonable use cases at all ?
>5. Is it not possible that for some things i2rs will end up using
>Netconf, while for others ForCES and/or something else?

"That's foolish. You pick the one right tool.” (Anton Chigurh in No
Country for Old Men)

Why would we do that? Two sets of engineering rules, configurations, tool
chains, bugs… (My $0.02)

> 
>
>IMHO we can not give convincing answers for 3. and 5. until we see the
>requirements agreed upon by all interesting parties. In this I totally
>agree with Jamal.

We have been discussing I2RS use cases and requirements for the past year
or so. It is my understanding that at the last IETF there were two
proposals that can meet the requirements: Forces and NC/RC/Y. There have
been cases made for each one of them - Andy and Dean made the case for
NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community to
a vote for one of the two.

Is my understanding correct or not? If my understanding is correct, why
are we going back to square one?

>My personal answer to 4. is why not?

"I am pessimistic about what Yakov would say about this idea :=))” (...
earlier in this email thread)

>It is binary and hence as fast. I happen to like the granularity at which
>ForCES protocol allows for incremental updates and how the messages could
>be limited both in size and CPU processing to just the very things that
>have changed.
>
>Regards,
>Igor
>

Thanks,
Jan

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Mon, 21 Apr 2014 16:58:30 +0000

Jamal,

We have been discussing I2RS use cases and requirements for the past year
or so. It is my understanding that at the last IETF there were two
proposals presented that can meet the requirements: Forces and NC/RC/Y.
The case has been made for each one of them - you made the case for
Forces, and Andy and Dean made the case for NC/RC/Y. Now, Ed has asked the
community to a vote for one of the two.

Thanks,
Jan

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 21 Apr 2014 17:57:23 +0000

Hi Jan,
Please, see in line.
Igor
________________________________________
From: Jan Medved (jmedved) <[email-masked]>
Sent: Monday, April 21, 2014 12:55 PM
To: Igor Bryskin; Jamal Hadi Salim; Dean Bogdanovic
Cc: [email-masked]; Joel M. Halpern; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

IB>> Were do you see routing or signaling protocols different? Why can't you use for example  Netconf/YANG for provisioning of TE paths?

IB>> Same question: why don't we replace signaling and routing protocols with Netconf/YANG and have a universal tool for all network control needs? 

IB>> But the WG like i2rs can only influence on the speed of the protocols, not internal NE architecture and infrastructure as you keep referring to as well as the facts we have to take your word for.

IB>> I meant to say what if i2rs client can produce calls to RIB manager twice as many as local BGP speaker.

IB>> Well, in the past we had a choice which IGP to use: OSPF or ISIS. The decision was to let market to decide, and it turned out that both are well deployed. Another example, we had to choose which signalling protocol to use for setting up TE paths. In this case we decided to choose one and ended up with the RSVP-TE, arguably the worst possible choice we could make (at least in case of transport networks), discarding all other options in a very early stage. 

IB>> I don't think we have a satisfactorily protocol/model requirement document yet, which is a tightly defined an unambiguous enumeration of qualitative and qualitative parameters of the protocol and model that are required, desired, etc. for i2rs architecture to be successful (Take a look for a good  example at MPLS-TP requirements RFC). We have to go to square one and write such a document, I think

Cheers,
Igor

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 15:02:18 -0400

> I am sorry, I disagree. Understanding latency and throughput needs is

I agree - the understanding is required to help us decide whether the
properties of a given data modeling language/protocol pairing satisfy our
requirements.  It may not be the primary deciding criterion but it will
certainly be a big one given the high-throughput desires we have for I2RS.

To use this as a jump-off point, what we need is a listing of such
requirements and properties of a given data modeling language/protocol that
realizes that perhaps better than another example.  I'm still familiarizing
myself with the IETF wiki and am unclear what sort of security permissions
are present in it, but I'm happy to provide wiki space for these things to
be enumerated.

For the above item, there are various properties from the different
mechanism that may be of benefit.  (I'm still not through my protocol
reading, so mistakes in characterization of a given protocol are all mine.)

The binary encoding of FORCES may help with speed.
It was asserted elsewhere (copied below) that this may only be 3-5% of a
speed improvement.  (I had thought I recalled a discussion in netmod(?) at
one point of a BER format for YANG, but my google-fu is failing me.)
A somewhat negative property of XML is that a document is only considered
valid once you have the whole document.  Thus, document size may matter.

> a clear selection and lets end the discussion.

I've been working through the various I-Ds in detail. Using the BGP use case
as an example, one of the desires may be to dynamically provision BGP
peering sessions.  Given that the I2RS cases are not strictly to provide the
configuration of BGP but are likely a subset of this piece of configuration
in an ephemeral context, this seems to suggest that the I2RS pieces of the
system should ideally have good alignment with configuration systems.  Thus,
if YANG were used for provisioning BGP, there's a strong desire for there to
be symmetry in the I2RS model - and thus potentially to share a portion of
the YANG.  The same observation would hold for a FORCES implementation of
I2RS.

Another example is the RIB.  

We want to leverage existing data models in a configuration context while
also providing I2RS extensions for configuration, monitoring, etc.

> What it is ignoring is: you are spending 1000 cycles instead of 50 for

The other half of such a discussion tends to be around letting other
consumers of the encoded information Do Something Useful with it.  This does
to some extent argue and influence what your programming model/API is.  If
your access to everything is always via strict API, binary encoding a great.
But an (IMO) advantage of text-based systems is that it's pretty trivial to
do a lot of things.  I suspect I'm not the only one that uses text-based
expansions of binary objects for various work.  (And I'll also note that I
leave things in binary format with API access when it makes sense.)

What I'm really saying is that the ecosystem is likely to expand binary
encoding to text just as much as it's going to move to a binary encoding.

> (as well as from Thomas);

Would you say section 4.5.3 of RFC 5812 provides a good example of that?
(Just to pick one from my reading.)

> > that we can do with I2RS (and it?s much, much more than just RIB

Jamal, while the point is being made perhaps a bit less than pleasantly,
there is certainly something there to discuss: The work Jan cites has a
depth of models that cover many pieces of functionality similar to those
that I2RS looks to address.  They've done enough work against Yang/Netconf
to have an idea of the remaining gaps.

While I agree that within the limited scope of the FORCES documents that
I've read that the modeling language and to a large extent the protocol can
similarly address the problems, I haven't the depth to determine whether
similar coverage of I2RS cases can be done within FORCES and what would need
to change.  It is also unclear aside from the binary encoding / more atomic
transaction model (note, I haven't read restconf yet for proper comparison)
that FORCES would bring vs. Yang/Netconf.  That comparison is what the WG
needs in somewhat greater depth than the existing gap analysis.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 15:13:59 -0400

On Mon, Apr 21, 2014 at 05:57:23PM +0000, Igor Bryskin wrote:
> ?APIs? into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ...

FWIW, L3VPN has draft-ietf-l3vpn-end-system using XMPP as a component. :-)

> it?s more about the right organization of data in the RIB for fast updates
> and scale; after that it?s about the speed at which you can install the
> routes in hardware.

I tend to agree here.  I've spent a fair amount of time analyzing the
marshalling code in 3 different BGP implementations and while there is room
to Do the Wrong Thing, most of the CPU is not spent in these paths.

Where bigger mistakes tend to be is taking the information to be presented
and deviating too greatly from the internal representation of that
information.

> are we going back to square one?

The request was really for two things:
1. Please look at the proposed mechanisms in DETAIL.  We already know there
are gaps and have been presented many of them by the experts in those
mechanisms.  Before the WG goes off and chooses something by popularity
contest, we owe it to ourselves as engineers to understand the systems well
enough to know what we're getting into.

2. By becoming familiar with the other system, we can see if there are
properties we really like that would need to be added into the competing
system.  To give an arbitrary example, if binary encoding is really that
helpful in the FORCES protocol, do we want something similar in
Netconf/Restconf if we chose that one?  If human-readable XML output is what
we really want, are there gaps in the properties we get in Yang that FORCES
would need?

> IB>> I don't think we have a satisfactorily protocol/model requirement document yet, which is a tightly defined an unambiguous enumeration of qualitative and qualitative parameters of the protocol…

Much of the motivation for this discussion was to help decide what should go
in such a thing.  We're not inventing something completely from scratch in
I2RS, we have existing things we can pick from.  If we know that something
that exists doesn't satisfy all of the needs via either comparison or other
means, the selected mechanism will need to evolve.

And while inventing our own might be neat, I think the majority of people
interested in I2RS related work would really just rather start writing code.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 15:16:14 -0400

> our results after real code exists.

Sue will have some document updates utilizing UML soon.  ABNF/RBNF has
proven to be insufficient for our purposes.

My suggestion is to wait on her updates and provide feedback on whether the
new format sufficiently addresses the concerns.

-- Jeff

---

From: Edward Crabbe <[email-masked]>
Date: Mon, 21 Apr 2014 12:56:17 -0700

Jeff;

+1    ^_^

This was originally the reason Jeff and I asked for a two week period
during which people could familiarize themselves more thoroughly with both
protocols.  From both my reading and advice/explanation from protocol
experts, both NetCONF/YANG and ForCES are entirely capable (with some minor
modifications) of performing the duties required by I2RS (from both
modeling and communications perspectives).

Supporting via +1 is fine (preferably with someone is echoing a previously
espoused argument set).  There is obviously a component of ease of use and
expedience in the protocol selection process here, especially given the
fact that both protocols seem to meet our specific needs without too many
contortions,  but the point of this discussion is to pinpoint any
deficiencies in the (other-guy's ?) protocol that we may have missed in
review thus far, aka the /gap analyses/  that Jeff and I have referred to.

Looking forward to hearing some more substantive debate here, and glad to
see it's started in the last 10 messages or so.

cheers,
   -ed

On Mon, Apr 21, 2014 at 12:13 PM, Jeffrey Haas <[email-masked]> wrote:

> > >1. AFAIK we don't have yet a routing protocol whose speakers exchange
> XML
> > >encoded messages, why is that?
> >
> > IB>> I don't think we have a satisfactorily protocol/model requirement
> document yet, which is a tightly defined an unambiguous enumeration of
> qualitative and qualitative parameters of the protocol and model that are
> required, desired, etc. for i2rs architecture to be successful (Take a look
> for a good  example at MPLS-TP requirements RFC). We have to go to square
> one and write such a document, I think
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 16:02:02 -0400

> Yang/Forces Data Model (Yang readable/Forces:Readable)   

FWIW, UML can do much of this but even some of the best authors on it note
that it can be a bit more art than science in some cases.  Since our models
to this point have been relatively simple I suspect that this train may
actually work.

> For validation of the code in the router

I suspect this is effectively where the tool chain would traditionally stop.
You've de-marshalled the intermediate form into something that recognizes
the structured data and can dump it directly into your code.  You might

> UML syntax 

UML in the middle to absorb it, but my suspicion is that a lot of existing
tools would prefer to either work on XML documents due to the related tools
like XPath.

> misunderstood the point for information models and data models. 

Just to clarify my own point for the list, my concern was mostly that a
sufficiently useful data modeling language obviates much of what the info
model gives us: Structure of the information and general typing.

What something like UML gives us that isn't necessarily a property of those
data modeling languages is the inter-relationship of objects.  UML is pretty
good at that.  My only concern about graphical UML, having done a few pretty
pictures for similar info systems is that they get *big*, and splitting
those across the IETF-publishable formats may be messy.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Apr 2014 22:04:04 +0200

> one point of a BER format for YANG, but my google-fu is failing me.)

As long as you do crypto in software, the outcome of the binary
vs. textual data encoding discussion likely does not matter much. Note
that for NC all standards-track transports do authentication and
encryption above the transport layer (via SSH or optionally TLS). For
RC it is likely going to be TLS. For ForCES, it seems RFC 5811 (ForCES
over SCTP) requires IPsec in transport mode plus IKE.

Perhaps all boxes that are targets for I2RS can be assumed to have
hardware crypto and hence this is a non-issue. But I think it is
important to keep the bigger picture in mind when we talk about
performance (and I assume I2RS will not pass through the IESG with a
plaintext transport mode).

/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: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Apr 2014 16:11:33 -0400

Juergen,

> > one point of a BER format for YANG, but my google-fu is failing me.)
[...]
> plaintext transport mode).

Not speaking for the chairs, I'd hope the WG would consider this blatantly
against what we're hoping to do.  The goal of the WG is to help make routing
system information more available.  Requiring new hardware to implement our
proposals goes counter to that idea, IMO. :-)

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 14:44:28 -0700

Hi,

> So lets put all that in a requirement list somewhere and work around a gap
So how does ForCES support these things?
Where is the language specification in RFC 5812?
Section 4 describes LFB classes, which appear to represent the only
supported data
for the protocol. Is the entire normative language specification contained
in the XSD in sec. 4.9?

What happens if multiple <load> elements pull in definitions with the
same local name?  The examples do not show any use of prefixes
and the <load> element has no prefix mapping.

   <load library="a_library"/>
   <load library="another_library" location="another_lib.xml"/>
   <load library="yetanother_library"
    location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/>

There does not appear to be any conformance information like what is
mandatory or conditional on a user-defined feature. How are logical groups
of conditional objects defined and advertised in the protocol? (e.g., YANG
features)

Are there examples of the augmentation described in sec. 4.5.7?
There does not appear to be any way for 1 module to add elements to another
<dataTypeDef> without controlling the naming for all modules.

How does a vendor implement the unique naming requirements in ForCES
without controlling the names of all possible ForCES files?  Are they
supposed to
rewrite modules when a naming collision occurs because modules X and Y are
being loaded
into module Z, which causes a new naming collision that did not occur
before?

YANG supports groupings that can be refined in each use/expansion.
How are complex <dataTypeDef> statements reused and refined?
Where are examples of that in the RFC?

How would I2RS use <frameDefs>?

    <frameDefs>
     <frameDef>
      <name>ipv4</name>
      <synopsis>IPv4 packet</synopsis>
      <description>
       This frame type refers to an IPv4 packet.
     </description>
    </frameDef>
     <frameDef>
     <name>ipv6</name>
     <synopsis>IPv6 packet</synopsis>
     <description>
       This frame type refers to an IPv6 packet.
     </description>
    </frameDef>
     ...
   </frameDefs>

Is this like a YANG identity statement, except this causes naming
collisions,
so it is more like a specialized distributed enumeration type?

To compare readability, here are the same type definitions in ForCES and
YANG:

ForCES: (RFC 5812, pg. 80)

              <dataTypeDef>
                  <name>accessPermissionValues</name>
                  <synopsis>
                    The possible values of component access permission
                  </synopsis>
                  <atomic>
                    <baseType>uchar</baseType>
                    <specialValues>
                      <specialValue value="0">
                        <name>None</name>
                        <synopsis>Access is prohibited</synopsis>
                      </specialValue>
                       <specialValue value="1">
                        <name> Read-Only </name>
                        <synopsis>
                          Access to the component is read only
                        </synopsis>
                      </specialValue>
                      <specialValue value="2">
                        <name>Write-Only</name>
                        <synopsis>
                          The component MAY be written, but not read
                        </synopsis>
                      </specialValue>
                      <specialValue value="3">
                        <name>Read-Write</name>
                        <synopsis>
                          The component MAY be read or written
                        </synopsis>
                      </specialValue>
                    </specialValues>
                  </atomic>
                </dataTypeDef>

YANG:

    typedef accessPermissionValues {

      description

        "The possible values of component access permission";

           type enumeration {

             enum None {

                value 0;

                description "Access is prohibited";

             }

             enum Read-Only {

                value 1;

                description "Access to the component is read only";

             }

             enum Write-Only {

                value 2;

                description "The component MAY be written, but not read";

             }

             enum Read-Write {

                value 3;

                description "The component MAY be read or written";

             }

           }

        }

How are new protocol operations defined? Are they part of the language.

How are language extensions done? This does not appear to be supported.

How are existence constraints between objects expressed? (e.g.,
must/when/unique)

How does a vendor add arbitrary data to notification events?
Can event definitions be augmented?
If so, how is this done so nodes can be conditional? (e.g., if-feature,
when)

The <eventCondition> element is one of many that seems very ForCES specific.
How are new events added?

I don't see an event definition for the "Goof1changed" example:

    </xsd:complexType>
      <!-- the substitution group for the event conditions -->
      <xsd:element name="eventCondition" abstract="true"/>
      <xsd:element name="eventCreated"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventDeleted"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventChanged"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventGreaterThan"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventLessThan"
                  substitutionGroup="eventCondition"/>
      <xsd:complexType name="eventPathType">
        <xsd:sequence>
          <xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
      <!-- the substitution group for the event path parts -->
      <xsd:element name="eventPathPart" type="xsd:string"
                   abstract="true"/>
      <xsd:element name="eventField" type="xsd:string"
                   substitutionGroup="eventPathPart"/>
      <xsd:element name="eventSubscript" type="xsd:string"
                   substitutionGroup="eventPathPart"/>
      <xsd:complexType name="eventReportsType">
        <xsd:sequence>
          <xsd:element name="eventReport" type="eventPathType"
                       maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:complexType>

  <event eventID="8">
      <name>Goof1changed</name>
      <synopsis>
          An example event for a complex structure
      </synopsis>
      <eventTarget>
        <!-- target is goo.f1 -->
        <eventField>goo</eventField>
        <eventField>f1</eventField>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <!-- report the new state of goo.f1 -->
        <eventReport>
        <eventField>goo</eventField>
        <eventField>f1</eventField>
        </eventReport>
      </eventReports>
    </event>

I am still confused about the <metadataDefs> general applicability.
E.g., how are <inputPorts>, <outputPorts> used in I2RS?

Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 21 Apr 2014 17:18:26 -0500

> On Apr 21, 2014, at 12:46 AM, "Jan Medved (jmedved)" <[email-masked]> wrote:
> 
> 
> 

This is the right approach. The speed up vs pita factor for binary encoding isn't worth it. And as you say, the CPU performance is so fast even today that it's not an issue.

> programming ;-) ) can be addressed with NC/RC/Y today.

I agree. I've always viewed what needs to be done as more or less a subset of what's in netconf today.

Tom

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 15:21:55 -0700

Hi,

Forgot life-cycle issues....
There does not appear to be any notion of a module revision in ForCES.
There does not seem to be any way to identify a particular definition
as either current, deprecated, or obsolete.

Is a library used with the <load> element ever allowed to change?
If so, how are new revisions identified?

Is there any text explaining how these modules are allowed to change over
time?
Was this considered by the WG?

Andy

On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman <[email-masked]> wrote:

> Hi,
>
>
> On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <[email-masked]>wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2014 15:42:28 -0700

On Mon, Apr 21, 2014 at 3:18 PM, Thomas Nadeau <[email-masked]>wrote:

> This is the right approach. The speed up vs pita factor for binary
> encoding isn't worth it. And as you say, the CPU performance is so fast
> even today that it's not an issue.
>
> >
> >
> >>
> >>> work, then back to the drawing board. Until things work, keep on
> >moving
I will try to be more specific here.

IMO:

  I2RS = (NC | RC) + YANG - datastore_validation - NV_storage +
owner_priority_ACM

My early implementation feedback (hope to be done before Toronto):
The message encoding has virtually no impact and it is not the bottleneck.
The new protocol stack screams, because distributed YANG validation and
NV-storage can be really expensive. The system's ability to activate changes
in the underlying firmware is the bottleneck in NC/RC, and that depends
on the implementation.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Apr 2014 23:48:08 -0400

As a minor point, I consider the embedding of file management and 
business logic into the core of NetConf was probably a mistake.
ForCES does have version numbers on classes, so if you change an LFB 
class definition, you increase the revision.
It also has inheritance, which provides an effective way to define a 
coherent extension of a class.
And it explicitly includes indications of which items are required.  As 
well as providing mechanisms for a controller to determine on a fine 
grained basis what an FE actually supports.  So we do not have to guess 
what the right groupings are for unknown users down the road.

Yours,
Joel

On 4/21/14, 6:21 PM, Andy Bierman wrote:
> Is there any text explaining how these modules are allowed to change
> over time?
> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>
>     On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >
>     for the protocol. Is the entire normative language specification
>     contained in the XSD in sec. 4.9?
>
>     of conditional objects defined and advertised in the protocol?
>     (e.g., YANG features)
>
>     without controlling the names of all possible ForCES files?  Are
>     they supposed to
>     rewrite modules when a naming collision occurs because modules X and
>     Y are being loaded
>     into module Z, which causes a new naming collision that did not
>     occur before?
>
>     To compare readability, here are the same type definitions in ForCES
>     and YANG:
>
>     If so, how is this done so nodes can be conditional? (e.g.,
>     if-feature, when)
>

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 21 Apr 2014 22:26:58 -0700

It would be good to have an empirical performance analysis of Netconf vs FORCES; this would substantiate performance advantages, if any, of either protocol. The following reference provides a reasonable empirical performance analysis of Netconf vs SNMP - http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf.

Thanks,
Ramki

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, April 21, 2014 8:48 PM
To: Andy Bierman; Jamal Hadi Salim
Cc: Russ White; [email-masked]; Jan Medved (jmedved); Dean Bogdanovic; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

As a minor point, I consider the embedding of file management and business logic into the core of NetConf was probably a mistake.
ForCES does have version numbers on classes, so if you change an LFB class definition, you increase the revision.
It also has inheritance, which provides an effective way to define a coherent extension of a class.
And it explicitly includes indications of which items are required.  As well as providing mechanisms for a controller to determine on a fine grained basis what an FE actually supports.  So we do not have to guess what the right groupings are for unknown users down the road.

Yours,
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Apr 2014 09:06:09 +0200 (CEST)

Jeffrey Haas <[email-masked]> wrote:
> that it can be a bit more art than science in some cases.

Also note that UML is more abstract, and doesn't necessarily have the
ability to express details that are actually needed in the data
model.  So in general it is not possible to generate the data model
from UML.  (of course, you might be able to generate a stub data model
which you manually tweak).

I agree that UML is a better choice for the information model than
ABNF.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Apr 2014 09:19:56 +0200

On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote:

> It would be good to have an empirical performance analysis of
> Netconf vs FORCES; this would substantiate performance advantages,
> if any, of either protocol. The following reference provides a
> reasonable empirical performance analysis of Netconf vs SNMP -
> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf.

I believe this comparison is flawed. ncclient uses a pure Python
implementation of SSH while the authors used a Python wrapper around
NET-SNMP (a C implementation) to measure SNMP performance. And the
authors state that they used SNMPv2c (no security) and SSH as the
NETCONF transport. (It is also unclear whether all NETCONF
transactions were executed over a single session or multiple
sessions.)

The design of such experiments is not as easy as it may look at first
glance and it is in particular important to use comparable security
algorithms (ideally the same crypto library).

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Apr 2014 13:43:35 +0200

Dear all,

I've been spending the last 2 hours reading that full email thread, up 
to this time.
Not sure to which email I should reply, so here am I, top posting.

+ 1 on YANG for the data model language.
What counts at the end of the day is a consistent data model language 
for configuration, because implementing a proxy for different data model 
languages is a pain, time consuming, and error-prone.
Ideally, we should have a consistent information model language, but the 
industry/standards are not there yet. Not even sure they will even 
arrive there one day.

Looking at the life cycling of specifying a new language, implementing 
it, deploying it, and developing tools around it (I have SMI and YANG in 
mind), having a new data model language for I2RS only is not practical. 
And the more we wait, the more obvious the solution is.
I know, it's not about a technical argument any longer (those have been 
made on the lits already).
Let's look at the WG deliverables:
Jul 2013 	
Request publication of an Informational document defining the problem 
statement
Jul 2013 	
Request publication of an Informational document defining the high-level 
architecture
Aug 2013 	
Request publication of Informational documents describing use cases
Sep 2013 	
Request publication of an Informational document defining the protocol 
requirements
Sep 2013 	
Request publication of an Informational document defining encoding 
language requirements
Feb 2014 	
Request publication of Standards Track documents specifying information 
models
Feb 2014 	
Request publication of an Informational document providing an analysis 
of existing IETF and other protocols and encoding languages against the 
requirements
Feb 2014 	
Consider re-chartering

The least we can say is that the WG is late.
I observe that after 1 year and 3 months after the WG creation, we still 
don't have the problem statement/architecture/requirements: that  
explains, whether we like it or not, why the  business reasons are 
getting more and more important compared to the technical arguments.
Didn't we see a few comments lately about the IETF not being relevant 
because we're too slow?
Maybe the IESG should be stricter: "no problem statement with a year, WG 
closed", but I guess I'm diverging :-)

Once YANG is selected, NETCONF/RESTCONF for the protocol is the next 
logical step, even if I believe that in practice, we'll see different 
devices speaking different languages.

Regards,  Benoit (as a contributor)

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 22 Apr 2014 09:21:14 -0400

>
> It may not be the primary deciding criterion but it will

Do you see a whole BGP table (or larger) being injected/dumped via I2RS?

>  but I'm happy to provide wiki space for these things to be enumerated.
>

That would be nice.

> valid once you have the whole document.  Thus, document size may matter.

I think the parsing technique used for XML may help (DOM vs SAX); XML gurus
can comment.
I have very strong doubts about the 3-5% number stated - but hopefully
we can settle
that with real numbers.  Let me try to handwave (not sure if this is
wiki material):

On compute:
I would expect json to perform better than XML when sending to a browser.
In particular given that  json is a native format to javascript (but
also heard of
some decent C/python parsers). If you extended that thought to binary data
it will likely perform better than json to an I2RS agent because
it is closer to the native format of the I2RS agent ( a lot less
translation needed).
String processing may be alleviated with newer instruction sets that
processor vendors are putting out (glibc uses some of the SSE
instructions on x864 when
available to do things like strcmp) - but that still will not give you
the 3-5% difference
claimed. There's also a bunch of vendors who would sell you xml or
string processing
offload. But i wouldnt call that commodity or depend on that when
defining wire format.

On extensibility:
One could argue that the XML definition would be more extensible than
json i.e if you
want to be close to native format you pay in reduced extensibility. So
if I2RS cared more
about extensibility json would not be a good choice.
In ForCES we chose to define things in XML to allow for the
extensibility; so from that
perspective we are closer to XML. The ForCES XML schema/language
allows  defining things
as close as possible to native format.
On the wire we take the xml definition and convert it to binary and
from that perspective
we are closer to json.

On wire performance:
Should be noted that it is not just about compute resources, but also
network resources.
If i send 1000 RIB components in ascii (doesnt matter whether it is
json or xml) vs
the same amount in binary; i would expect the wire resources to be
several magnitudes
better with binary. It will also be a lot closer to native format the
RIB manager
uses. Same with sending XML vs json to a browser - json is a native
format to javascript
and a lot more compact, therefore will perform better.
Wire performance can be improved by the classical technique of using compression
on the wire. That adds cost to the cost of compute.

> also providing I2RS extensions for configuration, monitoring, etc.

Lets pick a few use cases that makes sense to I2RS and go with that from
an analysis pov. Tom Petch was probably right in saying we needed to start with
use cases. I dont want to sell ForCES features that have no meaning for I2RS.

> your access to everything is always via strict API, binary encoding a great.

This is the modus operandi for what we do today. It allows us to hide
whats underneath. The user really has no business knowing we are running
ForCES underneath.

> do a lot of things.

This is true. The cost may be extensibility as i said above.
Note: most of the time the arguement ive heard for ascii is it is
useful for the operator
for debugging - which clearly not true considering the wire format is always
encrypted. This may have been true for smtp or early days of http - but clearly
not true for the domain we are talking about.

>I suspect I'm not the only one that uses text-based

I am juggling that in my head and not seeing going ascii from binary.
(I guess given my reading of your context above i am seeing base64
encoding of binary data ;->).
You probably mean something else

> (Just to pick one from my reading.)

If you are talking about the API, it is closer to what http does (restful,
few verbs and many nouns which would be close to URIs). Think of a restful
binary setup. Something restful like http would be sufficient to describe it.

Section 4.5 defines the schema i.e how one would define/model the
resources (eg RIB).
The API is what the protocol provides the few verbs to act on resources/nouns.
So an API call is of the form:
Verb <resource noun> [optional data]
Bringing the comparison to http again:
a ForCES SET would be equivalent to http POST/PUT/PATCH etc.
There are some CRUD semantics like append/exclusivity etc that were
discussed but missing from the protocol.
I gave a high level view at the SDNRG WG in ietf86. Also my gap analysis
summarizes some things. Evangelos is planning to give webinars/tutorial
that people wanting to get familiar with ForCES could attend.

> needs in somewhat greater depth than the existing gap analysis.

So my take on this is:
Lets have the informational description of what I2RS needs - perhaps
by going over
use cases. It is easy to provide the ForCES view of those model.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 22 Apr 2014 09:59:09 -0400

Sorry Andy - trying to catchup with the threads (and busy elsewhere at
the moment)
so fast forwarding to this email. I will try to come back later and answer each
of your questions probably in a separate email
To provide an example to what Joel said:
You can augment/extend in two ways.
a) Take an existing LFB - keep the name change the class version.
Take an existing data structure within that class and extend it.
Example (straight out of our regression tests, simplified for clarity):

struct foobartype {
  id 1, foo, uint32;
  id 2, bar, uint32;
}

class MyUpgrade id 667
{
  version 1.0
  components {
    id 1, cbogtabl, array of foobartype;
  }

  events {
    id 1, CBogChanged ... reports  cbogtable changes with row
 }
}

And later you decide you want to add some new field to foobartype.

struct foobartype {
  id 1, foo, uint32;
  id 2, bar, uint32;
  id 3, goo, uint32;
}

class MyUpgrade id 667
{
  version 1.1
  components {
    id 1, cbogtable, array of foobartype;
  }
  events {
    id 1, CBogChanged ... reports table changes with new foobartype
 }
}

In field upgrades, typically i see that the  control piece is first upgraded.
The data path follows next incrementally on different nodes.
The datapath ignores and logs what it doesnt understand. i.e in such a case,
an app sends cbogtable row with goo to version 1 datapath.

On inheritance, here's an example of what a linux port would look like:

struct portinfo {
  id 1, name, string[16]
  id 2, ifindex, uint32
  ..
  ..
  id 23, ethinfo, struct ethparams
}

class Port, id 6113
{
 version 1.0
 components {
    id 1, ports, array of portinfo;
  }
  events {
   ... link, port creation etc ..
  }
 capabilities {
   .........
 }
}

So if i wanted to define a tunnel device, then i take that
portinfo struct and derive from it then i create a new class.
As an example for tuntap port on Linux:

struct tunport {
  <derivedFrom>PortInfo</derivedFrom>
  id 24,tunflags, uint32, optional
  id 25, userid, uint32, optional
  id 26, groupid, uint32, optiona
 }

class tuntap, id 6119
{
 version 1.0
 <derivedFrom>Port</derivedFrom>
 components {
    id 1, ports, array of tunport;
  }
  events {
   ... link, port creation etc ..
  }
 capabilities {
   .........
 }
}

The XML is reduced greatly.

Not sure if i answered the specific question

I will respond to your other questions later..

cheers,
jamal

On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern <[email-masked]> wrote:
> As a minor point, I consider the embedding of file management and business
> logic into the core of NetConf was probably a mistake.
> And it explicitly includes indications of which items are required.  As well
> as providing mechanisms for a controller to determine on a fine grained
> basis what an FE actually supports.  So we do not have to guess what the
> right groupings are for unknown users down the road.
>
> Yours,
> Joel
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 22 Apr 2014 10:19:12 -0400

So I understand the practical implication of a WG being behind schedule
and by no means do i want to contribute to that.
One approach that Tom Petch had suggested is to focus on use cases.
The idea of what model/protocol is used can be going on in parallel. Input
from the use cases is useful to help define what protocol model used.

cheers,
jamal

On Tue, Apr 22, 2014 at 7:43 AM, Benoit Claise <[email-masked]> wrote:

>  Dear all,
>
> I've been spending the last 2 hours reading that full email thread, up to
> this time.
> What counts at the end of the day is a consistent data model language for
> configuration, because implementing a proxy for different data model
> industry/standards are not there yet. Not even sure they will even arrive
> there one day.
>
> Looking at the life cycling of specifying a new language, implementing it,
> deploying it, and developing tools around it (I have SMI and YANG in mind),
> having a new data model language for I2RS only is not practical. And the
> more we wait, the more obvious the solution is.
> Request publication of an Informational document providing an analysis of
> existing IETF and other protocols and encoding languages against the
> requirements
>   Feb 2014
> Consider re-chartering
>
> don't have the problem statement/architecture/requirements: that  explains,
> whether we like it or not, why the  business reasons are getting more and
> more important compared to the technical arguments.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2014 07:23:58 -0700

> Example (straight out of our regression tests, simplified for clarity):
I will try to relate this back to the RFC.
The real syntax is XML and does not look anything like your examples.
(If XML was that readable, perhaps you would use the real syntax).

I do not understand the conformance model.  Does the server claim
conformance to a set of { class, version } tuples? How does the
client know what versions to expect?

ForCES is not really extensible if multiple vendors are defining data
because
there is 1 giant flat namespace so all data naming has to globally
coordinated, or naming collisions can occur:

mod1:

   container foo { }

mod2:

   augment /mod1:foo {
      leaf X { type string }
   }

mod3:

   augment /mod1:foo {
      leaf X { type string }
   }

This is not an error in YANG.
It can't be because mod2 and mod3 are from 2 different vendors
and they both want to augment the standard module (mod1).
Clients that use /mod1:foo/mod2:X do not collide with clients
that are using /mod1:foo/mod3:X.

Without namespaces, even vendor modules would need to go
through a central naming authority like IANA.

Andy

struct foobartype {
> well

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 22 Apr 2014 10:28:13 -0400

Since ForCES name space is per-lfb-class.  So that the collision problem 
is mostly in the naming of the lfb classes.  (Some care is needed in the 
naming of data types and such, but it is pretty easy to do that in a 
colission avoiding fashion.  The harder problem, which applies equally 
to NetConf and ForCES, is to know when you can reuse an existing 
definition and when you need your own.)

Note that the protocol on the wire does not use the names at all, but 
only the assigned identifiers.  Which are registered precisely to avoid 
collision.

Yours,
Joel

On 4/22/14, 10:23 AM, Andy Bierman wrote:
>
>
>
> On Tue, Apr 22, 2014 at 6:59 AM, Jamal Hadi Salim <[email-masked]
>     On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > ForCES does have version numbers on classes, so if you change an
>     LFB class
>      > definition, you increase the revision.
>      >> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman
>     <[email-masked] <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >>     Hi,
>      >>
>      >>
>      >>     On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim
>     <[email-masked] <mailto:[email-masked]>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >>         <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>          >
>      >>          > I think Jan and others have explained why they think
>     they can
>      >>         leverage
>      >>          > variation on every router, then issues such as
>     modularity,
>      >>         conformance
>      >>         So lets put all that in a requirement list somewhere and
>     work
>      >>         around a gap
>      >>         analysis.
>      >>
>      >>
>      >>     mandatory or conditional on a user-defined feature. How are
>     logical
>      >>     groups
>      >>     There does not appear to be any way for 1 module to add
>     elements to
>      >>     another
>      >>                      description "The component MAY be written,
>     but not
>      >> read";
>      >>
>      >>
>      >>                   }
>      >>
>      >>                   enum Read-Write {
>      >>
>      >>                      value 3;
>      >>
>      >>
>      >>     The <eventCondition> element is one of many that seems very
>     ForCES
>      >>     specific.

---

From: ramki Krishnan <[email-masked]>
Date: Tue, 22 Apr 2014 07:30:42 -0700

My point is that it is good to have an empirical performance comparison (which would mean everything is apple-to-apple including setup, use case etc.) between Netconf and FORCES given that both the protocols have been in existence for a while. 

I agree that there may be some flaws in this particular comparison between SNMP and Netconf. I couldn't find anything else which is easily publicly available; if you have any better publicly available reference, please suggest.

Thanks,
Ramki

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2014 7:15 AM
To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman; Jamal Hadi Salim; Russ White; [email-masked]; Jan Medved (jmedved); Dean Bogdanovic; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

I see a different flaw just from the first few pages and looking at the conclusion.
Sorry - didnt have time to look at the whole thing.
The paper picks a model entity of about 90% strings (theres one "int" iirc).
I am not sure what that was supposed to emulate. From that perspective the question answered to me seems to be "how bad does SNMP do when you have mostly strings?". It seemed to do fairly well at the end. I liked the fact they tried to batch things with SNMP.
If i was emulating what I2RS is doing by building on say the RIB model, it will not be 90% ascii on the wire for SNMP.

Agree with Juergen on apple-apple comparison needed.

cheers,
jamal

On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>> It would be good to have an empirical performance analysis of Netconf 
>> vs FORCES; this would substantiate performance advantages, if any, of 
>> either protocol. The following reference provides a reasonable 
>> empirical performance analysis of Netconf vs SNMP -

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2014 07:44:44 -0700

On Tue, Apr 22, 2014 at 7:30 AM, ramki Krishnan <[email-masked]> wrote:

> My point is that it is good to have an empirical performance comparison
> (which would mean everything is apple-to-apple including setup, use case
> etc.) between Netconf and FORCES given that both the protocols have been in
> existence for a while.
>
>
It would be good to have a pointer to implementations, open-source tools,
tutorials, etc.

The NETCONF WG maintains a wiki to help provide this information:
http://trac.tools.ietf.org/wg/netconf/trac/wiki

Benoit asked at the London meeting, "where is this list for ForCES?"
We still have not heard an answer.

I agree that there may be some flaws in this particular comparison between
> SNMP and Netconf. I couldn't find anything else which is easily publicly
> available; if you have any better publicly available reference, please
> suggest.
>
> Thanks,
> Ramki
>
>

Andy

> To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman;
> Jamal Hadi Salim; Russ White; [email-masked]; Jan Medved (jmedved); Dean
> Bogdanovic; Edward Crabbe
> I am not sure what that was supposed to emulate. From that perspective the
> question answered to me seems to be "how bad does SNMP do when you have
> mostly strings?". It seemed to do fairly well at the end. I liked the fact
> they tried to batch things with SNMP.
> If i was emulating what I2RS is doing by building on say the RIB model, it
> will not be 90% ascii on the wire for SNMP.
>
> On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Apr 2014 11:08:29 -0400

Jamal,

> Do you see a whole BGP table (or larger) being injected/dumped via I2RS?

I can definitely see such a case, although the more likely paradigm is
injecting a large number of RIB entries that may have some BGP properties,
such as communities or inputs to various BGP-like policy mechanisms.

> >  but I'm happy to provide wiki space for these things to be enumerated.

I have created stubs in the wiki for such comparisons.  Would you mind
starting the work for FORCES?

http://wiki.tools.ietf.org/wg/i2rs/trac/wiki

You will require a datatracker login.  If you run into issues with editing,
please unicast me.  This is the first time I'll have done more than editing
it myself.

If someone is willing to start stubbing in similar items for Netconf/Yang,
that would be helpful.

> I would expect json to perform better than XML when sending to a browser.

While I think that detail is true, I suspect a browser is not the first
order consumer of the information.

> it is closer to the native format of the I2RS agent ( a lot less

My general experience with such things is that JSON does fine when you want
to pass around JavaScript native data, but that you lose some of the
semantic layering in turning things into JavaScript.  My personal preference
would be that if we provide JSON layers that they effectively be at the far
end of the pipe (UI facing) rather than the native object in-protocol.

Obviously such details are discussion points and the above is simply my
opinion and experience.

> offload. But i wouldnt call that commodity or depend on that when

While certainly not a constraint on the working group, I tend to remember
that we want I2RS to be as pervasive as possible.  This means that anything
we can make work well on older platforms means it's more likely to be
supported across a wide range of devices.  This has impact, for example, on
crypto load.

[Several other good points that should be in the wiki entry elided.]

> on the wire. That adds cost to the cost of compute.

I think I made this observation at the last IETF session: Even for simple
compression, XML tends to compress *very* nicely with small dictionaries.
Since HTTP compression is well deployed, I suspect this isn't quite as big a
deal as it could be.  Of course, that presumes we're layering on top of
something HTTP-like.

> not true for the domain we are talking about.

It's pretty common to either tap before or after the transport APIs for
debugging.  I think the distintion is that in something text-like you can
tap and do thinks potentially simpler than if you have to look at binary
PDUs.  That requires tapping one level back before the binary marshalling
layer.  Obviously that is doable as well, but simply moves the point of
complexity one layer up/down.

> I am juggling that in my head and not seeing going ascii from binary.

To offer a somewhat BGP network operations example, those who use the MRT
file format (RFC 6396) typically have programs that convert from/to that
format in human-readable form.  Some users may use binary API to interact
with the files but the majority of operators I've interacted with that use
it tend to simply transform it to ASCII and Do Something Clever using their
favorite scripting language.

> use cases. It is easy to provide the ForCES view of those model.

I've left a stub in the wiki for helping to derive or map requirements.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Apr 2014 11:19:10 -0400

Joel,

On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote:
> Since ForCES name space is per-lfb-class.  So that the collision
> problem is mostly in the naming of the lfb classes.  (Some care is
> needed in the naming of data types and such, but it is pretty easy
> to do that in a colission avoiding fashion.  The harder problem,
> which applies equally to NetConf and ForCES, is to know when you can
> reuse an existing definition and when you need your own.)

I'm still working my way through my FORCES reading.  It would be very
helpful to see an example of this.

To offer an example from netconf that I commented upon at various WG
sessions, a RIB entry will tend to consist of things that are common across
implementations (prefix, nexthop[s], source protocol) and may be augmented
by either protocol-specific components (AS_PATH, communities for BGP; metric
for IGP) or vendor-specific ones (weight, administrative distance, etc.)

In YANG, this is mostly a matter of just decorating with additional XML
elements around the core objects.  (I'm over-generalizing.)

How does one do this in FORCES?

> Note that the protocol on the wire does not use the names at all,
> but only the assigned identifiers.  Which are registered precisely
> to avoid collision.

One of my lesser concerns here is that code point registries provide another
pivot for coordinating development work, in or out of IETF.  Arguably, XML
token names have the same sort of issue to some extent, but tend not to be
"last code point +1".

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Apr 2014 11:23:09 -0400

Benoit,

> The least we can say is that the WG is late.

Indeed. :-)

> I observe that after 1 year and 3 months after the WG creation, we
> still don't have the problem statement/architecture/requirements:

I've been told that we should see an update to the architecture and problem
statement soon.  The intention is to push for final review in WGLC to get
that work completed.

The requirements are, in many cases, covered in the various use case
documents.  Sue has volunteered to try to excerpt the common requirements
from the documents she's shepherding to derive a common requirements set.

A space has been set aside on the WG wiki for this.  Please feel free to
help populate it:
http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/UseCaseRequirementsEnumeration

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Apr 2014 11:42:05 -0400

As with most modeling work, there are several ways to extend the base 
models.  Figuring out which one is right, and designing for 
extensibility is important no matter what the language is.

So, for the RIB, clearly it starts with a base RIB entry definition with 
the common stuff.
The challenge with extensions is whether there are a number of 
orthogonal things we want, or a set of components that we want to be 
able to use.

To pick the hardest case, lets suppose that we use a RIB table LFB which 
uses a RIB datatype.  If we can coordinate, the easiest thing is to 
assign an ID in the RIB structure for each substructure as you add it. 
One way or another, in order to have binary names for these, we have to 
achieve that.  The subclassing mechanism supports this easily.

For alternatives, we do have unions.  But I think that is a more narrow 
case and not as useful.

One can also define various components as freestanding LFB classes, and 
include aliases to reference them.  That is even more flexible, and 
requires less coordination.  But it is more opaque as a model.
To do this, would would define in the base RIB entry a table of 
"extension points" which are aliases to an LFB class which inherits from 
a base LFB extension LFB.  You can then reference any instances of any 
subclass of that.  Arbitrarily flexible, but quite confusing.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2014 08:46:40 -0700

> helpful to see an example of this.

Isn't "knowing when you can reuse an existing definition"
just a tooling issue (e.g., searchable library of existing definitions)?
YANG is designed to be as readable by humans as possible because
usually humans need to understand the data model.

> token names have the same sort of issue to some extent, but tend not to be

Who assigns code points? IANA?
IMO it is really useful to have distributed naming authority, so
vendors do not need to register every data node as a new code point
with IANA.

The experience in NETCONF has been that human friendly identifiers like
"/interfaces/interface/name" are far easier to work with than OIDs like
1.3.6.1.2.1.31.1.1.1.1
I think EXI encoding would be almost as efficient as a native binary
encoding for NETCONF
and HTTP compression should be about the same for RESTCONF.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Apr 2014 11:52:11 -0400

I wish that knowing when you can reuse definitions was just a matter of 
searchable libraries.
Unfortunately, until human readable documentation is consistently 
better, it is still a challenge when looking at these things to tell 
what they really are for and whether they cover what you want.

Yes, tooling, documentation, and search support all help.
And maybe it will be easier than I expect.

In any case, i don't think this is a difference between the choices.

Yours,
Joel

On 4/22/14, 11:46 AM, Andy Bierman wrote:
...
...

---

From: Robert Varga <[email-masked]>
Date: Tue, 22 Apr 2014 18:18:23 +0200

> valid once you have the whole document.  Thus, document size may matter.

There is a draft for using EXI encoding in NETCONF. There is a (partial) 
implementation in OpenDaylight, so benchmarking should be possible. 
Sorry, don't have the cycles to actually design/run a reasonable test suite.

Bye,
Robert

---

From: "Palani Chinnakannan (pals)" <[email-masked]>
Date: Tue, 22 Apr 2014 18:57:35 +0000

Just an FYI.  Rex an I have a protocol buffer mapping to Yang RFC
proposal. 

pals

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 22 Apr 2014 19:32:08 -0500

> On Apr 22, 2014, at 6:43 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
> I've been spending the last 2 hours reading that full email thread, up to this time.
> What counts at the end of the day is a consistent data model language for configuration, because implementing a proxy for different data model languages is a pain, time consuming, and error-prone.
> Ideally, we should have a consistent information model language, but the industry/standards are not there yet. Not even sure they will even arrive there one day.
> 
> Looking at the life cycling of specifying a new language, implementing it, deploying it, and developing tools around it (I have SMI and YANG in mind), having a new data model language for I2RS only is not practical. And the more we wait, the more obvious the solution is.
> I know, it's not about a technical argument any longer (those have been made on the lits already).
> Request publication of an Informational document defining the problem statement
> Jul 2013	
> Request publication of an Informational document defining the high-level architecture
> Aug 2013	
> Request publication of an Informational document defining the protocol requirements
> Sep 2013	
> Request publication of an Informational document defining encoding language requirements
> Feb 2014	
> Request publication of Standards Track documents specifying information models
> Feb 2014	
> Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements
> Feb 2014	
> Consider re-chartering
> 
> I observe that after 1 year and 3 months after the WG creation, we still don't have the problem statement/architecture/requirements: that  explains, whether we like it or not, why the  business reasons are getting more and more important compared to the technical arguments.
> Didn't we see a few comments lately about the IETF not being relevant because we're too slow?
> Maybe the IESG should be stricter: "no problem statement with a year, WG closed", but I guess I'm diverging :-)
> 
> Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logical step, even if I believe that in practice, we'll see different devices speaking different languages.
> 

I am with you in the "move forward or shut this train down" sentiment. Really how long does it take to decide in a modeling language - esp when the ietf has one that is perfectly suitable?

Tom

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 22 Apr 2014 20:36:01 -0400

Andy:

Catching up.  A few questions: 

1)      Why do you think that only the RIB matters in the long run (Short
run = RIB + BGP)

2)      Your modeling questions are important .. so let me ask a
meta-question and then go a level deeper. 

Why does netmod never really publish an informational model? 

Here's a bunch of answers/question to you great modeling questino

a)      Yes.  Right now no Data types in  

This static set is likely to continually expand if it is used for I2RS, and
have vendor specific 

[Sue] Yes.  But we will talk a lot about what is high-level data model
constructs?  

          Do you consider next-hop as defined in the RIB a high-level? 

[Sue" If you mean, will vendors or specific end users need it?  I do not see
how we can go without it. 

 -Can vendors add data definitions that extend the standard definition? 

   [Sue]:  Answer yes to all.  Re-usable, modular, growing, vendor
extensible, user-defined. 

   Do not plan to break if add new, 

    [Sue]: Need the profiling variables that Yang is using 

              [Note: Forces has an equivalent to all of this] 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: Russ White
Cc: [email-masked]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan
Medved (jmedved); Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

Hi,

 

Can you explain how an off-line representation of the data model can be fast
or slow?

 

RESTCONF is a protocol.

 

 

:-)

Russ

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2014 17:45:37 -0700

> 1)      Why do you think that only the RIB matters in the long run (Short

Why do you think I said that?
I don't see anything special about I2RS at all.
Editing operational state would probably work the same for other data.

> meta-question and then go a level deeper...
>
>
>

NETMOD publishes YANG modules.
I suppose it is perceived an unnecessary.

Andy

> This static set is likely to continually expand if it is used for I2RS,
> and have vendor specific
>
>
>
> [Sue" If you mean, will vendors or specific end users need it?  I do not
> see how we can go without it.
>
>
>

>
> Sue
>
>
>
>
>
> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Saturday, April 19, 2014 1:46 PM
> *To:* Russ White
> *Cc:* [email-masked]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic;
> Jan Medved (jmedved); Joel M. Halpern

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Apr 2014 10:50:43 -0400

The list server choked - so I'm Pull off all copies except Andy and I2rs.
By the way, I agree with Jeff Haas and Adrian,RBNF == BAD for I2RS.  I hope
we can pull it soon. 

Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 10:42 AM
To: 'Andy Bierman'
Cc: [email-masked]'; 'Edward Crabbe'; 'Jamal Hadi Salim'; 'Dean Bogdanovic';
'Russ White'; 'Jan Medved (jmedved)'; 'Joel M. Halpern';
[email-masked]'; Alia Atlas ([email-masked]); Nitin Bahadur
([email-masked]); 'Jeffrey Haas'
Subject: RE: [i2rs] consensus on I2RS protocol and model

Andy:

I started using UML to do the information models because Adrian Farrel and
Alia Atlas encouraged it to replace RBNF.   I think that the yang/netconf
models are still mining the existing SNMP/Configuration structures. For new
development, I suspect UML may help us root out redundancy. Why?  Because I
think I've found lots of redundancy in the RIB_INFO model.  I've attached
slides that may convince you, and an alternate drafts.

I've assumed in the information model that yang models as defined below

  +--------+---------------------------+-----------+

  | Prefix | YANG module               | Reference |

  +--------+---------------------------+-----------+

  | if     | ietf-interfaces           | [YANG-IF
<http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IF> ]
|

  |        |                           |           |

  | ip     | ietf-ip                   | [YANG-IP
<http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IP> ]
|

  |        |                           |           |

  | rt     | ietf-routing              | [routing] |

 |        |                           |           |

 | v4ur   | ietf-ipv4-unicast-routing | [routing] |

  |        |                           |           |

  | v6ur   | ietf-ipv6-unicast-routing | [routing  |

  |        |                           |           |

  | yang   | ietf-yang-types           | [RFC6991
<http://tools.ietf.org/html/rfc6991> ] |

  |        |                           |           |

  | inet   | ietf-inet-types           | [RFC6991
<http://tools.ietf.org/html/rfc6991> ] |

  +--------+---------------------------+-----------+

I've attached a revision of the RIB-info-model draft that provides:

1)      Revised RIB Grammar in RBNF (section 6.1) 

2)      (section 6.2) Spot for the pdf graphic attached as
draf-thares-i2rs-info-rib-only-v7.pdf

3)      (section 6.3) Yang tree structure (per yang documents)

4)      Revised Usage - using simplified grammar

Basically the complex RBNF grammar boils down to very few simply statement.
The Yang Tree does not provide an easy way to design/debug redundancy. I
think that the use of the UML tools that create the Yang modules/Yang Tree
structures could speed time to market on the designs.  For example, all the
I2RS RIB is simply 5 power-point slides, that then can be generated into
Yang module.  This seems the normal progression of the process you started
with the Yang-modules. 

CAVEATS: 

1)      For all mistakes on the UML and diagrams blame me - this first pass
at UMLs, and it will need revising 

2)      Some of the redundancies could have been fixed in other ways 

3)      I did Yang modules to demonstrate proof of concept

4)      I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES
Data model can do the same 

Sue Hares  

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, April 22, 2014 8:46 PM
To: Susan Hares
Cc: [email-masked]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ
White; Jan Medved (jmedved); Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

<..snip>  

run = RIB + BGP) - 

[Andy] Why do you think I said that I don't see anything special about I2RS
at all. Editing operational state would probably work the same for other
data.

[Sue]: Agree! 

 NETMOD publishes YANG modules. I suppose it is perceived an unnecessary.

[Sue]: Other designers on lists stated they suggested they considered IM in
their design of YANG.  I think the graphical finds redundancies

<snip)  

Hi,

 

 

RESTCONF is a protocol.

 

 

:-)

Russ

Andy

---

From: t.petch <[email-masked]>
Date: Wed, 23 Apr 2014 17:07:51 +0100

YANG (with NETCONF) is designed for writing configuration and reading
everything else, and does an excellent job at it.  Trouble is, for me,
that configuration doesn't mean what I think of it as; it means, in the
YANG context, what you might put in through the CLI and it excludes
everything else, such as data learnt via a protocol.

Take routing.  A static route is configuration; anything learnt, via
BGP, IS-IS, RIP etc, is not configuration (and is read only).

An interface configured automatically on a hot-plugged card is not
configuration; adding 'ospf passive' is.

And so on, for DHCP, NTP, .....

In practice, this means that the YANG model comes in twin sets, one of
read-write configuration and one of read-only not-configuration (as can
be seen in the current I-Ds that the netmod WG is producing) with no
formal way in YANG of relating the one to the other.  So if you want
e.g. the routing table, the host software has to know where to look and
how to combine the pieces to produce a coherent picture (and then you
cannot edit most of it).

So if I2RS never wants to write anything to a router, YANG is fine; if
I2RS is only producing a Information Model (and ignoring whether or not
data is read-only or read-write), and not moving on to an
implementation, then YANG is fine.

Rather, as Andy Bierman said at IETF89, likely I2RS would need an
extension to YANG, a new sub-statement for all data objects, semantics
not too clear but designed to separate out the not-configuration, learnt
via a protocol, 'editable-state' (and in doing so, making it
read-write - but still 'config false').

Yes, YANG allows for such extensions but it seems to me that I2RS would
then be getting YANG++ (and NETCONF++), once the necessary work has been
done.

Tom Petch

----- Original Message -----
From: "Edward Crabbe" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 11, 2014 6:50 PM
Subject: [i2rs] consensus on I2RS protocol and model

adequate
changes
> contribute to this analysis.

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Apr 2014 12:21:54 -0400

Tom:

100% agree with your comments. I2RS cares whether it is read-only or
read-write.  My work toward the revision found:

- RBNF  RBNF did not even allow you a place to r/w or r-only or permissions
(needed for security, but that's my next draft).
- The yang tree I wrote was r-w for config, but did not express the ro-only
tree.  I wanted some feedback to figure out why I had 2 write 2 trees. 
 (your telling me it is a yang short-coming).
- UML seems to be able to handle read/write variants, and I'm looking to see
if graphical tools will help the developer. 

Not shown in the reduction: 
... And I started working on BGP, ISIS, RIP.. only to find some of these
issues you mention. DCHP and NTP.   Any suggestions or help would be
gratefully accepted. 
 
I will continue to try to get more details on Yang++ and ForCES to see how
many wheels fall off.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of t.petch
Sent: Wednesday, April 23, 2014 12:08 PM
To: Edward Crabbe; [email-masked]
Subject: Re: [i2rs] consensus on I2RS protocol and model

YANG (with NETCONF) is designed for writing configuration and reading
everything else, and does an excellent job at it.  Trouble is, for me, that
configuration doesn't mean what I think of it as; it means, in the YANG
context, what you might put in through the CLI and it excludes everything
else, such as data learnt via a protocol.

Take routing.  A static route is configuration; anything learnt, via BGP,
IS-IS, RIP etc, is not configuration (and is read only).

In practice, this means that the YANG model comes in twin sets, one of
read-write configuration and one of read-only not-configuration (as can be
seen in the current I-Ds that the netmod WG is producing) with no formal way
in YANG of relating the one to the other.  So if you want e.g. the routing
table, the host software has to know where to look and how to combine the
pieces to produce a coherent picture (and then you cannot edit most of it).

So if I2RS never wants to write anything to a router, YANG is fine; if I2RS
is only producing a Information Model (and ignoring whether or not data is
read-only or read-write), and not moving on to an implementation, then YANG
is fine.

Rather, as Andy Bierman said at IETF89, likely I2RS would need an extension
to YANG, a new sub-statement for all data objects, semantics not too clear
but designed to separate out the not-configuration, learnt via a protocol,
'editable-state' (and in doing so, making it read-write - but still 'config
false').

Yes, YANG allows for such extensions but it seems to me that I2RS would then
be getting YANG++ (and NETCONF++), once the necessary work has been done.

Tom Petch

----- Original Message -----
From: "Edward Crabbe" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 11, 2014 6:50 PM
Subject: [i2rs] consensus on I2RS protocol and model

adequate
changes

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2014 09:59:55 -0700

> then be getting YANG++ (and NETCONF++), once the necessary work has been

So far, 2 extensions have been identified that are needed by I2RS.

1) identification of editable operational state.
    The config=false property in YANG will cause NETCONF and RESTCONF
    to (correctly) treat operational state as read-only. I2RS servers must
    implement the extension: The I2RS protocol will use its own access
control
    model on this data. NACM is not required.

   e.g. (not real data, just example!)

   extension edit-data {
       description
          "If this statement is present, and the parent statement represents
           a non-configuration data node, then instances of this data node
           can be modified by a client.";
   }

   container rib {
      config false;
      i2rs:edit-data;
      ....
   }

2) identification of objects associated with event notifications

This could also be done with a YANG extension, and there is a proposal
to change YANG 1.1 to support this feature:

   extension event-object {
     description
          "If this statement is present, and the parent statement is
           a notification statement, then the 'path' argument represents
           the resource associated with the notification.";
     argument path;
   }

   notification some-interface-event {
      i2rs:event-object /if:interfaces/if:interface;

      leaf name {
         type leafref { path /if:interfaces/if:interface/if:name; }
      }
      leaf some-data { type string; }
      ....
   }

Nobody said YANG or ForCES could be used without any modifications
to support I2RS.  YANG allows instant modifications that require no
changes to the language specification.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Apr 2014 19:08:51 +0200 (CEST)

> everything else, such as data learnt via a protocol.

This is true, but more for NETCONF than for YANG.  I think it has been
clear from the start that I2RS probably needs some (hopefully minor)
extensions to NETCONF and/or YANG, should we choose to use these
technologies.

Also, I think it has been pretty clear that what is missing is a way
to identify writable data that is not configuration (in the
NETCONF/YANG sense).

> be seen in the current I-Ds that the netmod WG is producing)

Correct.  This reflects how it usually works on devices; most routers
and similar equipment has a "config mode CLI" and "show commands"; a
linux box has config files and various ways of reading and writing
operational state (/proc, direct apis...)  These are different
structures with different syntax and semantics.

(SNMP tried to combine the two into one, but this turned out to be
problematic.)

> with no

You can call it YANG++ and NETCONF++, but the fact is that these
things can be done today, without having to revise the YANG or NETCONF
specs, by using the current extensibility mechanisms.

/martin

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 23 Apr 2014 18:20:27 +0000

Martin et alii,

The suggested protocol for i2rs is RESTCONF. Let me put quickly pros and cons for RESTCONF with few use cases.

Although there are many similarities between those two protocols, there are differences. Biggest negative for both, RESTCONF and NETCONF is lack of possibility to modify operational state of the device. 

Cons:
No network locking model
Can’t modify operational state of network device
Using JSON only simple meta-data is supported

Pros:
Unified data store
Provides atomicity of transaction
Simplified defaults handling
Allows multiple edits (with PATCH) within single message
Providing abstracted simplified config model
Supports XML and JSON
Streaming via Server-Sent-Events
Edit collision detection

I2RS clearly needs capability to modify operational state of the device. With unified data store that should be easier to achieve for RESTCONF then NETCONF, where multiple data stores are supported.
I envision that only transient changes are configured via RESTCONF. Any persistent changes IMO, should go via NETCONF. 
Does the WG see a need for i2rs to provide mechanism for persistent changes?

Following 3, I view very connected, simplified defaults handling, atomicity of transaction and abstracted simplified config model. With simplified configuration models, we can create 
With RESTCONF we want to ensure that a single transaction is making a meaningful request that can be fulfilled. This means that request can be either fulfilled or the transaction will fail. The simplified defaults handling makes the process easier. In case of writing, if not all the parameters are provided and there are no default arguments for the missing parameter, transaction will fail.

For the performance reasons, support for PATCH is very good, as it allows multiple updates in single transaction. It is not the same to send 1000 transactions to update 1000 routes or 1000 routes are updated in single transaction. With this capability clients can execute much faster changes to the system.

Lacking support for network locking model is an issue if there is a service activated across multiple devices via i2rs and in case of an error on one device, client has to be able to clean up on the other devices. Is this a viable use case that would prevent use of RESTCONF for i2rs?

Dean

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2014 12:54:44 -0700

On Wed, Apr 23, 2014 at 11:20 AM, Dean Bogdanovic <[email-masked]> wrote:

> Although there are many similarities between those two protocols, there
> are differences. Biggest negative for both, RESTCONF and NETCONF is lack of
> possibility to modify operational state of the device.
>
> Cons:
> No network locking model
> Can't modify operational state of network device
> I2RS clearly needs capability to modify operational state of the device.
> With unified data store that should be easier to achieve for RESTCONF then
> NETCONF, where multiple data stores are supported.
> I envision that only transient changes are configured via RESTCONF. Any
> persistent changes IMO, should go via NETCONF.
> Following 3, I view very connected, simplified defaults handling,
> atomicity of transaction and abstracted simplified config model. With
> simplified configuration models, we can create
> With RESTCONF we want to ensure that a single transaction is making a
> meaningful request that can be fulfilled. This means that request can be
> either fulfilled or the transaction will fail. The simplified defaults
> handling makes the process easier. In case of writing, if not all the
> parameters are provided and there are no default arguments for the missing
> parameter, transaction will fail.
>
> For the performance reasons, support for PATCH is very good, as it allows
> multiple updates in single transaction. It is not the same to send 1000
> transactions to update 1000 routes or 1000 routes are updated in single
> transaction. With this capability clients can execute much faster changes
> to the system.
>
>

I agree the RESTCONF session-less approach is better is the client does not
need
to change things very often, or changes can be done in bulk.

That may not be the case, for example, if the client is really a broker
coordinating lots of I2RS applications, so it is sending very frequently.
Then the session-based NETCONF approach might work better.
If the cost of authentication is high, RESTCONF would probably be slower
than NETCONF.

Lacking support for network locking model is an issue if there is a service
> activated across multiple devices via i2rs and in case of an error on one
> device, client has to be able to clean up on the other devices. Is this a
> viable use case that would prevent use of RESTCONF for i2rs?
>

I thought I2RS is starting out focusing on 1 client and 1 agent.
Network locking across devices is out of scope.

Andy

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 23 Apr 2014 20:19:38 +0000

On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

I have same opinion as you on this one, just wanted to spell it out one more time explicitly, as I heard some discussions where network locking was coming up.

Dean

---

From: chong feng <[email-masked]>
Date: Thu, 24 Apr 2014 14:16:38 +0800

I think we can introduce a new own protocol that is similar with NETCONF.
For example, extensiable RPC mechanism, session control will be reserved,
but capabilities and operations and datastores
about configuration management(edit-config/get-config etc) will be not
reserved, and introduce new
datastore/capablities/operations about I2RS.

The data model what the new protocol operates will be open, but must be
suitable for requirements of I2RS.

The encoding of new protocol is open, xml, json, binary,etc are all
acceptable.

We can suggest YANG model language as preferred data model language of
I2RS.

YANG is a excellent data model language for configuration management, but
it must be extend to adapt
to the requirements of I2RS.

---

From: t.petch <[email-masked]>
Date: Thu, 24 Apr 2014 10:17:41 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 23, 2014 6:08 PM
> t.petch <[email-masked]> wrote:
<snip>
> > how to combine the pieces to produce a coherent picture (and then
you

I see this lack of combination as a separate issue.

When the interest is in configuration, then the focus is on 'config
true' and anything else - state - can be ignored; NETCONF provides
get-config, edit-config etc which does just that.  NETCONF did not have
to provide this - it could have used filtering to filter out the 'config
true' - but I do not think that that would have been viable.

I2RS will have an interest in (some of) 'config true' and some of the
state - e.g. routing table entries learnt by BGP but not, at least in
some use cases, the read-only statistics.  The models have two separate
schema trees for 'config true' and state, as

http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt

Figure 1 and Figure 2 show.  What YANG does not have is a way of
correlating the two trees - rather, each data model has to craft its
own, such as look for value 'mm' in both object X in one list and object
Y in another list and assume that they refer to matching entries of the
lists.

Splitting state into two, operational and the rest, with an
i2rs:edit-data for the former, does nothing to help with this - it could
make things more complex.

We now have a three way split - do we now have three separate trees (if
not, why not)?  How do we get the i2rs:edit-data?  Do we use filters to
separate out the i2rs:edit-data, like a NETCONF get were get-config not
to exist?  Or do we need an i2rs:get-edit-data, except that that still
leaves the issue of correlation, so do we need some help from YANG for
that?  Do we need a i2rs:get-i2rs that spans 'config true' and
i2rs:edit-data?  Or do we make everything of interest to I2RS
i2rs:edit-data and scrap 'config true' as far as I2RS is concerned?

Most things are possible with YANG and NETCONF, but it will take time to
work out the details; perhaps we will end up changing some of the tenets
of RFC6020.  Knowing how long operational state has been a topic on the
netmod WG list, will we still be working out the details of this in a
year's time?

Tom Petch

p.s.  if only draft-ietf-i2rs-rib-info-model were updated to use YANG,
with or without i2rs:edit-data, so as to make this concrete?

---

From: Rob Shakir <[email-masked]>
Date: Thu, 24 Apr 2014 10:24:37 +0100

Hi Dean,

> Does the WG see a need for i2rs to provide mechanism for persistent changes?

Whilst it would be nice from an i2rs view to say “no, we can clearly make these changes via NETCONF”, from my perspective, it is very important that we ensure that we do not end up with unnecessary fragmentation between different approaches to changing the state of an element of the routing system. As soon as we say we interact with the i2rs agent for a particular set of ephemeral state, and then with via a separate path using NETCONF other persistent state then we drive complexity into the systems layer above the element - which is, IMVHO, best avoided. We end up having to have such fragmentation today where we have MIBs that give us a subset of information/writable configuration, and another subset available via CLI - and it causes pain.

From my reading of the architecture -02 draft, then within the overview of the architecture (§1.2) then currently we state (under the definition of “Static System State”) “How the I2RS agent modifies of obtains this information is out of scope” — which seems to support the view that persistent changes are something we consider required for I2RS. 

Cheers,
r.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 05:48:23 -0400

I dont know of any. But it looks like an interesting academic paper
one could write.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 05:49:04 -0400

Our code (which is used in production for a few years) unfortunately is not
open source (we dont have the resources as a small company).
However, i do plan to implement i2rs with quagga (zebra to be specific)
and hope to show up with some results - that is if i dont get overruled to using
ForCES before the next meeting.

cheers,
jamal

On Tue, Apr 22, 2014 at 10:44 AM, Andy Bierman <[email-masked]> wrote:
>> On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder
>> <[email-masked]> wrote:

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Apr 2014 11:59:05 +0200

> Y in another list and assume that they refer to matching entries of the

We tried to address this duality in this draft (now expired):

http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

The result was, at least in my view, less than satisfactory. There certainly is a correlation between configuration and state data but it can be tight or loose depending on at least the following two factors:

- The amount of processing done by the configuration system. For example, it can turn high-level configuration into corresponding low-level settings in the device.

- Often there are other factors beside configuration (e.g. network protocols) that influence the final result.

So we eventually came to the conclusion that configuration and state data are in general independent, and separate trees were introduced - not only in the routing-cfg draft.

Lada

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:02:05 -0400

Hi Jeff,

Apologies, on travel mode - so some latency involved.

> such as communities or inputs to various BGP-like policy mechanisms.

It will be useful to come up with some hand-wavy numbers; at minimal
for implementations to check if they are within expected ranges.

> If someone is willing to start stubbing in similar items for Netconf/Yang,

I will update the ForCES bits at the next opportunity i get. Useful again to
have a matrix of I2RS requirements vs what a model/protocol offers.
While the presentations at the meeting attempted to follow that, it was
not "standard" requirements.

> Obviously such details are discussion points and the above is simply my

it does make sense; note what i said earlier are arguements the
pro-json camp uses against xml. Mostly they deal with a browser as
an endpoint.
Having said that there will always be an impedence mismatch of some
form between a representation and the native format; i just claim
it is less so with binary than it is with any form of ascii.

> supported across a wide range of devices.  This has impact, for example, on

Nod.

> deal as it could be.  Of course, that presumes we're layering on top of

Yes, http compression is pretty ubiquitous - so something like restconf
could take advantage of that.

> complexity one layer up/down.

So I am sensing development debugging then?
The arguement i have heard is that operators debug
by capturing on the wire packets and that ascii was easier to follow.

> favorite scripting language.

Ok, understood.

> I've left a stub in the wiki for helping to derive or map requirements.

I will be picking requirements as i find them (architecture doc etc) and
filling up the ForCES responses.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:12:15 -0400

Thanks for posting on that draft. Google was kind to find it for me.
For other folks, Robert is talking about his draft here:
http://tools.ietf.org/html/draft-varga-netconf-exi-capability-01

I thought ive heard claims that "CPUs are fast enough, dont worry"
and this draft's problem statement is (to make netconf):
" ... more efficient from both CPU and bandwidth utilization perspective...

What do you have to say for yourself Jan/Thomas ? ;->

cheers,
jamal

On Tue, Apr 22, 2014 at 12:18 PM, Robert Varga <[email-masked]> wrote:
> implementation in OpenDaylight, so benchmarking should be possible. Sorry,
> don't have the cycles to actually design/run a reasonable test suite.
>
> Bye,
> Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:24:31 -0400

On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <[email-masked]> wrote:
>
> On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email-masked]> wrote:
>

> I thought I2RS is starting out focusing on 1 client and 1 agent.

Dont think so.

> I have same opinion as you on this one, just wanted to spell it out one more
> time explicitly, as I heard some discussions where network locking was
> coming up.
>

Either I am misunderstanding both of you or both of you misunderstood the
requirement.
The idea is to allow a single writer per object as a starting point.
OTOH, if you really mean what you say then I violently disagree.

cheers,
jamal

PS:- Changing the topic so this is not lost in the noise because i think that
the many clients-single agent brings needs for other protocol requirements.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2014 12:31:43 +0200

> What do you have to say for yourself Jan/Thomas ? ;->

Frankly, I think it is the job of those who propose alternate
encodings to provide evidence that the proposed encoding leads to
noticable improvements. And I like to insist on security being
included in such a study since NETCONF by definition runs over 
secure transports.

/js

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:41:18 -0400

For comparison completion, ForCES data model does not need ANY changes.
We do need to specify some new data types and models for the different objects
as will always be the case for any new LFB but we dont need any changes
to the model.

cheers,
jamal

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Apr 2014 13:12:44 +0200 (CEST)

t.petch <[email-masked]> wrote:
> correlating the two trees

See also Lada's reply.

What kind of correlation are you looking for?  The point is that these
are *different* structures, with different semantics.  If an entry
exists in the operational state, it doesn't imply there is a
corresponding entry in the config, and vice versa.  And just b/c a
config entry also exists in operational state doesn't mean that it is
*exactly* as configured; some other dynamic mechanism might have
changed it.  It all depends on what you model.

> - rather, each data model has to craft its
> not, why not)?

I don't think a separate structure for i2rs routes are needed, b/c it
is supposed to directly modify the operational state.

Also, I don't think this is a YANG-specific issue; any modelling
language can model one, two or three separate structures.  If we put
the configuration part aside, you still have to decide if you need one
or two (or N) structures for "i2rs" state and "complete" state.

> How do we get the i2rs:edit-data?  Do we use filters to
> to exist?

Sure, just like might want to get the routes from bgp or some other
protocol.

/martin

---

From: t.petch <[email-masked]>
Date: Thu, 24 Apr 2014 14:15:13 +0100

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Edward Crabbe'"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 23, 2014 5:21 PM

Sue

That is a feature of YANG.  Spend half a day on the netmod WG archives
for 1H2013, particularly May and June and for interfaces-cfg, and all
will be clear.

As Ladislav said on 2May13,

"In the current model, the operational state data are not present unless
the corresponding entry in the "interface" list is *configured*. So,
what I have in mind is a data tree like this: ..."

That is, 'config false' nodes under a 'config true' node do not get
instantiated in the data model unless and until the 'config true' node
is configured.  So if you have the one routing table, you will be unable
to see the routes learnt via BGP - 'config false' - unless and until you
configure the table by creating a static route - 'config true'.

It is a tenet of YANG so fundamental, so basic, that I know of nowhere
where it is written down:-(

Tom Petch

> To: Edward Crabbe; [email-masked]>
that
> Take routing.  A static route is configuration; anything learnt, via
BGP,
I2RS
> Rather, as Andy Bierman said at IETF89, likely I2RS would need an
extension

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 06:46:23 -0700

> where it is written down:-(
I am confused.
How would a router that has no 'eth27' interface configured suddenly
start reporting statistics for an interface named 'eth27'?

I think the operational state is usually related to the configuration,
wrt/ instance naming (at least).  The same YANG module could have
config data and operational state.  NETCONF could read everything and
write config, and I2RS could read everything and write operational state.

Even if the objects are separated, the data types, identities, features,
and instance naming can be easily shared across protocols.

Using different data types and instance naming for config
and operational state would mean that humans and machines would
need to know both, and be able to translate from 1 to the other.
This would be an operational nightmare.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Apr 2014 16:27:01 +0200

> is configured.  So if you have the one routing table, you will be unable

This issue only affects 'config false' data appearing in the subtree of a 'config true' node.
In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. 

> configure the table by creating a static route - 'config true'.

Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration.

> where it is written down:-(

Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13.

I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work.

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 24 Apr 2014 15:42:51 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, April 24, 2014 12:12 PM
 <snip>
> or two (or N) structures for "i2rs" state and "complete" state.

Martin

The reason I speculate about three structures relates to the rules of
YANG, for example that 'config true' cannot be subordinate to 'config
false' in the schema tree.  I cannot now recall what goes wrong were
that not to be the case, but if we introduce i2rs:edit-data, then what
are the rules about that?

Can it be freely mixed with 'config true' in the tree, or do we need
more rules about what can appear under what? or do we need to work more
on the semantics of i2rs:edit-data?

I don't know, hence my question (and my underlying concern that some way
down the road, I2RS Information Models complete, we will hit a snag
related to this that makes data models difficult to derive from the
Information Models)..

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 07:50:22 -0700

On Thu, Apr 24, 2014 at 7:27 AM, Ladislav Lhotka <[email-masked]> wrote:

> In my opinion, such a data organisation should be generally avoided, and
> that's why we now have configuration and state data in separate trees.
>
>
So to be clear -- it is a property of the data model, not the language.
YANG allows top-level config=true or false nodes.  The data model
authors need to pick the design patterns that are most appropriate.
(just like code ;-)

Generally, the correlation is embodied in the list keys -- the data naming.
For example in the interfaces module, the keys are the same.

     typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:name";
       }
       description
         "This type is used by data models that need to reference
          configured interfaces.";
     }

     typedef interface-state-ref {
       type leafref {
         path "/if:interfaces-state/if:interface/if:name";
       }
       description
         "This type is used by data models that need to reference
          the operationally present interfaces.";
     }

A weakness of YANG (perhaps Tom's point?) is that the correlation
between the 2 'name' leafs is defined in the description statements,
(elsewhere in the module) not any machine-readable statements.
In general, this correlation is very model-specific, and it might be too
hard
to formalize into machine-readable statements.

> Note this has never been the case in the ietf-routing module. Routing
> tables (later renamed to ribs) were always "pure" state data and the
> default rib for every address family is supposed to be present
> independently of any configuration.
>
> >
> Please see the definitions of system-controlled versus user-controlled
> list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13.
>

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Apr 2014 14:02:02 -0400

Jamal,

> by capturing on the wire packets and that ascii was easier to follow.

Such tap points are definitely there (or should be, IMO) for development
debugging.  The "capture on the wire" scenario is complicated by whether
encryption is in use or not.  Binary or not isn't critical here in some
respects.  After all, wireshark does perfectly fine in decoding various
binary protocols.

But it does mean in terms of our security and usability requirements that
permitting integrity-only options vs. encryption required needs to be
carefully thought through.

-- Jeff

---

From: t.petch <[email-masked]>
Date: Thu, 24 Apr 2014 19:12:20 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>; "Susan Hares" <[email-masked]>;
"'Edward Crabbe'" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 24, 2014 3:27 PM
> In my opinion, such a data organisation should be generally avoided,
and that's why we now have configuration and state data in separate
trees.
> I also think think is no idiosyncrasy of YANG, just the way how most
systems and their CLIs work.

Is it, though, the right approach for I2RS?  I see the rationale of I2RS
as being able to take a holistic view of the routing system, not one
based on where the information is coming from (a view that may make
sense when building boxes or installing them).

Rather, I am minded of problems I have been called upon to resolve which
are the result of misconfiguration, misconfiguration which is not
apparent because the integrated view of what is controlling the box  is
not available.  For example, a static route is inserted to circumvent a
quirk of topology, the quirk is fixed but the static route is not
removed, the topology changes again and that static route becomes a
liability.  Being able to see everything at once makes the problem
apparent, looking for a configuration error or a BGP error separately is
fruitless.

My sense is that I2RS needs an integrated view whereas NETCONF/YANG
focus on the configuration (as their RFC explicitly state).  YANG is a
good start, but as Andy said at IETF89, not enough.

Tom Petch

> Lada
>
> >
> > Tom Petch
> >
> >
> >> - UML seems to be able to handle read/write variants, and I'm
looking
> > to see
> >> I will continue to try to get more details on Yang++ and ForCES to
see
> > how
> >> table, the host software has to know where to look and how to
combine
> > the
> >> pieces to produce a coherent picture (and then you cannot edit most
of
> > it).
> >> read-only or read-write), and not moving on to an implementation,
then
> > YANG
> >> to YANG, a new sub-statement for all data objects, semantics not
too
> > clear

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Apr 2014 20:57:50 +0200 (CEST)

> good start, but as Andy said at IETF89, not enough.

I am not sure I what you mean by "integrated view".

One reason for separating config from operational state is to make
sure the view of operational state is exactly what is really currently
in use.  So if a static route has been configured, and it really is in
use, it will show up in the operational state (marked as being a
static route).

Isn't the "integrated view" the complete operational state?  If not,
how is it different?

/martin

---

From: t.petch <[email-masked]>
Date: Wed, 30 Apr 2014 15:25:06 +0100

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>; "Susan Hares" <[email-masked]>;

Lada

I find the I-D slightly inconsistent and incomplete on this matter.

I find it inconsistent in its definition of user-controlled entry.

s2.1 "   user-controlled entry:  An entry of a list in operational state
data
      ("config false") ... "

versus

s4.1 "   Additional entries may be created in the configuration by the
user
   via the NETCONF protocol.  These are so-called user-controlled
   entries. "

where configuration means, to me, configuration which is then not
operational state.

Also in s4.1 " Deleting a user-controlled entry from the configuration
list results .........."
suggests to me again that user-controlled entries can appear in the
configuration.

Given the length and quantity of discussion on this issue over the
years, I think that precision is called for.  I am easy as to whether
user-controlled entries can appear in configuration and operational
state, or only in operational state, but think that the I-D needs to be
precise and consistent.  If you take the latter option, then you
probably need a new term to describe entries in a configuration list
that correspond to entries in an operational state list in order to
specify the interactions arising from operations on the entry in the
configuration.

Separately, most discussions, although not all I-Ds, split two ways,
into configuration and state and may then subdivide state into
operational state and read-only statistics.  This I-D seems not to allow
for read-only statistics, and seems to use state and operational state
interchangeably. Again, I think that precision is called for.  I2RS may
be interested in statistics.

And the point I first raised, of when state is instantiated in the data
model, I do not see covered here (not that I was too hopeful that it
would be:-(

As you say, above,

> This issue only affects 'config false' data appearing in the subtree
of a 'config true' node.

but given the quantity of discussion arising from it a year ago, I still
think that it is a pitfall that should be written down.

I keep this on the I2RS list since I imagine that these issues may arise
as and when YANG is used to create I2RS models.

Tom Petch

<snip>

---

From: t.petch <[email-masked]>
Date: Wed, 30 Apr 2014 17:24:16 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, April 24, 2014 7:57 PM

Martin

>From what you say, then yes, it is.  Is it always the case that an entry
in a
config list is replicated in the matching operational state list for
some meaning of the word matching?  If so, then how is matching defined?
 Is it up to each individual model to specify this in the description?

Lada says
"have to be populated with at least
   one entry in any properly functioning device, and additional entries
   may be configured by the user."
which fits the case of routers but this issue occurred in 2013 for
interfaces, system, routing, ... and my expectation is that it will
occur in most models.  Except that with routing, you may have 350k
entries in the operational state list and none in the config list,
whereas in other models, the common case may have many entries in the
config list and few or none system-controlled ones in which case, I am
uncertain if the same logic should apply.

I think that more explanation is still needed.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2014 08:03:17 -0700

> slides that may convince you, and an alternate drafts.

I do not have any objections to using UML.
They are painful to read and write in ASCII art.
Maybe that's why we tend to describe the model in introductory text.
We also try to avoid duplicating normative text, and try to keep as much
normative text in the YANG modules themselves (since they tend to get
extracted and the RFC tossed ;-).

This is an awesome step forwards.  Thanks!
I was going to translate the next info-model draft to YANG so we
can compare YANG and ForCES using the same data definitions.
Looks like you already did that, but I just see the YANG tree diagram in
the draft,
not the YANG module.

It is still enough to see how YANG features would be defined, based on
protocols.
Clearly, not every I2RS router is going to implement the exact same set of
protocols.
Not every conceivable piece of data is going to be mandatory to implement.
Data organization and modularity are really important aspects to get right
the first time.

Andy

>   | if     | ietf-interfaces           | [YANG-IF<http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IF>]
> |
>
>   |        |                           |           |
>
>   | ip     | ietf-ip                   | [YANG-IP<http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IP>]
> |
>
>   |        |                           |           |
>
>   | rt     | ietf-routing              *| [routing] |*
>
>  |        |                           |           |
>
>  | v4ur   | ietf-ipv4-unicast-routing *| [routing] |*
>
>   |        |                           |           |
>
>   | v6ur   | ietf-ipv6-unicast-routing |* [routing * |
>
>   |        |                           |           |
>
>   | yang   | ietf-yang-types           | [RFC6991<http://tools.ietf.org/html/rfc6991>]
> |
>
>   |        |                           |           |
>
>   | inet   | ietf-inet-types           | [RFC6991<http://tools.ietf.org/html/rfc6991>]
> |
>
> Basically the complex RBNF grammar boils down to very few simply
> statement.  The Yang Tree does not provide an easy way to design/debug
> redundancy. I think that the use of the UML tools that create the Yang
> modules/Yang Tree structures could speed time to market on the designs.
>  For example, all the I2RS RIB is simply 5 power-point slides, that then
> can be generated into Yang module.  This seems the normal progression of
> the process you started with the Yang-modules.
>
>
>
> CAVEATS:
>
> 1)      For all mistakes on the UML and diagrams blame me - this first
> pass at UMLs, and it will need revising
>
> 4)      I suspect with Jamal and Joel Halpern's help (FoRCES gurus)..
> FoRCES Data model can do the same
>
>
>
> Sue Hares
>
>
>
> *Sent:* Tuesday, April 22, 2014 8:46 PM
> *To:* Susan Hares
> Russ White; Jan Medved (jmedved); Joel M. Halpern
> [Andy] Why do you think I said that I don't see anything special about
> I2RS at all. Editing operational state would probably work the same for
> other data.
>
> [Sue]: Agree!
>
>
>
> [Sue]: Other designers on lists stated they suggested they considered IM
> in their design of YANG.  I think the graphical finds redundancies
>
> <snip)
>
>
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 22 Apr 2014 10:14:58 -0400

I see a different flaw just from the first few pages and looking at
the conclusion.
Sorry - didnt have time to look at the whole thing.
The paper picks a model entity of about 90% strings (theres one "int" iirc).
I am not sure what that was supposed to emulate. From that perspective
the question answered to me seems to be "how bad does SNMP do when you
have mostly strings?". It seemed to do fairly well at the end. I liked
the fact they
tried to batch things with SNMP.
If i was emulating what I2RS is doing by building on say the RIB model, it will
not be 90% ascii on the wire for SNMP.

cheers,
jamal

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Apr 2014 10:41:35 -0400

Andy:

  |        |                           |           |

  |        |                           |           |

 |        |                           |           |

  |        |                           |           |

  |        |                           |           |

  |        |                           |           |

CAVEATS: 

Sue Hares  

<..snip>  

[Sue]: Agree! 

<snip)  

Hi,

 

 

RESTCONF is a protocol.

 

 

:-)

Russ

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Apr 2014 11:13:55 -0400

Andy:

You are right about the graphics.  I've started a thread to the RFC Editor
and the ISE Editor who are working on the graphics. There is a UML to SVC
project that I am looking into to see if we can do this. 

I just did the tree structures because they actually are a short step away
from the UML diagrams.  This may allow us to expand the yang trees to be a
poor-man's uml while we wait for the graphics.   Would you look at the tree
to see if I got the yang tree right for config?   The RBNF did not take care
of the ro status, so I need to create this for the yang modules.  This is
one reason the RBNF is so poor rather than the UML.  

If these tree structures are ok, I think I can quickly turn this into a full
yang definition.  I'll do that once you respond and we can get the full yang
module definition up and running. I'd love to work with you on a draft
regarding the yang module definition as you are the expert. 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 11:03 AM
To: Susan Hares
Cc: [email-masked]; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ
White; Jan Medved (jmedved); Joel M. Halpern; Adrian Farrel; Alia Atlas;
Nitin Bahadur; Jeffrey Haas
Subject: Re: [i2rs] consensus on I2RS protocol and model

Andy:

 

Looks like you already did that, but I just see the YANG tree diagram in the
draft,

not the YANG module.

 

Andy

  |        |                           |           |

  |        |                           |           |

 |        |                           |           |

  |        |                           |           |

  |        |                           |           |

  |        |                           |           |

CAVEATS: 

Sue Hares  

<..snip>  

[Sue]: Agree! 

<snip)  

Hi,

 

 

RESTCONF is a protocol.

 

 

:-)

Russ

Andy

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 23 Apr 2014 10:08:06 -0700

Hi Sue;

Could we please move the UML discussion to a separate thread ?  Definitely
a useful topic , and I'm very glad the conversation is happening, but I'd
like to keep this (very long) thread fairly focused.

Cheers,
  -ed

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:17:11 -0400

Sorry, was there something i missed here that Andy is awesom-ing?
What graphics?

Sounds to me like an information model in plain english (the openstack people do
this) would have been a reasonable start as well, no?

cheers,
jamal

On Wed, Apr 23, 2014 at 11:03 AM, Andy Bierman <[email-masked]> wrote:
>>   | if     | ietf-interfaces           | [YANG-IF] |
>>
>>   |        |                           |           |
>>
>>   | ip     | ietf-ip                   | [YANG-IP] |
>>
>>   |        |                           |           |
>>
>>   | yang   | ietf-yang-types           | [RFC6991] |
>>
>>   |        |                           |           |
>>
>>   | inet   | ietf-inet-types           | [RFC6991] |
>>
>> modules/Yang Tree structures could speed time to market on the designs.  For
>> example, all the I2RS RIB is simply 5 power-point slides, that then can be
>> generated into Yang module.  This seems the normal progression of the
>> process you started with the Yang-modules.
>>
>>
>>
>> CAVEATS:
>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 06:36:23 -0700

> Sorry, was there something i missed here that Andy is awesom-ing?
No -- just progress on the info model.

Once we have an info model, it can be mapped into both
YANG and ForCES so they can be compared side-by-side,
using the actual model that this WG wants to standardize.

Andy

>  For
> >> use cases brought out that either NETCONF/YANG or FORCES not fulfill?
> One
> >> of
> >> >From my perspective, these two systems don't fulfill the I2RS mandate
> on
> >> the
> ever
> functionality

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 16:39:59 -0400

Ed and all: 

The chairs are just letting through old mail (see the date) - I moved this
topic to another list.  Anyone post on this topic should go to:  Re: [i2rs]
Some comments on draft-ietf-i2rs-rib-info-model-01.

Use the thread index on the list to find it if you have questions drop me a
note. 

Thanks, 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, April 23, 2014 10:42 AM
To: 'Andy Bierman'
Cc: Nitin Bahadur; [email-masked]; 'Edward Crabbe'; 'Jamal Hadi Salim'; 'Dean
Bogdanovic'; 'Russ White'; 'Jan Medved (jmedved)'; Alia Atlas; 'Jeffrey
Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] consensus on I2RS protocol and model

Andy:

  |        |                           |           |

  |        |                           |           |

 |        |                           |           |

  |        |                           |           |

  |        |                           |           |

  |        |                           |           |

CAVEATS: 

Sue Hares  

<..snip>  

[Sue]: Agree! 

<snip)  

Hi,

 

 

RESTCONF is a protocol.

 

 

:-)

Russ

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2014 19:57:43 -0400

> OTOH, if you really mean what you say then I violently disagree.

Single writer per object at a given time.  No locking, but also nothing
restricting more than one client from modifying the same thing.
(The things driving the clients must do the coordinating.)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2014 20:24:51 -0400

> changed it.  It all depends on what you model.

As I try to work through my reading of netconf and yang, the use case we're
discussing here is the one that troubles me the most.  Let me pick two
specific examples of injecting i2rs state on top of something that may have
coverage within existing yang configuration models: static routes and BGP.

It would be very convenient for purposes of configuring static routes in
i2rs where the semantic is ephemeral configuration to not have to duplicate
the existing yang model.  If the model in question was design to use
groupings, it appears that it would be easy to have one instance for normal
configuration and a second one specifically for i2rs.  It would be even more
convenient if we had a semantic that was not only "config true", but
potentially "config true|ephemeral".  

The issues then comes back to the ones noted in
draft-bjorklund-netmod-operational-00: How do we distinguish operational,
config or ephemeral config states?  When there are different precedences
(ephemeral overrides static, e.g.), how could you do a get that presents the
implemented order?

The BGP example to my mind may only go slightly further than this.  For
some types of i2rs configuration state, I can foresee wanting some portion
of it to be based upon non-ephemeral configuration - for example base BGP
state that should not be modified by i2rs.  Presuming that base state
exists, it may be desirable to permit something like BGP peer configuration
to re-use the existing BGP yang model for configuration, just in an
ephemeral context.  Thus, some portions of the configuration are
instantiated ephemerally and some require underlying non-i2rs config.

> is supposed to directly modify the operational state.

This is where I think we're getting stuck.  There is some vagueness between
operational state that can be modified and ephemeral configuration.  But the
real issue is when multiple forms exist, how do we operate upon it/see it in
a useful fashion?

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 May 2014 07:38:39 +0200

On Wed, Apr 30, 2014 at 08:24:51PM -0400, Jeffrey Haas wrote:
> operational state that can be modified and ephemeral configuration.

Are you saying there is a difference between 'writable operational
state' and 'ephemeral configuration' but the difference is still
unclear and hence vague?

/js