Hi Linda, The example you mentioned below seem like a capability discovery and an appropriate action taken based on that. A negotiation is different in my opinion, for example IPSEC peers negotiate hashing and encryption algorithm to establish a secured connection.
Even before we go into this question, we have to clarify I2NSF control plane. In my opinion, I2NSF defines the management plane (controller interfaces) for NSF. The control plane and data plane of NSF should be out of scope for I2NSF (Look at draft https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework). The NSF control plane and data plane, is for each VNF/PNF vendor to define and as long as NSF provides I2NSF management interface (NSF-facing interface), it should be sufficient. Thanks & Regards, Rakesh From: Linda Dunbar <[email protected]> Date: Monday, September 12, 2016 at 12:59 PM To: Rakesh Kumar <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Why do we have "negotiation" for the "Control Plane" Rakesh, Here is a use case to address your following question: Cloud (Overlay) Network needs the underlay network to enforce Rule A & B &C. Not sure of the capability of the underlay network, the Overlay Network can send an inquiry to the underlay network asking if it supports Rule A &B&C. The underlay network may respond with “Only Rule A”. Then the Overlay network can only send “Rule A” to be enforced by the Underlay network. Control Plane: In the context of I2NSF, the Control Plane is an architectural Component that provides common control functions to all I2NSF Components, including some or all of the following: authentication, authorization, accounting, auditing, and Capability discovery and negotiation. [Rakesh & Anil] Why do we have “negotiation”? What are we trying to negotiate? Cheers, Linda
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
