Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion

[Benoit Claise <[e-mail]>]

On 1/15/2018 10:10 PM, Wayne Tackabury wrote:
> Regarding SCTP, as of this writing, it is not and can not be 
> mandatory.  Not many commercial collectors support it.  I've found 
> this to be a bit of an "elephant in the room" on the RFC directions.
No disagreement.
http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/

Regards, B.
> To be perfectly practical, as things have emerged since the days of 
> RFC[s] 510x, SCTP has not been made sufficiently stable in linux 
> kernel and user interfaces that it could support carrier-grade flow 
> conveyance dependencies. There are probably other nontechnical 
> barriers to acceptance. To be sure, this is unfortunate, since SCTP 
> still admirably meets the original design goals.
> Without getting into it, where I'm aware of implementations that meed 
> tp make use of the "messaging" benefits of SCTP over UDP, the 
> less-than-standard path of TCP over some defacto standard port  has 
> been used.  Others may know of different implementations, but this is 
> based on subjective, but voluminous, input from implementations I've 
> seen at customer sites and discussions with colleagues at different 
> vendor enterprises.  Again, this is not an editorial on technical merit.
> Regards,
> Wayne
>
>     ----- Original message -----
>     From: Juergen Schoenwaelder <[e-mail]>
>     Sent by: "IPFIX" <[e-mail]>
>     To: Andrew Feren <[e-mail]>
>     Cc: 'Marta Seda' <[e-mail]>, "Aitken, Paul"
>     <[e-mail]>, "'[e-mail]'" <[e-mail]>
>     Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
>     Date: Mon, Jan 15, 2018 1:51 PM
>     I fail to see why this would be the case. (But I agree that renaming
>     identifiers for the sake of renaming them is having little value.)
>
>     /js
>
>     On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:
>     > In particular renaming identifiers would break any
>     implementations of RFC 7373 "Textual Representation of IP Flow
>     Information Export (IPFIX) Abstract Data Types".
>     >
>     > -Andrew
>     >
>     > ________________________________
>     > From: IPFIX [[e-mail]] on behalf of Gerhard Muenz
>     [[e-mail]]
>     > Sent: Saturday, January 13, 2018 4:43 AM
>     > To: Benoit Claise; Aitken, Paul; 'Marta Seda'
>     > Cc: '[e-mail]'
>     > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
>     >
>     >
>     > Marta, all,
>     >
>     > A few additional thoughts regarding your questions:
>     >
>     > 1) I would not expect that not following current naming
>     convention hinders implementation of RFC 6728. On the other hand,
>     if we change just the names of the identifiers, we lose
>     interoperability with older implementations that may exist.
>     >
>     > 2) I think that it is reasonable that destinationIPAddress is
>     mandatory because network management systems should be able to
>     query the IP address to which an Exporting Process sends data. As
>     Paul stated, RFC 6728 does not say how the destination IP address
>     is set.
>     >
>     > 3) SCTP is still a mandatory transport for a compliant
>     implementation of an IPFIX device, not a feature. See:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=qunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=M0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=>
>     >
>     > Best regards,
>     > Gerhard
>     >
>     >
>     >
>     > On 10.01.2018 08:33, Benoit Claise wrote:
>     > Hi,
>     > Marta, Benoit,
>     >
>     > 1. Are there efforts to update other RFCs to meet the latest
>     YANG best practices?
>     > Yes. Ex:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=Dml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w_zw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=whhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=>
>     > The goal is to specify NMDA-compliant
>     (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=gGNMKyVcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&e=>)
>     YANG modules
>     >
>     > 2. Since the IPFIX WG closed, there has been little ongoing
>     IPFIX work in the IETF. Is there a specific need to update RFC
>     6728 rather than just recognising it as a product of it's time?
>     > This type of feedback should come from implementation experience.
>     >
>     > Regards, Benoit
>     > Note that it's > 5 years old.
>     >
>     > Also see @PJ inline:
>     >
>     >
>     > On 09/01/2018 16:01, Benoit Claise wrote:
>     > Hi Marta,
>     > Hello,
>     > I am reaching out to the IETF IPFIX mailing list  on some issues
>     I have run into with respect to RFC 6728 “Configuration Data Model
>     for the IP Flow Information Export (IPFIX)  and Packet Sampling
>     (PSAMP) Protocols”
>     >
>     >
>     >   1.  RFC 6728 doesn’t meet the latest Yang Best Practices
>     (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=SSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.proofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=>)
>       Leaf identifiers are camel case (e.g., destinationAddress
>     instead of destination-address).  Are there any ongoing efforts to
>     update RFC 6728 to meet the latest best practices?
>     > Not as far as I know.
>     >
>     > Regards, Benoit
>     >
>     >
>     >   1.
>     >
>     >    Identifiers SHOULD follow a consistent naming pattern
>     throughout the
>     >    module.  Only lower-case letters, numbers, and dashes SHOULD
>     be used
>     >    in identifier names.  Upper-case characters and the underscore
>     >    character MAY be used if the identifier represents a
>     well-known value
>     >    that uses these characters.
>     >
>     >    Identifiers SHOULD include complete words and/or well-known
>     acronyms
>     >    or abbreviations.  Child nodes within a container or list
>     SHOULD NOT
>     >    replicate the parent identifier.  YANG identifiers are
>     hierarchical
>     >    and are only meant to be unique within the the set of sibling
>     nodes
>     >    defined in the same module namespace.
>     >
>     >    It is permissible to use common identifiers such as "name" or
>     "id" in
>     >    data definition statements, especially if these data nodes
>     share a
>     >    common data type.
>     >
>     >    Identifiers SHOULD NOT carry any special semantics that
>     identify data
>     >    modelling properties.  Only YANG statements and YANG extension
>     >    statements are designed to convey machine readable data modelling
>     >    properties.  For example, naming an object "config" or
>     "state" does
>     >    not change whether it is configuration data or state data.  Only
>     >    defined YANG statements or YANG extension statements can be
>     used to
>     >    assign semantics in a machine readable format in YANG.
>     >
>     >
>     >   1.  I generated the RFC 6728 yang tree (see attached).  The
>     tcp and udp exporting processes support a destinationIPAddress
>     (line 400, 455) which is mandatory.  The type is inet:ip-address.
>     >
>     >      *   A collector may be doing load balancing.  Rather than
>     managing ip-addresses, the collector may be using DNS (an exporter
>     could resolve from the domain name where the collector is located).
>     >
>     > @PJ: Load balancing and DNS are independent. Load balancing
>     IPFIX is probably a bad idea since templates need to be available
>     on all collectors, and out of step sequence numbers in the data
>     records would cause spurious reports of lost data. If DNS is used
>     to obtain the collector's address, arguably it should be a
>     one-time lookup rather than incurring a DNS lookup per export packet.
>     >
>     >
>     >
>     >   1.
>     >
>     >      *
>     >      *   The collector address may be learnt via other methods
>     (e.g., through DHCP options)
>     >      *   A choice statement to select what method to use seems
>     more appropriate than what is presently in RFC 6728.  For example
>     (use some shorthand)
>     >
>     > choice destination-method{
>     >                 case destination-address{
>     >                                 leaf destination-address// rw
>     with type inet:host
>     >                 }
>     >                 case dhcp-acquired-address{
>     >                                 container dcp-acquired-address{
>     >                                                 leaf
>     destination-ip-address inet-address //ro
>     >                 }
>     > }
>     >
>     >                                 However I can’t augment to
>     ietf-ipfix because destinationIPAddress is mandatory.  Can the
>     group suggest methods to (a) change the destinationIPAddress type
>     and (b) allow a choice?
>     >
>     > @PJ: The selection could also be done out of band so the
>     exporter need not know how the address is determined. eg a
>     configuration system could determine the address by any of these
>     methods or otherwise, and impose that address using the current model.
>     >
>     >
>     >
>     >   1.  RFC 6728 mandates SCTP transport.  I understand the logic
>     behind this (IETF prefers use of SCTP).  There are situations
>     where sctp is unnecessary and not supported (e.g., point to point
>     connection).  During netconf negotiations you can announce your
>     feature set (currently sctptransport is not a feature).  Is there
>     ongoing work in updating RFC 6728 to include sctptransport as a
>     feature (so that the device can announce whether or not it
>     supports sctptransport)?
>     >
>     > @PJ Same answer as point (2) above, ie is this necessary and useful?
>     >
>     > P.
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > IPFIX mailing list
>     > [e-mail]<mailto:[e-mail]>
>     >
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__www.ietf.org_mailman_listinfo_ipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGaKdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cQFI-IsxLhklEI0w-JcCksB_YNvx9v06CpqsjQys0N8&e=>
>     >
>     >
>
>     > _______________________________________________
>     > IPFIX mailing list
>     > [e-mail]
>     >
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=
>
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   [phone]        
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=>
>
>     _______________________________________________
>     IPFIX mailing list
>     [e-mail]
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix