Subject: [I2nsf] Why do we have "negotiation" for the "Control Plane"

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Sep 2016 19:59:40 +0000

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

---

From: John Strassner <[email-masked]>
Date: Mon, 12 Sep 2016 17:54:10 -0700

An even simpler and broader example is when two groups want to agree on a
particular function:

   - the function is a capability
   - negotiation is the process of agreeing to the final function used by
both groups

regards,
John

On Mon, Sep 12, 2016 at 12:59 PM, Linda Dunbar <[email-masked]>
wrote:

> 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.
>
>
>
>
>
> [Rakesh & Anil] Why do we have “negotiation” ? What are we trying to
> negotiate?
>
>
>
>
>
> *Cheers, *
>
> *Linda*
>
>
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

-- 
regards,
John

---

From: Rakesh Kumar <[email-masked]>
Date: Tue, 13 Sep 2016 04:25:30 +0000

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-masked]>
Date: Monday, September 12, 2016 at 12:59 PM
To: Rakesh Kumar <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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.

[Rakesh & Anil] Why do we have “negotiation”? What are we trying to negotiate?

Cheers,
Linda

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 00:22:18 -0700

Hi Rakesh,

please see my reply. What Linda meant is that the Overlay and Underlay
Controllers would offer a set of capabilities, then offer alternatives, and
continue until they agree on a mutually acceptable set of capabilities.
This is simply a more specific version of my generic example.

However, when you write:."In my opinion, I2NSF defines the management plane
(controller interfaces) for NSF". this conflates two very different
concepts. Please see the definitions of each that are in the current
Terminology I-D.

regards,
John

On Mon, Sep 12, 2016 at 9:25 PM, Rakesh Kumar <[email-masked]> wrote:

> 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-masked]>
> *Date: *Monday, September 12, 2016 at 12:59 PM
> *To: *Rakesh Kumar <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Why do we have "negotiation" for the "Control Plane"
>
>
>
> Rakesh,
>
>
>

-- 
regards,
John