Subject: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be used?

From: Benoit Claise <[email-masked]>
Date: Fri, 15 Feb 2008 15:44:22 +0100

Dear all,

During the last IETF meeting, we discussed the following open issue for 
regarding 
http://tools.ietf.org/wg/ipfix/draft-claise-ipfix-export-per-sctp-stream-02.txt, 
which concerns a current limitation in [IPFIX-PROTO]:

    "Template IDs are unique per SCTP association and per Observation
    Domain. If the Collecting Process receives a Template that has
    already been received but that has not previously been withdrawn
    (i.e., a Template Record from the same Exporter Observation Domain
    with the same Template ID received on the SCTP association), then the
    Collecting Process MUST shut down the association."

The current draft specifies: "Redefinition of the Template ID is not 
encouraged. Instead, new Template ID SHOULD be used, uFrom [email-masked]  Fri Feb 15 06:43:08 2008
Date: Fri, 15 Feb 2008 15:44:22 +0100
From: Benoit Claise <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be used?
Sender: [email-masked]

This is a multi-part message in MIME format.

Dear all,

During the last IETF meeting, we discussed the following open issue for 
regarding 
http://tools.ietf.org/wg/ipfix/draft-claise-ipfix-export-per-sctp-stream-02.txt, 
which concerns a current limitation in [IPFIX-PROTO]:

    "Template IDs are unique per SCTP association and per Observation
    Domain. If the Collecting Process receives a Template that has
    already been received but that has not previously been withdrawn
    (i.e., a Template Record from the same Exporter Observation Domain
    with the same Template ID received on the SCTP association), then the
    Collecting Process MUST shut down the association."

The current draft specifies: "Redefinition of the Template ID is not 
encouraged. Instead, new Template ID SHOULD be used, until the 
exhaustion of the Template ID space."
Do we want to put a MUST in that sentence?

IMHO, a MUST would be a plus as:
- it would considerably reduce the risk of losing Data Records in corner 
cases when Template IDs are applicable across multiple streams
- the number of bits for the Template ID is huge enough. The Template ID 
would wrap up to the next available Template ID, for which the Template 
Withdraw Message certainly had the time to reach the Collecting Process.
- the implementation is easy.

Feedback?

Regards, Benoit.

_______________________________________________
IPFIX mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 18 Feb 2008 15:33:25 +0100

Benoit, all,

> TheFrom [email-masked]  Mon Feb 18 06:33:41 2008
Date: Mon, 18 Feb 2008 15:33:25 +0100
From: Gerhard Muenz <[email-masked]>
To: Benoit Claise <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be
 used?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

Benoit, all,

> cases when Template IDs are applicable across multiple streams

What do you mean by reducing the risk of losing Data Records?
After receiving the Template Withdrawal Message, is not allowed to
decode any further Data Records associated with this Template ID. Hence,
you will always lose Data Records which arrive too late, independently
of the stream.

> - the implementation is easy.

According to my understanding, Template IDs can be reused without losing
any Records if the following three conditions are fulfilled:
1) Template and associated Data Records are sent over the same stream
using ordered delivery.
2) Reutilization of Template IDs is restricted to the same stream.
3) "All Template Withdrawal Message" is not used to withdraw Templates
from multiple streams.

Note that 1) does not imply that there is one stream per Template.

If any of the above conditions is not fulfilled, Data Records may arrive
before a Template, or after a Template Withdrawal Message.
Furthermore, if a Template ID is reused very quickly, we might have
trouble with some delayed Data Records assigned to the old Template and
arriving after the new Template.

It would be possible to detect that such delayed Data Records do not
belong to the new Template because by comparing the export times of the
Template and the Data Records. Yet this means that the export time has
to be stored for every Template, and that the Collector must accomplish
this comparison for every Data Record.

If we do not want to increase the Collector complexity in this manner,
Template IDs should not be reused as long as possible. Using new
Template ID until the exhaustion of the Template ID space achieves this
goal. However, I would not put a "MUST" because under the conditions
mentioned above, I can safely reuse Template IDs whenever I want.

Going beyond your question:

Reading the draft, it is difficult to understand its purpose. If I
understand correctly, it describes how to run IPFIX over multiple SCTP
streams in a beneficial way. Yet, most of section 5 explains common
IPFIX protocol behavior as specified in RFC 5101. It is difficult to see
at which points the draft goes beyond RFC 5101.

I propose to focus on explaining the recommended usage of SCTP streams,
combined with explanations why this is beneficial. If you want to keep
the detailed description of Exporter and Collector side behavior, make
clear which parts are normal IPFIX behavior and which parts are
according to your recommendations.

Further comments/questions:

        An Exporter uses multiple streams to export Data Sets.  In such
        a case, the Observation Domain MUST use the same Observation
        Domain ID value on all of the streams it uses.

This means that only one Observation Domain ID is allowed per
association. What is the reason for this restriction?

        Note: the idea of sending the (Options) Template Records on
        every single streams to which the Data Records corresponds to
        has been investigated.  However, [IPFIX-PROTO] specifies that
        the (Options) Templates Records are scoped by Transport Session,
        not per stream:

         "Template IDs are unique per SCTP association and per
          Observation Domain. ..."

Actually, RFC 5101 specifies that Template IDs (not Templates!) are
scoped per Transport Session. It does not forbid sending the same Option
Template with different Template IDs over different streams. And this
would solve the issue.

        The Template
        Withdrawal current draft specifies: "Redefinition of the Template ID is not
> cases when Template IDs are applicable across multiple streams

What do you mean by reducing the risk of losing Data Records?
After receiving the Template Withdrawal Message, is not allowed to
decode any further Data Records associated with this Template ID. Hence,
you will always lose Data Records which arrive too late, independently
of the stream.

> - the implementation is easy.

According to my understanding, Template IDs can be reused without losing
any Records if the following three conditions are fulfilled:
1) Template and associated Data Records are sent over the same stream
using ordered delivery.
2) Reutilization of Template IDs is restricted to the same stream.
3) "All Template Withdrawal Message" is not used to withdraw Templates
from multiple streams.

Note that 1) does not imply that there is one stream per Template.

If any of the above conditions is not fulfilled, Data Records may arrive
before a Template, or after a Template Withdrawal Message.
Furthermore, if a Template ID is reused very quickly, we might have
trouble with some delayed Data Records assigned to the old Template and
arriving after the new Template.

It would be possible to detect that such delayed Data Records do not
belong to the new Template because by comparing the export times of the
Template and the Data Records. Yet this means that the export time has
to be stored for every Template, and that the Collector must accomplish
this comparison for every Data Record.

If we do not want to increase the Collector complexity in this manner,
Template IDs should not be reused as long as possible. Using new
Template ID until the exhaustion of the Template ID space achieves this
goal. However, I would not put a "MUST" because under the conditions
mentioned above, I can safely reuse Template IDs whenever I want.

Going beyond your question:

Reading the draft, it is difficult to understand its purpose. If I
understand correctly, it describes how to run IPFIX over multiple SCTP
streams in a beneficial way. Yet, most of section 5 explains common
IPFIX protocol behavior as specified in RFC 5101. It is difficult to see
at which points the draft goes beyond RFC 5101.

I propose to focus on explaining the recommended usage of SCTP streams,
combined with explanations why this is beneficial. If you want to keep
the detailed description of Exporter and Collector side behavior, make
clear which parts are normal IPFIX behavior and which parts are
according to your recommendations.

Further comments/questions:

        An Exporter uses multiple streams to export Data Sets.  In such
        a case, the Observation Domain MUST use the same Observation
        Domain ID value on all of the streams it uses.

This means that only one Observation Domain ID is allowed per
association. What is the reason for this restriction?

        Note: the idea of sending the (Options) Template Records on
        every single streams to which the Data Records corresponds to
        has been investigated.  However, [IPFIX-PROTO] specifies that
        the (Options) Templates Records are scoped by Transport Session,
        not per stream:

         "Template IDs are unique per SCTP association and per
          Observation Domain. ..."

Actually, RFC 5101 specifies that Template IDs (not Templates!) are
scoped per Transport Session. It does not forbid sending the same Option
Template with different Template IDs over different streams. And this
would solve the issue.

        The Template
        Withdrawal Message SHOULD be sent in the last used stream that
        carried the Template ID to be removed.

but later:

        If the Collecting Process receives a Template Withdrawal Message
        on a different stream than the one on which the Template is
        used, then the Collecting Process MUST shutdown the association.

You have a SHOULD for the Exporter and a MUST for the Collector. The
described Collector behavior contradicts RFC 5101: "The Template
Withdrawal Message may be sent on any SCTP stream." So probably, the
association should not be shut down.

        If the Metering Process restarts, the Exporting Process MUST
        reuse the previously assigned Template ID for each Template and
        it MUST reuse the corresponding previously assigned stream for
        each Template ID. Alternatively, it MUST withdraw the previously
        issued Template IDs by sending Template Withdrawal Message(s)
        before reusing them. It can then use any available stream for
        the Template ID.

You have a MUST and an alternative MUST. Which one is the real MUST? Do
we really need this paragraph at all?

        If the measurement parameters change, the Template MUST be
        withdrawn (using a Template Withdrawal Message and a new
        Template definition) or an unused Template ID MUST be used.
        Examples of the measurement changes are: a new sampling rate, a
        new flow expiration process, a new filtering definition, etc. If
        a Template is changed, a Template Withdrawal Message MUST be
        sent to delete the Template.  Redefinition of the Template ID is
        not encouraged. Instead, new Template ID SHOULD be used, until
        the exhaustion of the Template ID space.

What is the reason for withdrawing Templates just because the
measurement parameters have changed? Wouldn't it be sufficient to send a
reliable Option Data Record with the new measurement parameters?

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Feb 2008 18:10:17 +0100

Gerhard,

You had a series of very good comments, which proves that we're thinking 
along the same lines.
For the everybody's sake, let me take a step back and explain the 
problems we try to solve by sending template per-SCTP stream.
This should answer some questions below, such as "What do you mean by 
reducing the risk of losing Data Records?"

_Problem 1:_
- when a template ID is used by multiple streams, and a template 
withdrawal message is sent on one of the those streams, then the other 
streams must allow enough time for the template withdrawal message to 
reach the collector before they can reuse the template ID, which is 
something they cannot know.
More importantly, the template withdrawal message cannot be sent on the 
first stream until it knows that all the other streams have transmitted 
their corresponding data records - which is also impossible to know.

It's true that RFC5101 specifies:

   The Template Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.  This
   time MUST be configurable.  A suitable default value is 5 seconds
   after the last Data Record has been sent.

But it's not always possible to guarantee that 5 seconds is enough. So 
we might lose data records.

_Problem 2:_
In figure 4 of the current draft, the potential head of line blocking 
could imply that the data records in a different stream might arrive 
before the template records. In other words, no guarantee that the data 
records will always arrive after the template records, if the template 
record and data records are not sent in the same stream.

It's true that RFC5101 specifies:

   The Collecting Process normally receives Template Records from the
   Exporting Process before receiving Data Records.  The Data Records
   are then decoded and stored by the Collector.  If the Template
   Records have not been received at the time Data Records are received,
   the Collecting Process MAY store the Data Records for a short period
   of time and decode them after the Template Records are received.  A
   Collecting Process MUST NOT assume that the Data Set and the
   associated Template Set (or Options Template Set) are exported in the
   same IPFIX Message.

But we can't guarantee that the Collecting Process will not lose some 
data records ("MAY store")
_
More generic problem:_
Problems 1 and 2 are different problems, but with the same cause: the 
problems come from data records from the same template ID sent across 
different streams. Typically, the PSAMP option template record for sampling.
This is a current limitation/problem with IPFIX
We evaluated whether we can propose some improvements part of this 
per-SCTP draft, even if the per-SCTP draft goal was to export one 
template per stream to be able to deduce the data loss for each template 
record.

There are a couple of solutions, with the solution 1 being the preferred 
one. Hence the reverse order.

_Solution 3:_
As explained by Gehrard, look at the export time in the template 
records, data records, and template withdrawal message.
- This implies a more complex collecting process implementation as the 
old and new template records must kept to compare the time
  Note: potentially more than two template records must be kept if the 
definition of the template ID changes frequently
- This implies that we loose the real-time decode, as the collecting 
process must wait for a certain time, just in case a delayed template 
withdrawal message and a new template record is received. For this 
reason only, I think this solution is poor
- What if data record and template withdraw message were in the same 
IPFIX message? Probably it'd depend on the order within the message.

_Solution 2_
We could propose a series of specifications that would reduce the 
likelihood that problem 1 or 2 would happen
    - transmission order is maintained within a stream
    - redefinition of the Template ID is not encouraged
    - template withdrawal message SHOULD be sent in the last used stream 
that carried the template ID to be removed
    - etc..
The drawback of this solution is that, even if the likelihood is 
reduced, there is no guarantee that the problem 1 and 2 will not happen.
When I posted the initial email from this thread, I was still thinking 
along this solution 2

_Solution 1_
The template IDs are scoped per stream, next to the the Transport 
Session and Observation Domain that generated the Template ID.
Next to that, the transmission order per stream is maintained
In this case, problem 1 and problem 2 will never happen
The drawbacks are that
    - more template ID and records would be used. For example, the 
sampling option template record would require
      one template ID per stream and the export the "same" data record 
values per stream
    - "reducing redundancy" draft would not work across stream. Is this 
a big issue, I don't know!
Note that there is a simple solution to address those two drawbacks: 
never send a template withdrawal message, and make those template IDs 
permanent as long as the SCTP association is up. Nothing is changed on 
the collector side specifications, as it doesn't have to know that the 
template IDs are permanent
Now, the real question in this solution 1 is: what to do if we can't 
increase anymore the number of streams in the SCTP association?

    We export all the newly created template IDs and the associated data
    records on the stream 0 (as currently specified in the per-SCTP stream)
    Overloading the stream 0 is not an issue as the SCTP design is such
    that there is one pool of buffer and all streams will share it, i.e.
    "if you send  100k in one stream.. or 100k spread over all streams..
    it makes no difference" dixit Randy Stewart.
    Note: stream 0 is mentioned for historical but could very well be
    another one. I'm not even sure we even need to specify a certain stream
    Note that on that stream 0, we can't deduce the loss per template.

We think that the solution 1 is the best solution to address the 
problems described
Feedback?

Regards, Paul and Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Feb 2008 18:10:17 +0100

Gerhard,

_Problem 1:_

_Problem 2:_

_Solution 3:_

_Solution 2_

_Solution 1_

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 20 Feb 2008 11:01:08 +0100

Benoit, Paul,

> Solution 1

Do you mean to change the scope of Template IDs as specified in RFC5101?
In my opinion, we should not change the protocol specifications as long
as we can achieve the same result by a clever usage of the current
protocol.

Changing the scope of Template IDs is necessary only if you want to use
the same Template ID on different streams. However, I assume that the
Template ID space is large enough (and much larger than the number of
available streams) to assign unique IDs per Transport Session. Then, if
a given Template ID is used, withdrawn, and reused exclusively on one
stream, we achieve the same result.

> Next to that, the transmission order per stream is maintained

Yes, that is a necessary condition.

> template IDs are permanent

It is a trade-off because now, the collector has to store numerous
unused Templates until the end of the association.
It should be up to the administrator's preferences if he prefers not to
withdraw Templates because he wants to use reducing redundancy with the
same Template over multiple streams and pay for it with higher memory
requirements at the collector.

>     Note that on that stream 0, we can't deduce the loss per template.

The main advantage of using separate streams for different Templates is
that you can calculate the record loss per Template. This might not be
required for all Templates. So the administrator can chose for which
Templates he wants to have a separate stream. He can also group several
Templates in one stream if the loss rate for the whole group is
sufficient for the statistics.

We also need to add that "All Template Withdrawal Message" is not used.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 20 Feb 2008 11:01:08 +0100

Benoit, Paul,

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Feb 2008 14:58:26 +0100

Gerhard,
> stream, we achieve the same result.
So basically you say: let's not scope the Template IDs per stream, but 
let's make sure that a Template ID is not used across multiple streams.
> sufficient for the statistics.
I like this idea.

> We also need to add that "All Template Withdrawal Message" is not used.
Yes.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Feb 2008 14:58:26 +0100

Gerhard,
I like this idea.

Yes.

Regards, Benoit

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Feb 2008 12:58:23 -0500

Benoit, Gerhard, and all,

Replies inline; the most important one appears at the end, after  
Solution 1. Summary: we shouldn't change the protocol to redefine  
template scopes; it doesn't just break specific things but creates a  
new protocol; and, we should address dependent information sequencing  
at some point.

On Feb 19, 2008, at 12:10 PM, Benoit Claise wrote:

> Gerhard,
>
> You had a series of very good comments, which proves that we're  
> thinking along the same lines.
> This should answer some questions below, such as "What do you mean  
> by reducing the risk of losing Data Records?"
>
> Problem 1:
> withdrawal message is sent on one of the those streams, then the  
> other streams must allow enough time for the template withdrawal  
> message to reach the collector before they can reuse the template  
> ID, which is something they cannot know.
> More importantly, the template withdrawal message cannot be sent on  
> the first stream until it knows that all the other streams have  
> transmitted their corresponding data records - which is also  
> impossible to know.
>
> But it's not always possible to guarantee that 5 seconds is enough.  
> So we might lose data records.

Indeed. Template withdrawals (like UDP) are dangerous, and in an ideal  
situation should not be used at all. They won't work reliably in the  
general-case, flexible multistream environment. But sometimes you'll  
get yourself into a situation where you need to withdraw templates,  
for whatever reason. So we give guidelines, as above, to minimize the  
damage should an exporter choose to use this feature.

(Aside: if data record loss avoidance is a prime requirement, use TCP  
or single-stream reliable SCTP.)

(Aside, aside: Can someone provide 1. the count of templates you're  
expecting to use within a single transport session and 2. example  
expected use cases for template withdrawals? In theory all this is  
broken, I agree, but I still can't really see situations where all  
these various template withdrawal problems will arise in the Real  
World (tm).)

> More generic problem:
> Problems 1 and 2 are different problems, but with the same cause:  
> the problems come from data records from the same template ID sent  
> across different streams. Typically, the PSAMP option template  
> record for sampling.

More generically still, the problems come from dependencies between  
IPFIX messages sent without sequencing guarantees. See comment on  
Solution 3 below.

> template per stream to be able to deduce the data loss for each  
> template record.
>
> There are a couple of solutions, with the solution 1 being the  
> preferred one. Hence the reverse order.
>
> Solution 3:
> - This implies a more complex collecting process implementation as  
> the old and new template records must kept to compare the time
>   Note: potentially more than two template records must be kept if  
> the definition of the template ID changes frequently
> process must wait for a certain time, just in case a delayed  
> template withdrawal message and a new template record is received.  
> For this reason only, I think this solution is poor

The CP should be looking at export time when evaluating information  
dependencies (scoped options, templates), anyway. This is completely  
ignored by the protocol (though in retrospect perhaps it should have  
been), but there are really only two temporal scoping policies that  
make sense:

1. If dependencies cannot be withdrawn, then it can be held to be  
valid for the entirety of its enclosing outer scope (the transport  
session). In this case, ordering within the session is completely  
unimportant. This is pretty much, by default, how 5101 treats things,  
and I think how we think about these things on the list.

2. If dependencies may we withdrawn _AND REDEFINED_ (which is the  
point of template withdrawals, after all), then the ordering of these  
operations is critically important. Since ordering is important  
_across_ streams, we can't use the sequence number. The only sync  
signal we have that works across all streams is the export time.

Actually building out a consistent set of rules for handling dependent  
information could, I think, be done without changing the wire protocol  
or the EP at all; it could basically be a set of CP guidelines. Though  
I haven't thought all the way through the problem to be able to say  
that with much confidence, yet. IIRC Andrew and I discussed something  
along these lines in the form of a "scope user's guide" way back in  
San Diego, but haven't had a chance to do anything with it since then.

> Solution 2
>     - template withdrawal message SHOULD be sent in the last used  
> stream that carried the template ID to be removed
>     - etc..
> When I posted the initial email from this thread, I was still  
> thinking along this solution 2

Something along the lines of this solution is, I think, as good as we  
can do, in view of the issues with solution 1; see below.

An EP using the per-stream technique will not lose data records due to  
template withdrawals or template synchronization issues. This is an  
advantage of using per-stream. But per-stream is an option; a  
technique applicable to certain use cases that has specific advantages  
in those cases. It uses each template only on a single stream, and  
each stream has only a single template, but that is simply the EP's  
prerogative, not a property of the protocol.

An EP not using template withdrawals at all will not lose data records  
due to template withdrawals, trivially.

An EP choosing to use template withdrawals and cross-stream template  
definitions may generate a message stream it is difficult but not  
impossible for the CP to process without record loss. 5101 provides  
guidelines and warnings to this effect already.

(Again, data loss avoidance is _one_ requirement -- one policy -- that  
the mechanisms of the IPFIX protocol can be used to implement. It is  
not always of the utmost importance; otherwise we wouldn't support UDP  
and PR-SCTP.)

>       one template ID per stream and the export the "same" data  
> record values per stream
>     - "reducing redundancy" draft would not work across stream. Is  
> this a big issue, I don't know!

Indeed, this would cause options template records used for other than  
MP/EP metadata export (as in RFC5103, ipfix-exporting-type, ipfix- 
reducing-redundancy) not to work across streams.

I agree with Gerhard (in his reply to this message): we shouldn't  
change the protocol. And this proposal does define a new protocol. RFC  
5103 EPs would be incapable of interoperating with CPs that failed to  
interpret cross-stream templates. 5103 CPs would be incapable of  
interoperating with EPs that caused template collision.

I would also repeat strenuously my warnings from the last time we  
visited this proposal (around the Chicago meeting last year) not to  
introduce restrictions or changes into the protocol that apply only to  
certain use cases and policies implementable with the greater protocol.

> never send a template withdrawal message, and make those template  
> IDs permanent as long as the SCTP association is up. Nothing is  
> changed on the collector side specifications, as it doesn't have to  
> know that the template IDs are permanent
>

Hmm. per-stream should also provide guidelines that it works best in  
cases where you have enough streams to handle all your templates.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Feb 2008 12:58:23 -0500

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Fri, 22 Feb 2008 00:31:11 +0000

Brian,

> ignored by the protocol

If you do that, then you'd have to store all the received data records
undecoded for a certain amount of time - even if you have a valid
template to decode them - against the slight possibility of a TWM and
new template definition with an earlier timestamp being received from
another stream.

Which means you lose the ability to decode data in real time.

> IIRC Andrew and I discussed something along these lines in the form 
> of a "scope user's guide" way back in San Diego

If templates contained a valid-from and a valid-to timestamp, with a
guarantee they'd not be withdrawn or redefined within that window, then
you could decode in real time once again.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Fri, 22 Feb 2008 00:31:11 +0000

Brian,

---

From: Benoit Claise <[email-masked]>
Date: Fri, 22 Feb 2008 14:16:39 +0100

Thanks Brian,

Let me quickly update the draft based on Gerhard's and your feedback.

Regards, Benoit.
>> - when a From [email-masked]  Fri Feb 22 05:16:51 2008
Date: Fri, 22 Feb 2008 14:16:39 +0100
From: Benoit Claise <[email-masked]>
To: Brian Trammell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] Per-SCTP stream draft: New Template ID SHOULD/MUST be
 used?
Sender: [email-masked]

Thanks Brian,

Let me quickly update the draft based on Gerhard's and your feedback.

Regards, Benoit.
>> message to reach the collector before they can reuse the template ID, 
>> which is something they cannot know.
> unimportant. This is pretty muchtemplate ID is used by multiple streams, and a template 
>> message to reach the collector before they can reuse the template ID, 
>> which is something they cannot know.
> MP/EP metadata export (as in RFC5103, ipfix-exporting-type, 
> ipfix-reducing-redundancy) not to work across streams.
>
> visited this proposal (around the Chicago, by default, how 5101 treats things, 
> MP/EP metadata export (as in RFC5103, ipfix-exporting-type, 
> ipfix-reducing-redundancy) not to work across streams.
>
>> permanent as long as the SCTP association is up. Nothing is changed 
>> on the collector side specifications, as it doesn't have to know that 
>> the template IDs are permanent
>>

 meeting last year) not to 
>> permanent as long as the SCTP association is up. Nothing is changed 
>> on the collector side specifications, as it doesn't have to know that 
>> the template IDs are permanent
>>