[ipfix] draft minutes of Seoul session

[Juergen Quittek <[e-mail]>]

Dear all,

Below find the draft minutes for our session in Seoul.
They were recorded by Ralf Wolter with help from Tanja.

Please read and comment.

Thanks,

    Juergen
-- 
Juergen Quittek        [e-mail]        Tel: [phone]
NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


=======================================
Minutes of the IPFIX session at IETF 59
Wednesday March 3, 15:30 h - 17:30 h
=======================================

Minutes taken by Ralf Wolter and Tanja Zseby

----------
Session summary
To be inserted here.

----------
1. WG Status (Juergen Quittek)

Juergen presented the list of WG document and summarized
their states.  I-D draft-leinen-ipfix-eval-contrib-02.txt is a
working group document although its name does not indicate it.

----------
2.1. Requirement I-D:  draft-ietf-ipfix-reqs-15.txt (Juergen)

The WG discussed on whether encryption should be mandatory to implement or not.
The document will not pass IESG if we would change it by weakening the
security, so Jürgen proposed to leave it as is.

---------
2.2. Evaluation I-D: draft-leinen-ipfix-eval-contrib-02.txt (Simon Leinen)

Simon got some feedback from the AD, so he prepared a revised draft.
There are issues with status of the document, but there will be a workaround,
a note about the references was added. There are still references
to non-RFCs (e.g. requirements I-D) but in most cases the references are ok.

[Juergen] Same problem in MIDCOM.  There an evaluation documents where
postponed until all references I-Ds became RFC.

----------
3.1. Protocol Specification I-D:  draft-ietf-ipfix-protocol-03.txt (Benoit
     Claise)

Benoit described the changes from version 01 to 02
- Time synchronization
- IEs for different precision
- Flow records with multiple precision possible
  Q: [Juergen] Does a protocol implementation require support of
     all precisions?
  A: [Benoit] MUST only for microseconds (but he will double check)
- Linkage with Info Model
- Encoding rules
- New Security section
- Vendor specific information:
  [Juergen] There was a comment on the mailing list. FlowSet ID 2 and 3 might
  only be needed, and not 0 and 1 which were defined to be NetFlow compliant.
  Should be OK if FlowSet ID 0 and 1 are reserved for NetFlow, as the packet
  header already has a different version number (10) instead of the one which
  is used by NetFlow (9).
- Metering process statistics
- Option template for statistics
- New proposal on mailing list from Maurizio
- Editorial changes
- Overview section on IPFIX docs

Then he listed changes from version 02 to 03:
- Terminology synchronized between protocol and architecture
- Flow Expiration
- Section Synchronized with architecture
- Flow export vs. flow expiration
- Editorial changes
- Abstract and structure changed
- Transport Protocol: finally agreed on SCTP MUST, TCP MAY, UDP MAY
  Q: [Juergen] Is an implementation compliant if it just supports PR-SCTP?
  A: [Benoit] MUST for PR-SCTP makes most sense, but I have to ask Nevil.
  A: [Nevil Brownlee (via Jabber)] I will talk to SCTP people on SCTP vs
     PR-SCTP.
- Input is required for UDP and TCP:
  [Simon] volunteers to write one of these sections.

Then Bemoit showed a list of 30 open issues and discussed some of them.
- Exporter Time Accuracy: what if the exporter does not provide
  microsecond accuracy?
  [Simon] We should support devices with less accuracy but also export
  the accuracy provided by the device (option template).  Precision
  field should be added to the template.
  [Simon (and others)] Support for exporters with less capabilities
  is needed. They can report their precision. He will send a proposal
  to the mailing list.
- IP encapsulated packets: Benoit addressed the issue of whether limiting
  IPFIX to IP only or to be flexible for encapsulating protocols such as MPLS.
  He also roposed to also include GRE, IP-in-IP, IPv6 tunnel, MPLS, AtoM
  and replace "IP packets" by "packets" in the flow definition.
  [Juergen] feels that MPLS packets are covered by explicitly mentioning it
  in the requirements I-D, but AtoM is not. What about IP over Sonet, IP
  over lambda, SDH, etc.? Why limit to IP? The charter says we have to look
  for IP packets.
  [several] Discussion about the IP focus of the charter. Extending beyond IP
  would slow down the group.  Even if we make it open for other protocols
  but make sure that everyone understands that we limit IPFIX to IP.
  If we limit it to IP only, there might be an issue with PSAMPs AtoM
  collection.
  [AD Bert Wijnen (via Jabber)] Don't try to boil the ocean.
- Padding: currently a should for the exporting process, and a must for
  the collector.  Proposal to have a MAY for the exporting process

----------
3.2. Informatio Model I-D:  draft-ietf-ipfix-info-03.txt (Juergen)

Paul and Jeff couldn't make it, so Juergen presented.  Several editorial
changes were applied and the XML representation of the info model was changed.
This change included replacing the representation of IPFIX protocol fields
and adding an XML representation of field template and abstract data types.
Juergen explained the new XML representation, which uses the xml2rfc tool
from Marshall Rose. This will make the programming of IPFIX applications easy
and increase safety.

Juergen listed the open issues:
- Datatypes: several changes applied like more precise names,
  Milliseconds and Nanoseconds were removed. They need to be added again.
  The IPDR data types were removed. Jeff wants to keep UUID, this needs to
  be discussed on the mailing list.
- Field IDs: Some fields from NetFlowV9 should not be re-used, because they
  are NetFlow/Cisco specific.  Still, the IDs of these fields should be
  reserved in order to avoid incompatibilities between IPFIX and NetFlowV9.
  This needs to be considered when registering fields IDs at IANA.
- Some NetFlowV9 fields (like in/out packets) do not apply to an observer
  like a probe. How to deal with them?  No comments from the room,
  to be solved on the mailing list.  NFv9 has separate values for IPv4
  and IPv6 netmask length.  Sampling interval and sampling algorithm is
  used in NFv9 but probably not required (according to PSAMP).
  [Tanja,Benoit] Use the the PSAMP info model.
- List of not yet used NFv9 fields: there are multiple fields defined by
  NFv9 which are not yet considered by IPFIX, but are candidates:
  engineType and engineID.
  [Benoit] Several line cards at one device require more granularity than
  the IP address.
  [Stewart Bryant] Engine ID and txpe are Cisco-specific.
  NFv9 defines 10 MPLSlabels, shall IPFIX also reserve 10 fields?
  [Simon] destClassOfService/ToS field should be reproted before and after
  writing it, maybe refer to DiffServ terminology.
  [Juergen] Let's sort it out on the mailing list.

----------
4. new I-D on IPFIX implementation at middleboxes:
   draft-ietf-ipfix-info-03.txt (Martin Stiemerling)

Refer to RFC 3234 for a definition of middleboxes.
For IPFIX a clearly indication of the location of the observation point
is required. An observation point in the midlebox might be ambiguous.
Martin suggests to measure not within a middlebox, but outside of it
with a clearly defined observation point.  Still it is possible to report
the effect of the middlebox on flows as 'middlebox internels.

Open issues:
- investigate security implications
- should this become a WG draft?
[Tanja] Middleboxes are not included in the applicability statement,
so it should become a separate WG I-D.
[Juergen] The results of the paper need to be considered in the info model
by fields reporting middlebox internals, such as changed DSCP or tranlated
addresses and prot numbers.
[Benoit] We standardize export, we should rather not include middlebox
recommendations for metering.
[Emile Stephane] At least location of observation point should be included
in other IPFIX document.
Q: [?] Can a router that changes DSCP be a middlebox?
A: [Juergen] A router in this case is a routing device with middlebox function.
on this devices, the observation point must be defined relative to the
middlebox function.
Q: [Ralf Wolter] Do we limit IPFIX to ingress?
A: [Juergen] No we don't!

Conclusion: middlebox discussion to be finalized on the mailing list

----------
5. WG Schedule

Initial I-D     Final I-D     Deliverable
Done            Done          IPFIX requirements
Done            May 04        IPFIX architecture
Done            May 04        IPFIX protocol
Done            May 04        IPFIX information model
Done            May 04        IPFIX applicability statement

Q: [Juergen] When to finalize the architecture draft?
A: [Benoit] May is too early, We will manage to have two iterations until
the next IETF meeting.
[Juergen] Information model will progress in parallel.
[Tanja] I did not receive comments on the applicability I-D, so there is
no new version. If more details are be requested, I will produce a new
version. Iuggest to finish the protocol document first. Volunteers for
sections on RMONMIB and TEWG relations to IPFIX are very welcome.
[Benoit] Accidentally, there was no new version on the architecture.
Ganesh will post one soon.



--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/