Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 4 Dec 2006 16:06:41 -0000

Brian,

thanks for your comments. I've changed the text according to your suggestions, just one minor comment below:

>
> 7.1 para 3 OLD:
>
>    The Collecting Process MUST NOT decode any further Data Records  which
>    are associated with the expired Common Properties.  If a Common
>    Property is refreshed with a Template Record that differs from the
>    previous received Template Record, the Collecting Process SHOULD log
>    a warning and replace the previous received Common Property with the
>    new one.  The Template lifetime at the Collecting Process MUST be at
>    least 3 times higher than the Template refresh timeout configured on
>    the Exporting Process.
>
> 7.1 para 3 NEW:
>
>    The Collecting Process MUST NOT decode any further Data Records  which
>    are associated with the expired Common Properties.  If a Common
>    Property is refreshed with a definition that differs from the
>    previous definition, the Collecting Process SHOULD log
>    a warning and replace the previous received Common Property with the
>    new one.  The Common Property lifetime at the Collecting Process  MUST be at
>    least 3 times higher than the Common Property timeout configured on
>    the Exporting Process.

OK. But in the last sentence I'd prefer keeping "refresh timeout" instead of just "timeout":

" The Common Property lifetime at the Collecting Process  MUST be at least 3 times higher than the Common Property refresh timeout configured on the Exporting Process."

Regards,
Elisa

>
>
> Regards,
>
> Brian
>
> On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote:
>
>> Dear all,
>>
>> As agreed at the IPFIX session in San Diego last week
>> this is the WG last call on the Internet draft on
>> Reducing redundancy in IPFIX and PSAMP reports,
>> draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>> The WG last call starts today and will be closed on
>> December 1st.
>>
>> Please review the draft and send your comments!  Please also
>> send a message to the mailing list if you reviewed it and
>> have no comment to make!
>>
>> Thanks,
>>
>>    Juergen
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipfix
>
>

**************************************************************************************************
 
 E-mail Confidentiality Notice and Disclaimer.
 
  This email and any files transmitted with it are confidential and are intended solely for 
the use of the individual or entity to which they are addressed. Access to this e-mail by 
anyone else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on it, is 
prohibited. 
  E-mail messages are not necessarily secure.  Hitachi does not accept responsibility 
for any changes made to this message after it was sent. 
  Please note that Hitachi checks outgoing e-mail messages for the presence of 
computer viruses.

**************************************************************************************************
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Mon, 4 Dec 2006 11:09:54 -0500

Elisa,

Agreed. "Common Property refresh timeout" is clearer.

Regards,

Brian

On Dec 4, 2006, at 11:06 AM, Boschi, Elisa wrote:

>
> Brian,
>
> thanks for your comments. I've changed the text according to your  
> suggestions, just one minor comment below:
>
> >
> > 7.1 para 3 OLD:
> >
> " The Common Property lifetime at the Collecting Process  MUST be  
> at least 3 times higher than the Common Property refresh timeout  
> configured on the Exporting Process."
>
>
> Regards,
> Elisa
>
> >
> >
> > Regards,
> >
> > Brian
> >
> ********************************************************************** 
> **************************** E-mail Confidentiality Notice and  
> Disclaimer. This email and any files transmitted with it are  
> confidential and are intended solely for the use of the individual  
> or entity to which they are addressed. Access to this e-mail by  
> anyone else is unauthorised. If you are not the intended recipient,  
> any disclosure, copying, distribution or any action taken or  
> omitted to be taken in reliance on it, is prohibited. E-mail  
> messages are not necessarily secure. Hitachi does not accept  
> responsibility for any changes made to this message after it was  
> sent. Please note that Hitachi checks outgoing e-mail messages for  
> the presence of computer viruses.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 4 Dec 2006 11:09:54 -0500

Elisa,

Regards,

Brian

On Dec 4, 2006, at 11:06 AM, Boschi, Elisa wrote:

> ****************************

---

From: Paul Aitken <[email-masked]>
Date: Mon, 04 Dec 2006 19:51:08 +0000

Dear all,

Elisa wrote:

> " The Common Property lifetime at the Collecting Process  MUST be at 
> least 3 times higher than the Common Property refresh timeout configured 
> on the Exporting Process."

There's a lot of talk about - and reliance on - timeouts in IPFIX. But 
there's currently no way for exporters to communicate timeouts to 
collectors in band; all communication must be done OOB (eg, by an operator).

It'd be really straightforward to send a template lifetime IE or common 
properties ID lifetime IE in an option with the relevant template ID or 
CP ID as scope.

But it's not a very efficient method, since you'd have to repeat this N 
times, once per template / CP ID - though we could export using another 
IE that scopes a single lifetime to the system as a whole, or to the 
transport session.

I believe that Brian and Andrew have some ideas about this in the 
upcoming managing scope draft.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 04 Dec 2006 19:51:08 +0000

Dear all,

---

From: Brian Trammell <[email-masked]>
Date: Tue, 5 Dec 2006 08:30:26 -0500

On Dec 4, 2006, at 2:51 PM, Paul Aitken wrote:

> There's a lot of talk about - and reliance on - timeouts in IPFIX.

Only when using UDP. When using SCTP or TCP, the Transport Session  
termination performs the same function as the template/cpId timeouts.

> But there's currently no way for exporters to communicate timeouts  
> to collectors in band; all communication must be done OOB (eg, by  
> an operator).

Indeed. I don't actually see this as much of an impediment, though.  
Keep in mind this is only a consideration for UDP. In the UDP case,  
the CP and EP are almost certainly within the same administrative  
domain, with the same operator. OOB configuration is not quite so bad  
here because the operator will notice timeout errors in the log  
during deployment testing and adjust either the CP or EP timeout  
accordingly. Once such is done, it can be forgotten.

A more advanced CP may certainly auto-adjust its expectation of the  
EP timeouts based on the observed retransmission delay.

> It'd be really straightforward to send a template lifetime IE or  
> common properties ID lifetime IE in an option with the relevant  
> template ID or CP ID as scope.
>
> But it's not a very efficient method, since you'd have to repeat  
> this N times, once per template / CP ID - though we could export  
> using another IE that scopes a single lifetime to the system as a  
> whole, or to the transport session.

Here you have a circular definition:

The transport session for UDP (the only transport for which all this  
timeout stuff is relevant) is defined in terms of its template  
timeouts. So you can't set the timeout within a session for a session  
which is itself defined by the CP's previous estimation of session  
timeout; at least not with any solid expectation that such will work.

However, exporting timeout information scoped to an EP identifier  
does not have the same issue.

> upcoming managing scope draft.

All the above having been said, yes. The managing scope draft, among  
other things, will propose validFrom and validUntil information  
elements, which can be scoped to templateIDs or cpIDs, and key the  
time to the Export Time field in the IPFIX Message header.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Tue, 5 Dec 2006 08:30:26 -0500

Cheers,

Brian