Subject: Re: [I2nsf] I-D on a 'Packet-Based Paradigm For Interfaces to NSFs'

From: "Zarny, Myo" <[email-masked]>
Date: Sat, 4 Apr 2015 11:54:16 -0400

Hi Ed,

Sorry, I couldn't make it to Dallas. But here's my feedback.

*         I like how you broke up the problem set into three areas: (1) (device/network) configuration, (2) signaling, and (3) (policy and object) provisioning as you call them.

*         I also quite like how the "packet-based" approach using a generic "subject.object.function.action" (SOFA) format allows us to get away from getting mired in specific definitions of NSFs. Seems like a very extensible approach.

A few questions/comments/suggestions:

*         Given that the approach covers just the service provisioning aspect, do you have a position as to whether or not the I2NSF charter should cover configuration and signaling?

*         Do I understand correctly that the approach requires the callers of the I2NSF Provisioning API to provide their intent? If so, you might want to add that the entity receiving the request in a SOFA format MUST be able to interpret the request, and map it to southbound NSFs. (And I feel like it's even more than that. The entity needs to be able to map signaling requests to the appropriate southbound NSFs as well. That is, does a SOFA approach for provisioning necessarily require intent-based APIs for configuration and signaling as well?)

*         This leads to my next point: It'll be very helpful for readers to see a couple of examples of how the SOFA approach could be carried out in practice. In general, the approach definitely is neat-perhaps, too neat!? I'd like to see some real world examples.

Myo

From: I2nsf [mailto:[email-masked]] On Behalf Of Edward Lopez
Sent: 25 March 2015 12:42 PM
To: [email-masked]
Subject: [I2nsf] I-D on a 'Packet-Based Paradigm For Interfaces to NSFs'

Team,

Sorry for the lateness of this relative to our meeting this evening.  I just posted an initial I-D on the concept of using a packet-based paradigm in developing a provisioning interface to NSFs.  It is located at:

https://datatracker.ietf.org/doc/draft-lopez-i2nsf-packet/

The idea is that rather than attempting to define provisioning interfaces based on the capabilities of classes of NSFs, a better method may be to consider how any given NSF will process received packets.  Such a provisioning interface would use match values based on packet data, as well as contextual information associated with packets.

It also considers the idea that functions and egress actions may not be easily defined, since the functional capabilities of NSFs are not easily defined, especially from a standards basis.  It would be far easier for us to define a standards-based function, such as OSPF on a router, than to define a vendor-specific function, such as used by flow-match functions like IPS, where even signature formats are implementation-specific.  This results in the need for a capabilities exchange between NSFs and provisioning applications.

This draft is not intended to be a specific implementation, but rather a logical argument relative to the formation of the scope of our WG charter.  Questions and comments are appreciated

Thanks!

Ed Lopez - Fortinet

________________________________
*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
________________________________