Subject: [OPSAWG] Negotiation replacing configuration

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jan 2014 13:04:05 +1300

Hi,

I'm a bit surprised at the silence on this. After all, we
are suggesting a fairly radical change of approach: from
centrally-driven configuration of devices to peer negotiation
between devices. In this WG we'd like to get feedback on
the problem statement based on real experience, since the
NMRG discussion is more likely to be theoretical.
Also, is our summary of existing protocols accurate?

    Brian

-------- Original Message --------
Subject: I-D Action: draft-jiang-config-negotiation-ps-02.txt
Date: Sat, 18 Jan 2014 11:23:25 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Network Configuration Negotiation Problem Statement and Requirements
        Authors         : Sheng Jiang
                          Yuanbin Yin
                          Brian Carpenter
	Filename        : draft-jiang-config-negotiation-ps-02.txt
	Pages           : 14
	Date            : 2014-01-18

Abstract:
   This document describes a problem statement and general requirements
   for distributed autonomous configuration of multiple aspects of
   networks, in particular carrier networks.  The basic model is that
   network elements need to negotiate configuration settings with each
   other to meet overall goals.  The document describes a generic
   negotiation behavior model.  The document also reviews whether
   existing management and configuration protocols may be suitable for
   autonomic networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 30 Jan 2014 19:18:42 -0800

Brian,

Many protocols already do some type of negotiation but it is based on
capabilities and local/remote configuration rather than operational state
-- at the link layer 802.3x and DCBX come to mind, with routing protocols
operational parameters such as the hello timer come to mind, or even with
TCP things like ECN and SACK are negotiated.  But that is a one-off
negotiation at startup.

The draft seems to want to take this kind of negotiation one step further.
 It looks like an interesting concept.  I worry a bit about the complexity.
 This also seems to be moving in the opposite direction of a centralized
SDN controller making global decisions and implementing them (just an
observation, not a judgement about whether it's a good or bad thing).  It
would help to see a detailed example of how this would actually work for a
sample network/application for folks to get a feel for the complexity.

Anoop

On Tue, Jan 28, 2014 at 4:04 PM, Brian E Carpenter <
[email-masked]> wrote:

> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Feb 2014 11:14:08 +1300

Hi Anoop, thanks for the comments. Answers in line.

> TCP things like ECN and SACK are negotiated.  But that is a one-off

Yes, and we'd like more examples of existing negotiations.

>  It looks like an interesting concept.  I worry a bit about the complexity.

Well, our hope is that the protocol itself would be rather simple.
But like "Simple" Network Management Protocol, the solutions constructed
with the protocol would be rather complex. The point is that humans
wouldn't have to deal with the complexity.

> observation, not a judgement about whether it's a good or bad thing). 

Absolutely correct. It has been pointed out that SDN controllers
don't have to be literally central and global, but if you have multiple
controllers you'd need some kind of arbitration between them; in our
minds that would be an application of generic negotiation, using
negotiation objectives that mean something to an SDN controller.

> It

Agreed. Working out some detailed use cases is necessary, but it's
hard to do with assuming something about the actual protocol
We do have a draft about the protocol solution too, but it seems
better to start by discussing the problem.

Regards
    Brian