Subject: [I2nsf] Comments to draft-xia-i2nsf-capability-interface-im-00

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 2 Feb 2015 19:39:38 +0000

Just found out recently about this WG and started looking through the email thread.

Have some general comments

Security applications (FW, IDS, UTS, etc) are in general L7 applications that direct traffic forwarding based on some rules calculated by them. If you think more about it, it is a service plane, which sits on  top of data plane. Today security devices, are combination of data plane (for traffic forwarding) and service plane (for threat analysis). I can very well see dismantling that into different systems and then the question is how to communicate between those systems.
I2RS is thinking how to create interface between data and control plane, essentially be able to run an application like BGP somewhere else and then communicate the instruction to data plane how to act. I2NSF is looking specifically into security, but there is a common part between I2RS and I2NSF, especially if you look at the basic policy model in I2NSF, which is very similar to ACL Yang model (http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/) with some extensions 

I can easily see an architecture like this below

i2nsf client            
      |          
i2nsf agent (acting as i2rs client)               
      |         
i2rs agent
      |         
device

My suggestion would be to make sure that the work is not duplicated between I2RS and I2NSF, as there are some very close common goals between the groups.

I think the work is very useful, as intent based networking is a much better concept, then what is done with automation today

Some minor edits to the draft

In chapter 2 DDoS stands for Distributed Denial of Services (not Deny)

Chapter 3
In other words, the IM of the capability interface should be ...
What does IM stand for? You mentioned at the end of the chapter information model, but I believe IM should be either added to the abbreviation section or write down information model first and then use IM. Ideally you would do both.

Also, in Abstract section, you used NBI and NSF abbreviations and then explained them in the abbreviation section. You should use full name instead of abbreviation in the abstract section IMO. You used it in introduction section very nicely.

Dean

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 2 Feb 2015 20:42:11 +0000

+1, esp. on the intersection(s) between I2NSF and I2RS ... my view is that there are multiple other intersections that should be considered across the set (probably) interrelated efforts ... ANIMA, SUPA, IBNemo, SFC, to name just a few ... yes, each of these does (or aspires to do) something that uniquely adds value ... but leveraging the commonalities where they exist will make for better individual solutions and, much more importantly from the user perspective, a more powerful collective solution. I realize that one could get into a "boiling the ocean" situation with this, but I think the "right" level of focus on the intersections can be identified and pursued relatively easily, avoiding that trap.

Identifying, documenting, and promoting the cross-initiative commonalities among this set of initiatives (and I'm not sure I've got the set fully  populated yet) will yield benefits for all parties ... it should probably be an Area-level responsibility, however.

IMHO and YMMV!,
BobN

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Monday, February 02, 2015 2:40 PM
To: [email-masked]
Subject: [I2nsf] Comments to draft-xia-i2nsf-capability-interface-im-00

i2nsf client            
      |          

Chapter 3

Dean
_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 3 Feb 2015 01:16:53 +0000

Hi Dean,
Yes. Your understanding is correct. The whole I2NSF architecture is very similar to I2RS. The main difference is we are focused on the service plane and security services. 
For capability interface, we use the traditional "match & action" style to be compatible to most of existed implementations. So, there should be some common part between ACL model, which we need more study and cooperation.
About the intent-driven(service) interface, we also prepared a draft for it and will submit it very soon. We hope to get all the experts' supports and cooperation.

Thanks for your editorial comments too, I will correct them in next version.

B.R.
Frank

> Sent: Tuesday, February 03, 2015 3:40 AM
> To: [email-masked]
> Security applications (FW, IDS, UTS, etc) are in general L7 applications that
> direct traffic forwarding based on some rules calculated by them. If you think
> more about it, it is a service plane, which sits on  top of data plane. Today
> security devices, are combination of data plane (for traffic forwarding) and
> service plane (for threat analysis). I can very well see dismantling that into
> different systems and then the question is how to communicate between
> those systems.
> I2RS is thinking how to create interface between data and control plane,
> essentially be able to run an application like BGP somewhere else and then
> communicate the instruction to data plane how to act. I2NSF is looking
> specifically into security, but there is a common part between I2RS and I2NSF,
> especially if you look at the basic policy model in I2NSF, which is very similar
> to ACL Yang model
> (http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/) with some
> extensions
> 
> My suggestion would be to make sure that the work is not duplicated
> between I2RS and I2NSF, as there are some very close common goals
> between the groups.
> 
> I think the work is very useful, as intent based networking is a much better
> concept, then what is done with automation today
> 
> What does IM stand for? You mentioned at the end of the chapter
> information model, but I believe IM should be either added to the
> abbreviation section or write down information model first and then use IM.
> Ideally you would do both.
> 
> Also, in Abstract section, you used NBI and NSF abbreviations and then
> explained them in the abbreviation section. You should use full name instead
> of abbreviation in the abstract section IMO. You used it in introduction
> section very nicely.
> 
> Dean