Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04

Benoit,

> Finally, I took the time to reply to your email.
> As always, very thorough review

Thanks. I'm happy with all your feedback, except for the following points:


>>>     Original Exporter:   An Original Exporter is an IPFIX Device that
>>>        hosts the Observation Points where the metered IP packets are
>>>        observed.
>>>
>>>     Original Observation Point:   An Observation Point of the Original
>>>        Exporter.  In the case of the Intermediate Aggregation Process on
>>
>> These definitions imply that OPs belong to the exporter, which is not 
>> the case; they belong to the MP or to the IPFIX device.
> Changed to
> Original Observation Point:   An Observation Point_on_the Original
>        Exporter.  In the case of the Intermediate Aggregation Process on

Looking at the OP and OD definitions in 5101 and 5101bis, I see nothing 
to suggest that OPs are in any way related to Exporters.


>>>     Intermediate Flow Selection Process acting as distributor, which
>>>     collects Flow Records from one or more Exporters, and based on the
>>>     Information Elements content, redirects the Flow Records to the
>>>     appropriate Collector.  This example is a typical case of a single
>>>     network operation center managing multiple universities: an unique
>>>     IPFIX Collector collects all Flow Records for the common
>>>     infrastructure, but might be re-exporting specific university Flow
>>>     Records to the responsible system administrator.
>>
>> Does this case include the situation where incoming templates contain 
>> the same fields, but in a different order? So the mediator could 
>> re-order the fields and export the contents with a single outgoing 
>> Template. [Later: subject to key fields, per below.]
>
> See section 4.1.1

Is that just for me, or did you write it in the next version?


>> So are we saying that OD zero has a special meaning? Should existing 
>> exporters avoid using OD zero in order to avoid confusing Collectors?
> It's already taken care of by RFC5101bis and RFC5101 btw.
>   Observation Domain ID
>
>        A 32-bit identifier of the Observation Domain that is locally
>        unique to the Exporting Process.  The Exporting Process uses the
>        Observation Domain ID to uniquely identify to the Collecting
>        Process the Observation Domain that metered the Flows.  It is
>        RECOMMENDED that this identifier also be unique per IPFIX Device.
>        Collecting Processes SHOULD use the Transport Session and the
>        Observation Domain ID field to separate different export streams
>        originating from the same Exporter.  The Observation Domain ID
>        SHOULD be 0 when no specific Observation Domain ID is relevant for
>        the entire IPFIX Message, for example, when exporting the
>        Exporting Process Statistics, or in case of a hierarchy of
>        Collectors when aggregated Data Records are exported.
> Now, the only change is SHOULD -> MUST

You avoided the second part of the question: Should existing exporters 
avoid using OD zero in order to avoid confusing Collectors?

I could also ask, "MUST existing exporters avoid using OD zero ..." ?

It's possibly not directly relevant for this draft, but definitely for 
5101bis.


>>>     SCTP SHOULD be used in deployments where IPFIX Mediators and
>>>     Collectors are communicating over links that are susceptible to
>>>     congestion.  SCTP is capable of providing any required degree of
>>>     reliability.  TCP MAY be used in deployments where IPFIX Mediators
>>>     and Collectors communicate over links that are susceptible to
>>>     congestion, but SCTP is preferred due to its ability to limit back
>>>     pressure on Exporters and its message versus stream orientation.  UDP
>>>     MAY be used, although it is not a congestion-aware protocol.
>>>     However, in this case, the IPFIX traffic between IPFIX Mediator and
>>>     Collector MUST run in an environment where IPFIX traffic has been
>>>     provisioned for, or iscontained  through some other means.
>>
>> Explain "contained"?
>
> Contained -> not running over the open Internet. This is not the best way to express this. Suggest:
>
>     However, in this case, the IPFIX traffic between IPFIX Mediator and
>     Collector MUST run in an environment where IPFIX traffic has been
>     provisioned for and/or separated from non-IPFIX traffic, whether
>     physically or virtually.

Great!


>>> Claise, et al.           Expires August 29, 2013               [Page 22]
>>> 
>>> Internet-Draft               IPFIX MED-PROTO               February 2013
>>>
>>>
>>>     | ignoredRecordTotalCount | The total number of Data Records        |
>>>     |                         | received but not processed by the       |
>>>     |                         | Intermediate Process.                   |
>>>     | time first record       | The timestamp of the first record that  |
>>>     | ignored                 | was ignored by the Intermediate         |
>>>     |                         | Process.  For Data Records containing   |
>>>     |                         | timestamp ranges, this SHOULD be taken  |
>>>     |                         | from the start timestamp of the range;  |
>>>     |                         | for data records containing no timing   |
>>>     |                         | information, this SHOULD be taken from  |
>>>     |                         | the Export Time in the message header   |
>>>     |                         | ofthe containing IPFIX Message.  For   |
>>
>> Is this the incoming IPFIX Message? So the Intermediate Process has 
>> to examine each incoming Message in some detail, even though it's 
>> ignoring them? 
> Yes.

Well that's just daft. So this is a new definition of "ignoring" which 
actually means "examining them in detail"? Have you considered a career 
in politics?


>> How do you expect that to work?
>> Also, this supposes clock synchronisation.
>     It is RECOMMENDED that IPFIX Mediators handle time using absolute
>     timestamps (e.g. flowStartSeconds, flowStartMilliseconds,
>     flowStartNanoseconds), which are specified relative to the UNIX epoch
>     (00:00 UTC 1 Jan 1970), where possible, rather than relative
>     timestamps (e.g. flowStartSysUpTime, flowStartDeltaMicroseconds),
>     which are specified relative to protocol structures such as system
>     initialization or message export time.
>
>
> See also
> NEW.
>
>     The specification of the precise rules for applying Flow Record timestamps at IPFIX
>     Mediators for all the different situations is out of the scope of this document.

Still doesn't mention clock synchronisation.


>>>     |                         | this timestamp, any of the following    |
>>>     |                         | timestamp can be used:                  |
>>>     |                         | observationTimeSeconds,                 |
>>>     |                         | observationTimeMilliseconds,            |
>>>     |                         | observationTimeMicroseconds, or         |
>>>     |                         | observationTimeNanoseconds.             |
>>>     | time last record        | The timestamp of the last record that   |
>>>     | ignored                 | was ignored by the Intermediate         |
>>>     |                         | Process.  For Data Records containing   |
>>>     |                         | timestamp ranges, this SHOULD be taken  |
>>>     |                         | from the end timestamp of the range;    |
>>>     |                         | for data records containing no timing   |
>>>     |                         | information, this SHOULD be taken from  |
>>>     |                         | the Export Time in the message header   |
>>>     |                         | of the containing IPFIX Message.  For   |
>>>     |                         | this timestamp, any of the following    |
>>>     |                         | timestamp can be used:                  |
>>>     |                         | observationTimeSeconds,                 |
>>>     |                         | observationTimeMilliseconds,            |
>>>     |                         | observationTimeMicroseconds, or         |
>>>     |                         | observationTimeNanoseconds.             |
>>>     +-------------------------+-----------------------------------------+
>>
>> Pleaseaddsomewhitespacetomakethetablereadable.
> I could not find a way to do it...

Add some blank lines to vertically separate each definition in the 
table. Else all the definitions run together.

ie, make each definition a visually separate chunk. See 
http://syque.com/cstyle/ch2.8.htm


>>> 10.4.  ignoredRecordTotalCount Information Element
>>>
>>>     Description:   The total number of received Data Records that the
>>>        Intermediate Process did not process since the (re-)initialization
>>>        of the Intermediate Process; includes only Data Records not
>>>        examined or otherwise handled by the Intermediate Process due to
>>>        resource constraints, not Data Records which were examined or
>>>        otherwise handled by the Intermediate Process but which merely do
>>>        not contribute to any exported Data Record due to the operations
>>>        performed by the Intermediate Process.
>>
>> If a mediator is resource constrained, how can it accurately report 
>> this figure?
> Like in RFC 5101, section 4.2 
> <https://tools.ietf.org/html/rfc5101#section-4.2>. The Metering 
> Process Reliability Statistics Option Template
>
>    ignoredPacketTotalCount
>                             The total number of IP packets that the
>                             Metering Process did not process.
>
>     ignoredOctetTotalCount
>                             The total number of octets in observed IP
>                             packets that the Metering Process did not
>                             process.

Sorry, I asked the wrong question. If a mediator is resource 
constrained, how can it accurately _measure_ this figure?

It's a similar point to "time first record ignored" above.

P.

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix