Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals

From: Juergen Quittek <[email-masked]>
Date: Wed, 14 Jun 2006 17:28:15 +0200

Dear all,

It seems to be difficult to come to an end with this discussion.
Therefore, I try another approach.

Below please find a proposal that might be acceptable to
all of us.  It is a rather detailed one already containing
already concrete suggestions for text changes in our the three
documents.

Please comment.

Thanks,

    Juergen

OLD [in IPFIX-ARCH and IPFIX-PROTO]
   * Observation Domain

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an observation domain if it
      is composed of several interfaces, each of which is an Observation
      Point.  Each Observation Domain presents itself to the Collecting
      Process using an Observation Domain ID to identify the IPFIX
      Messages it generates.  Observation Domain IDs are unique per
      Exporting Process.
NEW [Just appended a sentence]
   * Observation Domain

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an observation domain if it
      is composed of several interfaces, each of which is an Observation
      Point.  Each Observation Domain presents itself to the Collecting
      Process using an Observation Domain ID to identify the IPFIX
      Messages it generates.  Observation Domain IDs are unique per
      Exporting Process. It is RECOMMENDED that an Observation Domain IDs
      is also unique per IPFIX device.

OLD [in IPFIX-ARCH and IPFIX-PROTO]
   * IPFIX Device

      An IPFIX Device hosts at least one Observation Point, a Metering
      Process and an Exporting Process.
NEW
   * IPFIX Device

      An IPFIX Device hosts at least one Exporting Process.  It may host
      further Exporting processes and arbitrary numbers of Observation Points
      and Metering Process.

OLD [in IPFIX-ARCH]
5.4.  Observation Domain

   The Observation Domain is a logical block that presents a single
   identity for a group of Observation Points within an IPFIX Device.
   Each {Observation Point, Metering Process} pair belongs to a single
   Observation Domain.  An IPFIX Device could have multiple Observation
   Domains, each of which has a subset of the total set of Observation
   Points in it.  Each Observation Domain must carry a unique ID within
   the context of an IPFIX Device.  Note that in case of multiple
   Observation Domains, a unique ID per Observation Domain must be
   transmitted as a parameter to the Exporting Function.  That unique ID
   is referred to as the IPFIX Observation Domain ID.
NEW
5.4.  Observation Domain

   The Observation Domain is a logical block that presents a single
   identity for a group of Observation Points. Each {Observation Point,
   Metering Process} pair SHOULD belong to a single Observation Domain.
   A single IPFIX Device may have multiple Observation Domains, each of
   which contains a subset of the total set of Observation Points.
   Each Observation Domain MUST carry a unique ID within the context of
   a single Exporting Process.  It is RECOMMENDED that this ID is also
   unique per IPFIX Device.

OLD [in IPFIX-PROTO section 3.1]
   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.  Collecting Processes SHOULD use the
NEW  [inserted one sentence]
   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
           is also unique per IPFIX Device.  Collecting Processes
           SHOULD use the

OLD [in IPFIX-PROTO section 4.1 and section 4.2]
        sourceId                An identifier of an Observation Domain
NEW
        observationDomainId     An identifier of an Observation Domain

OLD [in IPFIX-PROTO section 3.4.2.1]
   exportingProcessId, sourceId, etc. are also valid scopes.  The IPFIX
NEW
   exportingProcessId, observationDomainId, etc. are also valid scopes.  The IPFIX

OLD [in IPFIX-INFO]
5.1.10.  sourceId

   Description:
      An identifier of an Observation Domain that is unique per
      Exporting Process.  Typically, this Information Element is used
      for limiting the scope of other Information Elements.
NEW
5.1.10.  observationDomainId

   Description:
      An identifier of an Observation Domain that is unique per
      Exporting Process.  It is RECOMMENDED that this identifier is
      also unique per IPFIX device.  Typically, this Information
      Element is used for limiting the scope of other Information
      Elements.

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 16 Jun 2006 00:19:18 +0200

Hi Juergen,

Thanks for this effort.
In a nutshell, for the sake of finalizing the documents, I agree with 
your proposed changes.

>      Messages it generates.  Observation Domain IDs are unique per
First of all, there is a discrepancy in the Observation Domain 
definitions of [IPFIX-ARCH] and [IPFIX-PROTO].

[IPFIX-ARCH]

   * Observation Domain

[IPFIX-PROTO]

 Observation Domain 
   An Observation Domain is the largest set of Observation Points for 
   which Flow information can be aggregated by a Metering Process.  For 
   example, a router line card may be an Observation Domain if it is 
   composed of several interfaces, each of which is an Observation 
   Point. In the IPFIX Message it generates, the Observation Domain 
   includes its Observation Domain ID, which is unique per Exporting 
   Process.  That way, the Collecting Process can identify the specific 
   Observation Domain from the Exporter that sends the IPFIX Messages. 
   Every Observation Point is associated with an Observation Domain. 

>      is also unique per IPFIX device.
If you would add the sentence "It is RECOMMENDED that an Observation 
Domain IDs
     is also unique per IPFIX Device." to the [IPFIX-PROTO] definition,  
I would be fine.
Then this definition should be used for both [IPFIX-PROTO] and [IPFIX-ARCH]
>        observationDomainId     An identifier of an Observation Domain
Yes, already corrected in my temp version.
>   exportingProcessId, observationDomainId, etc. are also valid 
Yes, already corrected in my temp version.
>      Element is used for limiting the scope of other Information
Yep.

Regards, Benoit.

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 16 Jun 2006 10:42:08 +1200

Hi Benoit:

Sounds fine to me.  I'm working on a new revision of draft-architecture
now, I'll make the change to the definition of * Observation Domain, to

   ...

Following up on an email I sent Benoit yesterday, can we get new versions
of the protocol and architecture drafts published by about next Tuesday
(20 June)?  If we can, we could ask Dan to get them onto the IESG telechat
on 22 June ...

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 16 Jun 2006 13:19:01 +0200

Dear all,

I posted a list of changes to the documents as a proposal for
a compromise solution for the long discussion on observation
domain ID uniqueness per exporting versus uniqueness per IPFIX
device.

Now it seems that we are close to an agreement on uniqueness
per exporting process, which is in line with the current
protocol and info model drafts.

In case the WG agrees on that, here is the alternative (and
shorter) list of changes to be applied:

OLD [in IPFIX-ARCH]
5.4.  Observation Domain

   a single Exporting Process.

OLD [in IPFIX-INFO]
5.1.10.  sourceId
NEW

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Benoit Claise <[email-masked]>
Date: Fri, 16 Jun 2006 16:04:54 +0200

Juergen,
> protocol and info model drafts.
Note quite. See my previous email
> shorter) list of changes to be applied:
Since you removed "It is RECOMMENDED that an Observation Domain IDs is 
also unique per IPFIX device.", then I favor your previous proposal 
http://ipfix.doit.wisc.edu/archive/3366.html, which btw nobody objected.

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 16 Jun 2006 10:26:09 -0400

Juergen,

These changes look good.

And now for the related problem: Are we planning on keeping the  
Observation Domain ID header field definition in 3.1 (page 13 of -21)  
as-is? Either this or the Template ID definition in 3.4.1 (page 18 of  
-21) must change; else Templates are scoped within Observation  
Domains are scoped within (one of exporterIPv4Address,  
exporterIPv6Address, exporterProcessId), which are not guaranteed to  
be available to the Collecting Process (i.e. exporterProcessId is not  
present in the message header, addresses are not unique over SCTP)  
without explicit export, which requires a template.

I would propose changing the Template ID definition to read as follows:

OLD
       Template ID
          Each of the newly generated Template Records is given a unique
          Template ID.  This uniqueness is local to the Observation
          Domain that generated the Template ID.  Template IDs 0-255 are
          reserved for Template Sets, Options Template Sets, and other
          reserved Sets yet to be created.  Template IDs of Data Sets
          are numbered from 256 to 65535.  There are no constraints
          regarding the order of the Template ID allocation.
NEW
       Template ID
          Each Template Record is given a unique Template ID by the  
Exporting
          Process. This uniqueness is local to the session in which  
the template
          is transmitted (e.g., the TCP connection or the SCTP  
association).
          Template IDs are managed and reused as in sections 8, 10.3.6,
          and 10.4.2.2 of this document.  Template IDs 0-255 are
          reserved for Template Sets, Options Template Sets, and other
          reserved Sets yet to be created.  Template IDs of Data Sets
          are numbered from 256 to 65535.  There are no constraints
          regarding the order of the Template ID allocation.

[Note that I have not yet reviewed the language in the referenced  
sections to ensure congruence with this change; I will volunteer to  
do so if required, and if the WG consensus is to go with this.]

The primary negative impact of this change is that templateIDs have  
no meaning outside their use in the transport protocol, and can no  
longer be abused as generic scope. With commonPropertiesId now  
available with 2^64 codepoints, this is not, I think, a significant  
drawback.

Regards,

Brian