Subject: Re: [OPSAWG] Basic ietf process question ...

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2012 18:59:03 +0200

Hi,

The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
concerning the revision of RFC1052 and discussing a new architecture for
management protocols. 

My personal take is that no one protocol, or one data modeling language
can match the operational requirements to configure and manage the wide
and wider range of hosts, routers and other network devices that are
used to implement IP networks and protocols. We should be talking
nowadays about a toolset rather than one tool that fits all. However,
this is a discussion that just starts. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Robert Raszuk
> Sent: Thursday, August 02, 2012 7:25 PM
> Cc: [email-masked]
> Subject: Basic ietf process question ...
> 
> All,
> 
> IETF documents have number of mandatory sections .. IANA Actions,
> Security Considerations, Refs, etc ...
> 
> Does anyone have a good reason why any new protocol definition or
> enhancement does not have a build in mandatory "XML schema" section
> which would allow to actually use such standards based enhancement in
> vendor agnostic way ?
> 
> There is a lot of talk about reinventing APIs, building network wide
OS
> platform, delivering SDNs (whatever it means at any point of time for
> one) ... but how about we start with something very basic yet IMHO
> necessary to slowly begin thinking of network as one plane.
> 
> I understand that historically we had/still have SNMP however I have
> never seen this being mandatory section of any standards track
document.
> Usually SNMP comes 5 years behind (if at all) making it obsolete by
> design.
> 
> NETCONF is great and very flexible communication channel for
> provisioning. However it is sufficient to just look at number of ops
> lists to see that those who tried to use it quickly abandoned their
> efforts due to complete lack of XML schema from each vendor they
happen
> to use or complete mismatch of vendor to vendor XML interpretation.
> 
> And while perhaps this is obvious I do not think that any new single
> effort will address this. This has to be an atomic and integral part
of
> each WG's document.
> 
> Looking forward for insightful comments ...
> 
> Best,
> R.
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 10:13:44 -0700

> this is a discussion that just starts.

NMS developers need to spend too many resources on translating
naming and other data-modeling specific details so they can be
usable within the application.  So if 1 data modeling language
is not used, then deterministic, loss-less, round-trip translation
between data modeling languages is needed.  Multiple
protocols are not the problem -- incompatible data from multiple
protocols is the problem.

> Dan

Andy

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Aug 2012 19:16:20 +0200

Yes. The question is whether a basic information model written in XML can be a useful starting point (trying to interpret the proposal made by Robert). 

Dan

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 8:14 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [OPSAWG] Basic ietf process question ...
> 
> > The OPSAWG/OPSAREA open meeting this afternoon has an item on the
> > agenda concerning the revision of RFC1052 and discussing a new
> > architecture for management protocols.
> >
> >
> > My personal take is that no one protocol, or one data modeling
> > language can match the operational requirements to configure and
> > manage the wide and wider range of hosts, routers and other network
> > devices that are used to implement IP networks and protocols. We
> > should be talking nowadays about a toolset rather than one tool that
> > fits all. However, this is a discussion that just starts.
> 
> NMS developers need to spend too many resources on translating naming
> and other data-modeling specific details so they can be usable within
> the application.  So if 1 data modeling language is not used, then
> deterministic, loss-less, round-trip translation between data modeling
> languages is needed.  Multiple protocols are not the problem --
> incompatible data from multiple protocols is the problem.
> 
> >
> > Regards,
> >
> > Dan
> >
> 
> Andy
> 
> >
> >
> >

---

From: David Harrington <[email-masked]>
Date: Thu, 02 Aug 2012 13:19:55 -0400

+1

--
David Harrington
[email-masked]
+1-603-828-1401

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 19:11:19 +0100

I think anyone with intimate experience of the Web Services standards
experiment (trying to use XML as if it was a Turing machine) would have
extreme doubts about any proposal to impose such a requirement.

It was not for no reason that many people came to refer to the Web
Services family of standards as "WS-splat". The words "small" and
"xml schema" don't really belong together,

Regards
   Brian Carpenter

On 02/08/2012 18:12, Robert Raszuk wrote:
> Hi Dan,
> 
>> We should be talking
>> nowadays about a toolset rather than one tool that fits all.
> 
> Just to clarify what I asked about .. I am not looking for a single tool
> or single protocol to be used to configure everything.
> 
> I am asking for small building block like xml schema (or something
> similar) to be part of each new IETF proposal or protocol change. IMHO
> only that can allow any further more fancy abstractions and tools to be
> build and used in practice.
> 
> Best regards,
> R.
> 
> 
> 
>> Hi,
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 20:17:30 +0200

Hi Brian,

Perhaps we understand a different thing by "xml schema" As example what 
I had in mind when asking this question was the example from "Appendix 
A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where 
while perhaps not yet complete it does provide decent representation of 
one of the popular service today.

That's what I had mind asking why such appendix isn't a mandatory part 
of each new protocol extension.

It has very little to do with Web Services you may be referring to.

Many thx,
R.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Aug 2012 07:58:03 +0100

> one of the popular service today.

There are certainly cases where systematic metadata are useful; I can't judge
whether VPN configuration is one of them, but I can easily believe it. In such
a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else
you might choose.

> of each new protocol extension.

That's an enormous leap that I just don't understand. Most protocols don't
need that sort of configuration complexity.

> It has very little to do with Web Services you may be referring to.

Yes it does. It's exactly because of a doctrinaire approach that whatever
it is, it should be represented by an XML schema, that WS-splat became
such a horribly complex matter.

Again: no problem with creating XML schemata where they are useful. But
making them mandatory would be just as bad as making MIB modules mandatory,
IMHO.

    Brian

>>>> agenda

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 03 Aug 2012 09:22:10 +0200

Hello Brian,

> need that sort of configuration complexity.

Hmmmm I am of the opinion that most protocols requires configuration. I 
am also of the opinion that each vendor chooses an original way to 
configure their network elements.

Therefor if you do not define up front a standard based of configuring 
given routing protocol you will end up with exactly what we have today 
.. zoo of various different CLI commands to enable the exact same 
protocol across more then one vendor box.

Are you saying that this is ok ?

Or are you saying that there is simpler way to enable netconf based 
unified way to configure protocols and services on your network other 
then providing per component "xml schema" with subsequent schema 
extensions as part of IETF standardization process ?

To make it a bit more explicit ... do you really need to study 5 user 
manuals or google 5 times to enable IGP or BGP or even configure NTP 
across 5 different router OS running in your network ???

 > Again: no problem with creating XML schemata where they are useful.
 > But making them mandatory would be just as bad as making MIB modules
 > mandatory, IMHO.

Aha .. so you are saying that MIBs are not mandatory .... Very 
interesting. So I guess SSH to the routers and box by box cli 
provisioning is here to stay for a while I think :(

Best regards,
R.

---

From: t.petch <[email-masked]>
Date: Fri, 3 Aug 2012 09:22:53 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 03, 2012 7:58 AM
> a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever
else

I don't:-)  I think that XML is a disaster, lacking any fundamental
principles or coherence, something that I see with its use for
protocols such as Netconf.

By contrast, I never saw such problems with SNMP and ASN.1,
except where the IETF had limited its use thereof (which was
probably the right call).

Tom Petch

<snip>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 15:29:45 +0200

> provisioning is here to stay for a while I think :(

Robert,

you may want to take a closer look at the data models currently being
defined in the NETMOD working group. Please review them and send any
comments.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 03 Aug 2012 16:31:42 +0200

Hi Juergen,

Many thx for the great suggestion !

However perhaps you are much more knowledgeable in that area and could 
recommend which model fit the best the requirement to standardize 
configuration of any new protocol or protocol extension at least in the 
space of routing and routing protocols or services being based on them ?

As you know the current IRS framework driven by junisco is trying to 
come with common API to the routing system agreed across vendors. This 
is great as attempts never happened in the past.

But if we are at this phase I think creating a network elements 
abstraction layer and be able to configure/monitor any protocol and 
service at the unified way is one of the building blocks we should start 
with. And of course I think this is very clear to everyone if it is not 
made mandatory in each draft as new section or appendix it is just not 
going to happen in practice.

Best regards,
R.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 17:31:00 +0200

On Fri, Aug 03, 2012 at 04:31:42PM +0200, Robert Raszuk wrote:
> service at the unified way is one of the building blocks we should
> start with. And of course I think this is very clear to everyone if
> it is not made mandatory in each draft as new section or appendix it
> is just not going to happen in practice.
> 

Writing data models that are implementable on multiple platforms is
non trivial. We started working on your "building block" but it will
take time. And after all, a data model is only worth something if it
gets implemented.  A mandatory section does not help much with all of
this. What helps is people who commit time to work on it, who review
stuff, producing good and hopefully widely implementable models.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Aug 2012 09:24:03 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, August 02, 2012 10:13 AM
...
> protocols is the problem.
...

Picking a single language or set of round-trip translatable languages
also isn't enough.  Its a fact of life that vendors will produce
models and implementations that are slightly, or even radically different.
The differences aren't necessarily even intentional, but nonetheless
introduce the need to talk about "similar" models and "operationally
equivalent" configurations, where the transformations needed to go
from what will do the job on one piece of equipment to what will
work on another may be substantial.  (From an implementation perspective
it might be better to think in terms of transformations necessary to go
from a common model of desired operational characteristics to the
dial tweaks and button pokes necessary to get a device to do the right
thing.)  Since great minds often think alike, even in the absence
of standards, there is not necessarily a formal "derived from" or
"subclass" or "common aspect" relationship between the definitions.
This may be an obvious use case for XSLT, but as far as I know nothing
has been done about *standardizing* such usage, other than discussions at the
IAB workshop oh-so-many years ago, and some ISO/ITU discussions in
the 1990s about eventual applications of the General Relationship
Model and the management domain/policy stuff in GDMO land.

Randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 02 Aug 2012 19:12:21 +0200

Hi Dan,

Best regards,
R.

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 6 Aug 2012 19:56:07 -0700 (PDT)

> provisioning is here to stay for a while I think :(

Well there is one example I can think of where this didn't
become the norm -- DOCSIS --  where a small customer community forced vendors 
through a process of standardization (trekking to Broomfield CO USA oh joy) 
in order for them to sell gear. And that included a set of tests for 
the SNMPv3 agent with mandated read-write mib modules among other 
mgmt protocols employed. 

Maybe this was a simpler problem than that's being discussed here.
But given the VC activity/startups on virtualized networking
can imagine that other chunks of networking infrastructure 
amenable to standardized configuration will follow suit.
Once that occurs then standards bodies codify industry practice.

Mike MacFaden

 |Tue, 2 Oct 2001 15:34:22 -0700
 |My amendment to Postel's Law:
 |Be liberal in what you accept, conservative in what you send, and add a
 |knob so that you can interoperate even if the other guy blows it.
 |
 |Tony