Subject: [Netconf] Fw: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 22 Feb 2010 13:40:42 -0800

Hi -

Does anyone think that Netconf would find use in this, or is
the thinking still that Netconf's usage would be limited to
routers, bridges, and the like?

If the NIST definition is correct, then the supporting  access
control model(s) would need to be rather expressive.

Randy

> From: "Dave CROCKER" <[email-masked]>
> To: "Melinda Shore" <[email-masked]>
> Cc: <[email-masked]>; "David Chadwick" <[email-masked]>; <[email-masked]>
> Sent: Monday, February 22, 2010 1:08 PM
> Subject: Re: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim,CA)
> 
> 
> On 2/22/2010 12:59 PM, Melinda Shore wrote:
> > On Feb 22, 2010, at 11:52 AM, Brian E Carpenter wrote:
> >> My thought exactly. The distinction between cloud computing and open grid
> >> computing is very small (or possibly zero)
> >
> > With all due respect, Brian, it's really not. With cloud
> > computing you're typically dealing with multitenanting issues
> > and a bunch of other layer 8-9 stuff that tends (of necessity)
> > to be reflected down the stack, and I think I can see an
> > argument for cloud computing belonging in the RAI space,
> > or at least having substantial overlap.
> 
> 
> Having recently gone through the exercise of trying to understand what these 
> different terms actually meant, I discovered that the underlying problem is that 
> you are both right, as are a variety of other people who have other views...
> 
> As already noted, the term 'cloud' is now used in many different ways, including 
> as a synonym for 'network' and for 'Internet', even amongst technical folk. 
> (Really.)
> 
> There are some people who have very specific and nuanced technical definitions, 
> including distinguishing cloud from grid.  But no set of definitions seems to 
> have a broad base of support.
> 
> For defining 'cloud', one group I'm participating in decided it was happy with 
> the NIST language:
> 
>     <http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc>
...

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Feb 2010 19:45:56 -0800

> routers, bridges, and the like?

I'll bite -- and recycle some electrons...

When I first brought up the idea that unix .conf files might
be applicable to NETCONF, I was laughed out of
the room.  We didn't have YANG then.

The real issue isn't NETCONF, but rather NETCONF/YANG.

Any idiot can design an XML protocol to ask a structured
question and get a structured response.  The interesting
question is "Do you have an expressive schema language
for all possible content that allows the protocol work
to be automated, and all configuration files to be validated off-line?"

That extra layer of abstraction -- the use
of any formal data modeling language at all,
seems to be the part that is completely lacking
in most 1-off solutions.

The favored design seems to be to use an example
configuration file with comments in it instead.
There is only 1 protocol operation to consider (load config).

At some point in the future, when YANG is finally published,
NETCONF might be of interest outside the NM area, but probably
not until then.

> control model(s) would need to be rather expressive.

I wish them good luck with that.
Ignore the KISS Principle at your own risk. ;-)

> Randy

Andy

---

From: Carl Moberg <[email-masked]>
Date: Tue, 23 Feb 2010 07:15:18 +0100

Randy,

We have experiences with real applications of NETCONF outside the realm
of network elements.

The various management activities I've seen for "the cloud" (both
internal to vendors and in emerging standard activities) seems to be
coming from the enterprise programming side and be leaning heavily
on SOA (WSDL, SOAP) and REST technologies.

Having said that I think there defnitely is a role to play for NETCONF
for the packet/frame infrastructure of "the cloud". Many types of
provisioning scenarios includes making fairly complex changes the
configuration state of N network boxes (where N > 2). This is an area
where NETCONF shines with its formal modeling language, and validation
and transaction components.

On 2010-02-22 22:40 PM, Randy Presuhn wrote:
>> From: "Dave CROCKER"<[email-masked]>
>> To: "Melinda Shore"<[email-masked]>
>> Cc:<[email-masked]>; "David Chadwick"<[email-masked]>;<[email-masked]>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 22 Feb 2010 23:22:36 -0800

Hi -

> From: "Carl Moberg" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, February 22, 2010 10:15 PM
> Subject: Re: [Netconf] Fw: Announcing Clouds bar BoF during IETF-77 (March, 2010, Anaheim, CA)
...
...

Care to share any "lessons learned" with access control models to support
this environment?  I think it would be helpful to have both minimum requirements,
as well as cases of "we thought we'd need such-and-such, but it turned out
to be overkill."

Randy

---

From: Carl Moberg <[email-masked]>
Date: Thu, 25 Feb 2010 16:30:12 +0100

On 2010-02-23 8:22 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "Carl Moberg"<[email-masked]>
>> To: "Randy Presuhn"<[email-masked]>
>> Cc:<[email-masked]>
>> configuration state of N network boxes (where N>  2). This is an area

  My response was perhaps more to the question about experience
  with non-router/bridge experience in general than with specific
  focus on access control.

  However, my simple input on the application of NETCONF on the
  infrastructure part of "cloud" deployments (which, in my mind, is an
  operational model) is that it seems to have the same expectations on
  the network as any "service oriented" network in the service provider
  world. For example a network that provides end-customer VPNs:
   - One set of people, support systems and checklists/processes that
     work on keeping the network running smoothly and ready for service
     (IS-IS is stable, full iBGP visibility for VPLS, etc) - The NOC team
   - Another set of people, support systems and checklists that
     provisions customer-oriented "services", e.g. makes sure that all
     involved PE-routers are automatically and correctly configured
     for customer VPNs - The Service Provisioning team

  The NOC team typically and historically require full access to all
  configurables in the box and with the exception of some internal
  hierarchy (e.g. specific security clearance needed to reconfigure
  access control or standard filters) there no strong reason to change
  this.

  The Service Provisioning team on the other hand expects the networ
  to be up and stable and provisions services on the boxes through
  "APIs" (CLI-scrapers today) and have no reason to touch anything but
  the configuration parameters that are related to the provisioned
  services.

  In the cloud world, the "services" are "computational loads" and the
  big difference may be that the frequency of change can be quite high
  with the level of self-management/open APIs proposed by some of the
  participating companies.

  With this type of simple scenario I think the access control model
  can be made fairly simple (NOC->superuser, Services->Limited view
  of configurables and operationf). I like what I have seen in Andy's
  draft this far (one quick glance through it) and I think it makes for
  a good starting point for the discussion.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Feb 2010 11:34:53 -0800

Hi -

> Sent: Thursday, February 25, 2010 7:30 AM
...
>   a good starting point for the discussion.

Following up for clarification...

(1) When you write "Services->Limited view", does that mean that
all members of the "Service Provisioning team" have exactly the
same access rights to exactly the same bits of information?

(2) Where does the customer fit in this model?

Randy