Subject: [Netconf] Network-wide Configuration Bar BoF (M:1700-1930)

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jul 2010 19:01:32 -0700

Hi,

I added the net-wide-config Bar BoF to the Wiki:

http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78

Hope everyone at the Maastricht meeting can be there.
(Where 'there' is TBD -- a pub to be selected Saturday night :-)

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:04:54 +0200

Well - you listed time as 17:00 - 19:30 on Monday. We have the open
OPSAREA meeting runing until 17:20, and I hope that you and all or most
of the potential participants in the BarBOF will attend this, especially
as there are a couple of NETMOD related items on the agenda. 

For me the time slot during the meeting times is not good as I need to
cover for Ron (who cannot make the meeting in Maastricht) in OPSEC
(17:40 to 19:40). Any reason for not holding the barBOF after meeting
times? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Friday, July 23, 2010 5:02 AM
> To: NETCONF; NETMOD Working Group
> Subject: [Netconf] Network-wide Configuration Bar BoF (M:1700-1930)
> 
> Hi,
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jul 2010 05:09:53 -0700

> (17:40 to 19:40). Any reason for not holding the barBOF after meeting

oops -- my intent was to place the BoF after the break following
the OPSAREA meeting.  Martin had requested that Nigel be present,
who could not attend later on.  That is why it was 5pm.

Should I change it to 17:40, 20:00, something else?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jul 2010 10:59:29 -0700

> (Where 'there' is TBD -- a pub to be selected Saturday night :-)

I changed the time-slot:  now 17:40 to 20:00.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jul 2010 03:58:51 -0700

> I changed the time-slot:  now 17:40 to 20:00.

The network-wide config Bar BoF will be held at the bar in the lobby
of the MH Maastricht hotel from 17:40 to about 19:40.
After that, some people will be going to the city center
for food and more beer.

Andy

---

From: Benoit Claise <[email-masked]>
Date: Wed, 28 Jul 2010 12:07:30 +0200

Andy,

Any conclusions from this Bar BoF?

Regards, Benoit.
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Jul 2010 05:57:02 -0700

> Any conclusions from this Bar BoF?

There was an interesting discussion.
This topic means different things to different people.
There is some concern that leaf-level device interoperability
within the NETCONF database will be difficult to achieve,
due to vendor product differentiation and inherent
complexity of mixing config APIs within a single server.

Solution discussion summary:

 - use of sophisticated config mechanisms to reduce the amount
   of 'raw config data' that a client must understand
   about the servers
   - use of dynamic defaults
   - use of XPath expressions and server-specific meta-data
     (e.g., XPath variables) to allow the server to fill in
     the raw config data instead of the client

 - use of a network view data model to identify all the servers
   and the config data associated with each server.  The model
   would focus on the inter-connections between the servers
   and the simplified view of the network service being managed.
   This is what we called a network model.

 - use of the TM Forum SID as the network model to manage the NETCONF
   servers

 - use of YANG as the top-level model which would integrate somehow
   with YANG device models;  not clear if a standard algorithm for
   converting from network to device-level would be possible or mandatory.

There was agreement that the architecture requires a 2-tier 'compiler' approach.
The client should only need to understand the network model (e.g. source code)
and the NETCONF server should somehow translate the content from this
model to device-specific content (e.g., ASM code).  It is understood that
the client may lose visibility of the device-level config contents
if the network model is used instead.

There is also a need to tune the device-level content sometimes.
A traffic shaping example was discussed.  Let's say a router
has 5 ways to control traffic shaping.  A network model would
focus on the common properties and not the details of any specific
method.  The client would provide the desired parameters and the
server would pick 1 of its 5 methods and setup the raw device config
data accordingly.  But if the client wants more control than that,
a mechanism to force the server to pick a specific method of the 5
would be needed.  It is not clear what this solution would look like.

Next steps:
  - Phil Shafer will publish an I-D on network-wide config soon
  - produce 1 or more I-Ds and either have a BoF at IETF #79
    or recharter the NETMOD WG to work on this
  - need to setup a conference-call to discuss SIM further
    and possible I-D on this approach

Andy