Subject: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07

From: Gerhard Muenz <[email-masked]>
Date: Tue, 03 Aug 2010 14:11:17 +0200

Dear all,

In the IPFIX WG, we will have a second WGLC for
draft-ietf-ipfix-configuration-model-07.

It would be nice if some YANG experts could have a look at the document,
too.

The YANG module was validated with pyang and seems to be correct.
Nevertheless, you might have further comments.

We also tried to make the document compliant with the YANG guidelines.
If you think that something is missing or should be changed, please let
me know.

Thanks a lot for you help,
Gerhard

-------- Original Message --------
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-07.txt
Date: Tue,  3 Aug 2010 04:45:02 -0700 (PDT)
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Flow Information Export Working
Group of the IETF.

	Title           : Configuration Data Model for IPFIX and PSAMP
	Author(s)       : G. Muenz, et al.
	Filename        : draft-ietf-ipfix-configuration-model-07.txt
	Pages           : 123
	Date            : 2010-08-03

This document specifies a data model for configuring and monitoring
Selection Processes, Caches, Exporting Processes, and Collecting
Processes of IPFIX and PSAMP compliant Monitoring Devices using the
NETCONF protocol [RFC4741].  The data model is defined using UML
(Unified Modeling Language) class diagrams and formally specified
using YANG [I-D.ietf-netmod-yang].  The configuration data is encoded
in Extensible Markup Language (XML).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-07.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Aug 2010 22:40:13 -0700

> If you think that something is missing or should be changed, please let

I have one concern already, which is the usage of
ifIndex or ifName for identifying an interface.  This is problematic.
Eventually there will be an interfaces module in YANG, even if it is
just scaffolding so we know where all the vendor per-interface config belongs.

Is there an assumption that the NETCONF server co-exists with an SNMP agent?
It looks that way.  IMO, the NETCONF/SNMP interactions are critically important
to interoperability.  It should be designed, not ad-hoc.  I don't want to hold up
ipfix-psamp.yang, but I don't want to let it constrain the eventual interfaces.yang
solution either.

(So a future Iipfix-psamp.yang revision may wish to support the YANG interfaces table,
which will probably not be indexed by either ifInex or ifName.)

> Thanks a lot for you help,

Andy

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

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 05 Aug 2010 09:27:19 +0200

Hi Andy,

Thank you for your answer. I did not pay attention to this point.

> Is there an assumption that the NETCONF server co-exists with an SNMP agent?

For commercial routers, this will very probably be the case.
However, the configuration model should not depend on an SNMP agent
implementing the IF-MIB module. You are right that this is unclear at
the moment.

> ipfix-psamp.yang, but I don't want to let it constrain the eventual interfaces.yang

Can you propose an intermediate solution?

At the moment, we allow ifIndex or ifName for identifying an interface.
These are fine for devices which do have an SNMP agent.
Shall we add a third neutral option for devices without SNMP?

> which will probably not be indexed by either ifInex or ifName.)

Sure. So, we should take care that the model can easily be extended by a
new option to identify an interface. As far as I understand, we can use
the augment statement to add another leaf to choice OPLocation.

Gerhard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 09:48:40 +0200

> Thank you for your answer. I did not pay attention to this point.

I did share Andy's concerns when I skimmed the document but then I
thought it is also unfair to raise a flag because there is nothing
better in place and so far we have not even a WG chartered to produce
something more appropriate.
 
> > It looks that way.  IMO, the NETCONF/SNMP interactions are
> > critically important to interoperability.  It should be designed,
> > not ad-hoc.  I don't want to hold up ipfix-psamp.yang, but I don't
> > want to let it constrain the eventual interfaces.yang solution
> > either.
> 

Supporting several different ways to identify an interface is not a
good long term solution overall. Perhaps the best we can do is to
accept the fact that there is nothing better yet but to be prepared
that a future revision might change this part of the data model.

> the augment statement to add another leaf to choice OPLocation.

I would rather see this "fixed" in place once the document is up for
revision. BTW, is there already implementation with this config model?
I am not following IPFIX in all detail so I am not sure how mature
things are (implementation experience always helps to understand
details better).

All that said and reading the DESCRIPTION of ifName again, I consider
it very likely that semantically ifName _values_ are going to be used
to refer to interfaces in YANG. How this is done (e.g. by direct
reference to the IF-MIB or via a separate YANG typedef that is
semantically equivalent) I do not know (although I do have an opinion
;-).

/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: Andy Bierman <[email-masked]>
Date: Thu, 05 Aug 2010 01:23:48 -0700

> Can you propose an intermediate solution?

not yet.  I prefer a solution that actually attempts to provide machine
readable structure to the if-name, and make if-index go away.
Martin started on a solution (e.g., if-name is a string and some
YANG extension-stmt defines the embedded structure).  I think that
has the most promise.

Andy

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 05 Aug 2010 10:44:13 +0200

Hi Jürgen,

> that a future revision might change this part of the data model.

Should we mention this somewhere in the draft? And in the module itself?

> things are (implementation experience always helps to understand

No, there is no implementation.

However, we have two NetFlow/IPFIX implementations in mind: Cisco
Flexible NetFlow and Vermont (which is a software probe).

> semantically equivalent) I do not know (although I do have an opinion

I share your opinion regarding the interfaces.

I also assume that ifName will be used in practice, just like in the
Cisco CLI.

What I can say for Vermont, there are no plans to implement an SNMP
agent because we do not see a use-case. As it is done in the current
Vermont configuration, we will use ifName to identify an interface on a
PC (e.g. "eth0").

Hm, maybe we can decide to remove ifIndex and entPhysicalIndex?
Would this address your concerns at least partially?

Regards,
Gerhard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 10:56:09 +0200

On Thu, Aug 05, 2010 at 10:23:48AM +0200, Andy Bierman wrote:
 
> not yet.  I prefer a solution that actually attempts to provide
> machine readable structure to the if-name, and make if-index go
> away.  Martin started on a solution (e.g., if-name is a string and
> some YANG extension-stmt defines the embedded structure).  I think
> that has the most promise.

Given the wide variety of different ifNames I have seen, I doubt this
will work out. I am sceptic that we will do any better than saying
what essentially is in the DESCRIPTION of ifName.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Aug 2010 11:05:56 +0200

Should I mention the fact that this discussion shows how important is to
have the core YANG modules standardized as fast as possible? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Thursday, August 05, 2010 8:40 AM
> To: Gerhard Muenz
> Cc: NETMOD Working Group
> Subject: Re: [netmod] Feedback on 
> draft-ietf-ipfix-configuration-model-07
> 
> > It would be nice if some YANG experts could have a look at the 
> > document, too.
> > 
> > If you think that something is missing or should be changed, please 
> > let me know.
> > 
> 
> 
> I have one concern already, which is the usage of ifIndex or 
> ifName for identifying an interface.  This is problematic.
> Eventually there will be an interfaces module in YANG, even 
> if it is just scaffolding so we know where all the vendor 
> per-interface config belongs.
> 
> critically important to interoperability.  It should be 
> designed, not ad-hoc.  I don't want to hold up 
> ipfix-psamp.yang, but I don't want to let it constrain the 
> eventual interfaces.yang solution either.
> 
> (So a future Iipfix-psamp.yang revision may wish to support 
> the YANG interfaces table, which will probably not be indexed 
> by either ifInex or ifName.)
> 
> 
> > Subject: [IPFIX] I-D 
> > Action:draft-ietf-ipfix-configuration-model-07.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 11:13:36 +0200

> Would this address your concerns at least partially?

Partially.

I do not understand entPhysicalIndex or entPhysicalName since they are
supposed to refer to a "linecard". Is the assumption here that a
linecard has exactly one interface? Or is this an observation point
attached on purpose to multiple interfaces of a linecard?

I could probably ask many more questions concerning the YANG model but
so far I did not have time to read things carefully. In general, I
think it would be valuable to have more typedefs for basic IPFIX
concepts. See for instance observation domain ID. RFC 5101 gives the
value 0 a special meaning, this is not reflected in the
observationDomainId leafs (and one of the three leafs does not even
refer to RFC 5101). I personally would also prefer to change leaf
names to make the names of leafs unique within the module (makes
communication easier) and I would prefer using YANG dashed writing
style.

But to be really prepared, I would have to read the whole thing (123
pages) and use tools to inspect the structure of the data model or
make drawings myself. And then I would have to spent time checking for
consistency between the data model and what is in the class diagrams
and whether the semantics in the supporting text are also reflected in
the YANG definitions. And then there are MIB modules to be consistent
with and of IPFIX and PSAMP itself. Sometimes, having less overlapping
text makes things simpler.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Aug 2010 02:15:41 -0700

> what essentially is in the DESCRIPTION of ifName.

Of course there is a description-stmt, but there can
also be out-of-band vendor extension-stmts.

The structure is different, but predictable for a given subset
of a given vendor's products, right?

  extension my-if-structure { ... }

  acme:my-if-structure {
     acme:if-separators "/ .";
     leaf machine-id {
       type string { length 4; }
     }
     leaf slot { type uint16; }
     leaf port { type uint32; }
     ...
  }

Then the vendor needs to provide this YANG as an annotation somewhere
and the standard <if-name> leaf can be parsed semi-automatically.

We don't need to get the IETF to agree on the uber-if-name definition.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 11:44:51 +0200

> and the standard <if-name> leaf can be parsed semi-automatically.

We can choose to have slot and port leafs, e.g.

   list interface {
      key "name";
      leaf name { ... };
      leaf port { ... };
      leaf slot { ... };
   }

or we can follow the old MIB approach where the physical port sitting
in a containment hierarchy representing the physical structure of the
device can point to logical interfaces. Both are workable solutions,
none of them requires that we agree on the format of an interface name
or that we have to parse and interpret the name itself.

The more fun part will be what we do with interfaces that come and go,
what config means for interfaces that come and go etc. And boxes
differ here - some boxes have interfaces where the name carries a
logical function (vlan42) or discovery order (eth0) while others have
interfaces where the name carries structural information. Once you
flip interfaces, the results you get when say ipfix config refers to
an interface name will depend quite a bit on the naming scheme (eth0
might still be a valid interface, even though it now sits in a
different slot, vlan42 might still do the expected, the reference to a
physical slot might be invalid). It may make sense to distinguish
between interface names that are associated with a physical location
and names that are associated with a function so that config snippets
can use what makes most sense. I might prefer to write firewall rules
for an interfaces called "customer-xyz" so that I do not have to
change firewall rules if I move the customer to a different interface
(so I am talking about ifAlias vs ifName in MIB terms, although
IF-MIB's ifAlias does not guarantee uniqueness I think).

Yes Dan, this is a crucial piece of work to be done.

/js

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 05 Aug 2010 13:07:32 +0200

> attached on purpose to multiple interfaces of a linecard?

The later is true. From RFC5101:

      An Observation Point is a location in the network where IP packets
      can be observed.  Examples include: a line to which a probe is
      attached, a shared medium, such as an Ethernet-based LAN, a single
      port of a router, or a set of interfaces (physical or logical) of
      a router.

> refer to RFC 5101). 

More typedefs for IPFIX-specific values are a good suggestion. I'll try
to include that.

> I personally would also prefer to change leaf

Is there a general preference for dashed writing style in YANG?
MIB object names do not use it.

> text makes things simpler.

I see that you understand the complexity of the defining such a model :)
Of course, it would be nice if reviewers would check all these details,
but I do not think that this whole effort can be expected.

The most important feedback from the NETMOD working group is what you
already offer right now: comments about the form of the document and
specific design issues of the module.

Thanks,
Gerhard

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Aug 2010 13:26:09 +0200

>       port of a router, or a set of interfaces (physical or logical) of

This does not line up. RFC 5101 leaves it pretty open what an
observation point is and only provides examples. The YANG
configuration module is much more restrictive. This might be what the
WG wants but clearly what is in the YANG model does not follow
directly from this quote of RFC5101.
 
> MIB object names do not use it.

The YANG language plus all modules produced or in the making in the
NETMOD/NETCONF WGs use the hyphen style. You may want to discard my
second comment concerning uniqueness of identifiers - I might actually
not like the idea on second thought (since we have a path notation
available that can be used easily and avoid extremely long and
difficult to read identifiers).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Aug 2010 16:28:59 +0200

Hi Gerhard,

I have the following comments/questions:

1. You only have one revision covering the entire history of the module.
I would expect at least one revision of the module for each revision of
the I-D.

2. Given the large number of declared features (17), perhaps it would be
better to have multiple modules, e.g. separate modules for "meter",
"exporter", "collector" and "psamp". Have you considered this option?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Aug 2010 16:43:45 +0200

> I would expect at least one revision of the module for each revision of

I think we decided to follow the SMIv2 model (this is my understanding
of section 4.6 in the YANG usage document) where a revision is used to
track "published" modules, where "published" means published as RFC
(or published by a vendor by shipping it with their hard-/software.
So I expect only one revision clause which just states that this is
the initial revision.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Aug 2010 17:20:06 +0200

> So I expect only one revision clause which just states that this is

Well, the last paragraph of section 4.7 in
draft-ietf-netmod-yang-usage-09 is IMO quite clear:

    "It is acceptable to reuse the same revision statement within
    unpublished versions (i.e., Internet-Drafts), but the revision date
    MUST be updated to a higher value each time the Internet-Draft is re-
    published."

I think this is appropriate since even an I-D is a form of publication,
and may actually get implemented, so it seems helpful to state clearly
the revision history.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Aug 2010 09:04:13 -0700

> and may actually get implemented, so it seems helpful to state clearly

This is a bit too strict.
Sometimes the I-D is updated and the YANG module within the I-D
has not been touched. IMO, s/MUST/SHOULD/ (w this explanation added)
should be made to the usage guidelines.

I.e, revision date MUST be updated if any contents of the module
has changed.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Aug 2010 18:06:14 +0200

On Fri, Aug 06, 2010 at 05:20:06PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v P?? 06. 08. 2010 v 16:43 +0200:

I disagree. The product of a WG is the RFC and while there is value in
documenting the differences between subsequent RFCs for the users of
RFCs, I do not see the need to document for the users of RFCs the
differences between working documents. We should not encourage people
to actually ship implementations of I-Ds.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Aug 2010 09:17:25 -0700

> to actually ship implementations of I-Ds.

I agree this is a slippery slope, but we want to encourage early implementation,
so we can find the bugs ASAP.  This also applies to readers of the extracted
YANG module, who want to know if the work-in-progress changed at all.

Vendors are going to ship I-Ds at their peril.
If the revision date is updated, YANG tools can easily
deal with new and old revisions.  Also, opensource projects
may be intended to support IETF work-in-progress, so they
are harmed by improper updating of the revision date.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Aug 2010 18:46:01 +0200

> are harmed by improper updating of the revision date.

Actually, my comment was not about improper updating of the revision
date - every revision of that I-D in fact uses a new revision date for
the module - but rather about the practice of "forgetting" the old
revisions and moving all descriptions from the old revisions to the most
recent one.

I would prefer to keep the old revision info intact to be able to
clearly see the revision in which each change happened.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Aug 2010 10:07:45 -0700

> clearly see the revision in which each change happened.

IMO this is not needed because the I-D already has a change log section.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Aug 2010 22:56:20 +0200 (CEST)

Hi,

> Nevertheless, you might have further comments.

I have done a very brief review, but I won't have time in the very
near future to do a deeper review, so I thought I should send what I
had:

1.  IMO, there should be one (1) revision statement, which should not
    contain the history of all drafts; it should simple state that
    this is the initial revision.

2.  I agree with Juergen that it might be a good idea to use
    dash-style-names instead of loCamelCase, in order to have a
    consistent IETF style.

3.  /ipfix/collectingProcess/exportingProcess is a leafref to
    /ipfix/exportingProcess/name.  exportingProcess is optional based
    on the 'exporter' feature.  Maybe
    /ipfix/collectingProcess/exportingProcess also should have
    "if-feature exporter;"?

4.  Ditto for /ipfix/collectingProcess/exportingProcess.

5.  In the when expressions, identityref values should have a prefix.
    E.g. 
       when "../cacheMode != 'immediate'" {
    should be
       when "../cacheMode != 'ipfix:immediate'" {

    (this is actually not clear from the YANG spec...)

6.  The leaf ipfixVersion in grouping commonExporterParameters and
    grouping fileWriterParameters uses a default value of "10".  These
    leafs should probably have a reference statement.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Aug 2010 18:30:44 +0200

> It would be nice if some YANG experts could have a look at the document,

Another observation: Perhaps it would be useful to introduce extra
containers encapsualting the entries of each list, e.g.

container collectingProcesses {
    list collectingProcess {
        ...
    }
}

As it is now, entries from different lists could be freely interleaved,
for instance

<collectingProcess>...</collectingProcess>
<exportingProcess>...</exportingProcess>
<collectingProcess>...</collectingProcess>

This is usually not very desirable.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C