Re: [NGO] NETCONF-related sessions at IETF 70

[Balazs Lengyel <[e-mail]>]

Hello Simon, Sharon,
We also have John Dickinson from DNSOP. He seems a very promising candidate.
Balazs

John Dickinson <[e-mail]> wrote:
 > > There has, for example, been some discussion in the dnsop WG about
 > > developing a protocol for configuring and controlling nameservers 
(http://tools.ietf.org/wg/dnsop/minutes?item=minutes69.html
 > > ) and I am one of the authors of a draft 
(http://www.ietf.org/internet-drafts/draft-arends-nscp-00.txt
 > > ) that suggests using NETCONF.
 > >
 > > The biggest issue for me in choosing NETCONF was and is to be sure I
 > > am using NETCONF appropriately and that it really is the correct
 > > solution to my problem.

I have read your draft and I do believe (and hope!) that NETCONF is
a good solution to this problem.

 > > I am currently looking at such things as, what
 > > would be an appropriate data model, how to correctly use capabilities
 > > and how to engineer things that are not strictly configuration, such
 > > as control commands, monitoring and statistics gathering.

In your draft you also listed:

   Be extensible to allow implementors to extend to cover new objects
   and methods.

Maybe not suprising, but these are exactly the problems that YANG is
designed to help you with.

To be more specific, with YANG, you can write a standard data model
with the the (most) common configuration parameters.  Vendors can then
augment this standard data model with vendor-specific config params.

As an example (NOTE: I don't know what parameters actually would make
sense, this is just an example):

   container server {
       container panorama {
           list view {
               key view-name;
               leaf-list match-client { type inet:ip-prefix; }
               leaf recursion         { type boolean; }
               ...
           }
       }
   }

Then vendor X can add its own proprietary stuff:

    augment /dns:server/dns:panorama/dns:view {
        leaf funky-cache-option { ... }
        ...
    }

And in the NETCONF XML you might see:

    <server>
      <panorama>
        <view>
          <view-name>mybiew</view-name>
          <match-client>192.168.23.0/24</match-client>
          <match-client>172.16.30.0/16</match-client>
          <recursion>true</recursion>
          <x:funky-cache-option>magic</x:funky-cache-option>
        </view>
      </panorama>
    </server>

The same goes for commands (rpcs).  You can define standard rpc, and
vendors can e.g. add new rpcs, or augment the standard rpcs.


/martin


_______________________________________________
NGO mailing list
[e-mail]
http

---------------------------------------------------------------------------------------

Simon Leinen wrote:
> Sharon Chisholm writes:
>> It would be good to reserve the timeslot and the room for an
>> informal meeting.
> 
> OK, so let's go ahead like this: As I suggested, we cancel the short
> NETCONF slot (TUESDAY, December 4, 2007 1850-1950), and try to keep
> the room for informal discussions.
> 
>> Now that the protocol extensions and the content specification
>> discussions seem to have homes, what I think would be interesting is
>> to try to identify a working group interesting in being a guinea pig
>> for defining some NETCONF content for their work. This session could
>> work out the plan to make that happen.
> 
> IPFIX seems to be a good candidate, because they have development of
> "an XML-based configuration data model that can be used for
> configuring IPFIX devices and for storing, modifying and managing
> IPFIX configurations parameter sets" on their brand-new charter, which
> also notes that "This work will be performed in close collaboration
> with the NETCONF WG".
> 
> IPFIX meets on Tuesday 1300-1500, and I'll be chairing the meeting
> (since the real IPFIX chairs won't be in Vancouver), so I can invite
> interested participants to our informal meeting on Tuesday evening.
> 
> OK?
> 
>> Either that or for more detailed discussion of the items in the
>> updated NETCONF charter.
> 
> I hope two hours are sufficient for that.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]


_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo