Subject: [Supa] Latest Info and Data Model Presentations

From: John Strassner <[email-masked]>
Date: Mon, 20 Jul 2015 06:16:29 +0000

These are interim works for comments, please.

regards,
John

John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2015 13:06:54 +0200

> These are interim works for comments, please.

While I understand where Jon is coming from, I believe the supa engine
slides make the problem to big to solve in the IETF. The IETF is
working best if problems are narrowly scoped and can be solved in
reasonable amount of time. Supporting multiple policy adaptors is
something we should IMHO not start with. We should assume the SB
interface is YANG and NETCONF/RESTCONF in order to achieve something
usable in a reasonable amount of time.

/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: Jon Saperia <[email-masked]>
Date: Tue, 21 Jul 2015 07:19:04 -0400

I believe there is consensus among many of those presenting that the problem as described is tractable in reasonable in increments fully supports YANG while making it possible to have interoperation across management environments.

/jon
> On Jul 21, 2015, at 7:06 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
> 

Thanks
/jon
------------------------------------
Jon Saperia
(mobil) 617-201-2655
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2015 13:47:55 +0200

On Tue, Jul 21, 2015 at 07:19:04AM -0400, Jon Saperia wrote:
> I believe there is consensus among many of those presenting that the
> problem as described is tractable in reasonable in increments fully
> supports YANG while making it possible to have interoperation across
> management environments.

I believe the scope of this effort should be very clearly limited to
YANG data model semantics and NETCONF/RESTCONF protocol operation
semantics.

Slide #2 'Scope of Work' of the engine slide set mentions
"NETCONF/RESTCONF, SNMP, Puppet, Chef, AWS, Vendor APIs" as SBIs. I
happen to understand two of the technologies listed reasonably well, I
have some ideas of others and I am clueless of the rest. For those I
do believe I understand reasonably well, I also know that the semantic
differences and the data modeling differences are significant.

Sure, it could be that I am the only one concerned. But clearly, for
me this is too big a problem to solve and I question that we have a
sufficient number of people (human resources) involved in SUPA that
understand the technologies mentioned on slide #2 well enough to
deliver something that works in a reasonable amount of time.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Jul 2015 04:49:33 -0700

Hi,

I agree that "boiling the ocean" is something we want to avoid,
since it always means "no WG for you".

What if we say the architecture allows for various southbound
data interfaces, but we will only standardize NETCONF/YANG?
The translation function for N/Y will be "pass-thru".

I am still very unclear about what the SUPA module looks like,
and how constructs defined in YANG are actually info models
not data models.  I would like YANG to be the canonical form
of the policy.

Most of the constructs in YANG are generic, but not all.
If I define a list with nested lists, then SNMP needs to
unfold the nested lists into flat tables.  CLI may define
modes and submodes.

If the YANG leaf is an int16, then maybe it is easy to map
to other SBIs, but maybe not for decimal64.  I am concerned
that the solution gets too complicated if I have to restrict
the policy to generic types that can be universally mapped.
I think you are concerned about this as well. (Consider
types like float32 that are not even supported in YANG)

The counter-argument to the many SBIs is to just leave
it out of scope.  If we are not going to standardize it, then
do we really need it in the architecture?  Most of the SBIs
would work better as open-source projects, not standards.

Andy

---

From: John Strassner <[email-masked]>
Date: Tue, 21 Jul 2015 08:09:31 -0700

I have tried to emphasize in the info model presentation that we are
narrowly focused on YANG. Juergen and others, please see if I emphasized
this enough.

Just because the info model is built generically does not mean that we have
to build out all southbound interfaces and all southbound data models. In
addition, I think that we will learn from supporting YANG over
NETCONF/RESTCONF, and that will in turn help make our second step -
interfacing with other non-YANG models, easier.

IMHO, our third step would then be to build out such non-YANG data models.
But that is for a new charter. :-)

regards,
John

-- 
regards,
John

---

From: Jon Saperia <[email-masked]>
Date: Tue, 21 Jul 2015 11:18:19 -0400

> On Jul 21, 2015, at 11:09 AM, John Strassner <[email-masked]> wrote:
> 
> I have tried to emphasize in the info model presentation that we are narrowly focused on YANG. Juergen and others, please see if I emphasized this enough.
> 
> Just because the info model is built generically does not mean that we have to build out all southbound interfaces and all southbound data models. In addition, I think that we will learn from supporting YANG over NETCONF/RESTCONF, and that will in turn help make our second step - interfacing with other non-YANG models, easier.
> 
> IMHO, our third step would then be to build out such non-YANG data models. But that is for a new charter. :-)

I would disagree on this point.  There are decisions made early on that impact future work.  The charter should state clearly what the goal of the proposed technology is.  The charter/WG indicate an initial task list that can be augmented in the future, but the direction of the effort and technology should be clear in the charter.
/jon
> 
> regards,
> John
> 
> On Tue, Jul 21, 2015 at 4:06 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/supa <https://www.ietf.org/mailman/listinfo/supa>
> 
> 
> 
> -- 
> regards,
> John

Thanks
/jon