Subject: [apps-discuss] Apps Area Review of draft-grow-mrt-13

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Sep 2010 11:41:32 +0200

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-grow-mrt-13
Reviewer: Eliot Lear
Review Date: 13 September 2010

Summary:

This draft is not yet ready for publication, but will require at least a
review of the issues mentioned below.

Major Issues:

This specification suffers from two complicating effects:

    * The fact that it already deployed, and hence is attempting to
      document existing practice; and
    * there is substantial "feature creep" in an attempt to continue to
      use the same collector, while extending capabilities.

Consideration should be given to breaking this effort into two: an
informational document that explains what is going on today, and a new
clean specification for standardization.

This specification could perhaps benefit from review of those who
developed IPFIX and PSAMP.  In particular, consistent terminology would
be nice.

Specific issues:

   1. Section 3.  There is no versioning information in the packet
      header.  This means that format upgrades will require external
      information to identify their changes.
   2. Section 3. There are several 32-bit timestamp values, which will
      mean that a wrap will occur in 2038.  For most *protocols* this is
      not a problem because one can manage with wrap conditions. 
      However, this is a data export format meant for researchers. 
      Researchers tend to want to do longitudinal studies, and as such,
      it may prove difficult to use conventional wrapping mechanisms.  
      (The 32bit value also varies from the POSIX time_t definition; a
      nit to be sure, but an annoying one).
   3. Sections 5.2 and 5.3.  There are  two table dump mechanisms
      (TABLE_DUMP and TABLE_DUMP_V2) defined.  This  complicates
      implementations without any justification.  Very limited guidance
      is given as to when one is needed versus the other.  The authors
      are advised to strongly consider deprecating TABLE_DUMP in favor
      of TABLE_DUMP_V2, or in the alternative, providing much clearer
      guidance as to when one should be used by an exporter.  This
      problem replays itself throughout the document in other
      circumstances (c.f.., BGP4MP_MESSAGE & BGP4MP_MESSAGE_AS4).
   4. In Section 5.4.1 & 5.4.2 it appears that IANA-specified values are
      listed, and are as such limited.  This seems unnecessarily
      restrictive, and would force updates of this document when work is
      done on BGP.  That might prove necessary anyway becasue there may
      be insufficient length information to ignore a single table entry.
   5. The TABLE_DUMP_V2 subtypes are not sufficiently specified.  A good
      example of how to specify something sufficiently is the MRT
      header, where all fields are defined and explained.  For instance,
      in the case of TABLE_DUMP*, is a single entry encoded with format
      specified in Figures 3-5?  the use of records versus messages
      isn't clear.  In part this is due to inconsistent or poorly
      defined use of terminology (record versus message) A diagram or
      example should be included in the text that says:

>    The MRT records which follow the PEER_INDEX_TABLE MRT record contain
>    the RIB entries and include a header which specifies a sequence
>    number, NLRI, and a count of the number of RIB entries which follow.

   6. There is not a single example in the document.  This further
      hinders implementation of an already unclear specification.

Minor issues:

   7. Section 4.  There seems to be a desired to deprecate START and
      I_AM_DEAD from the outset.  While I can easily envision uses for
      this information, and for archival purposes, it seems useful to
      indicate start and end collection times (e.g., it may be useful to
      know when someone thought they were collecting routing updates but
      had in fact none), perhaps a bit more discussion and guidance
      should be given to implementors.
   8. The document really should have a glossary of terms.

Nits:

   9. NLRI is not defined.

Other (not within Apps charter):

  10. Section 8: Security Considerations do not describe data privacy
      concerns (consider the case where information being exported might
      indicate connectivity of specific individuals or systems, as could
      be possible with IGP information).  A fuller review is recommended.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Sep 2010 19:46:39 +0200

Hi Larry,

Thanks for taking the time to read the review and to respond.  Please
see below.

>
>>    1. Section 3. There are several 32-bit timestamp values, which
>>       will mean that a wrap will occur in 2038.  For most *protocols*
>>       this is not a problem because one can manage with wrap
>>       conditions.  However, this is a data export format meant for
>>       researchers.  Researchers tend to want to do longitudinal
>>       studies, and as such, it may prove difficult to use
>>       conventional wrapping mechanisms.   (The 32bit value also
>>       varies from the POSIX time_t definition; a nit to be sure, but
>>       an annoying one).
>>
>
>    Would adding text dealing with wrap conditions be sufficient?
> I'm assuming creating new types with 64-bit timestamp values is
> not particularly desired for this document.

Yes, the wrap condition should be addressed.  There are a few ways to
deal with it (just off the top of my head):

    * Use 64 bit values (this way you never have a wrap– or at least
      it's really REALLY someone else's problem ;-)
    * Provide an indication in a *single* 64 bit value – SOMEWHERE – as
      to when the epoch is.
          o That could be in the external wrapping of this data;
          o It could be through some form of extension.
          o A protocol revision (my least favorite preference).

>
>>    1. Sections 5.2 and 5.3.  There are  two table dump mechanisms
>>       implementations without any justification.  Very limited
>>       guidance is given as to when one is needed versus the other. 
>>       The authors are advised to strongly consider deprecating
>>       TABLE_DUMP in favor of TABLE_DUMP_V2, or in the alternative,
>>       providing much clearer guidance as to when one should be used
>>       by an exporter.  This problem replays itself throughout the
>>       document in other circumstances (c.f.., BGP4MP_MESSAGE &
>>       BGP4MP_MESSAGE_AS4).
>>
>
>    I think it's reasonable to deprecate the TABLE_DUMP type.
> Although there is quite a bit of data archived with this type,
> I believe that both RIPE and Routeviews have now moved to
> archiving table dumps in the TABLE_DUMP_V2 type.    BGP4MP_MESSAGE
> is still actively used and BGP4MP_MESSAGE_AS4 is only
> used when 4 byte AS numbers are present in the path.   I can
> add some text to clarify this.

I could easily see the argument that once this stuff is out there, it's
out there and you will forever have to parse it.  On the other hand, it
may make sense for someone to simply convert data once and simplify the
parsing later.  I can't really say.  I would recommend a "MUST
NOT"/"MUST" combination to at least begin the process.

>
>>    1. In Section 5.4.1 & 5.4.2 it appears that IANA-specified values
>>       are listed, and are as such limited.  This seems unnecessarily
>>       restrictive, and would force updates of this document when work
>>       is done on BGP.  That might prove necessary anyway becasue
>>       there may be insufficient length information to ignore a single
>>       table entry.
>>
>
>    I received separate feedback from IANA.  I'm still in the process of
> reviewing their comments.
>
>>    1. The TABLE_DUMP_V2 subtypes are not sufficiently specified.  A
>>       good example of how to specify something sufficiently is the
>>       MRT header, where all fields are defined and explained.  For
>>       instance, in the case of TABLE_DUMP*, is a single entry encoded
>>       with format specified in Figures 3-5?  the use of records
>>       versus messages isn't clear.  In part this is due to
>>       inconsistent or poorly defined use of terminology (record
>>       versus message) A diagram or example should be included in the
>>       text that says:
>>
>             Understood, I'll make the text consistent and add an example.
>
>         Agreed, I will add some additional examples.
>
>>   6.
>>
>>
>>
>> Minor issues:
>>
>>       I_AM_DEAD from the outset.  While I can easily envision uses
>>       for this information, and for archival purposes, it seems
>>       useful to indicate start and end collection times (e.g., it may
>>       be useful to know when someone thought they were collecting
>>       routing updates but had in fact none), perhaps a bit more
>>       discussion and guidance should be given to implementors.
>>
>
>         I don't believe there are any implementations when generate the
> START and I_AM_DEAD messages.  While I thought there might be some
> use for them, I am inclined to move them to the deprecated Appendix
> as well.

Ok.  FWIW - you could use this sort of mechanism to deal with your epoch
problem at some point in the future.
>
>>    7. The document really should have a glossary of terms.
>>
>
>   Agree.
>
>>
>> Nits:
>>
>>    9. NLRI is not defined.
>>
>
>    This could go in the glossary perhaps?
>
>>
>>       concerns (consider the case where information being exported
>>       might indicate connectivity of specific individuals or systems,
>>       as could be possible with IGP information).  A fuller review is
>>       recommended.
>>
>
>     I have received additional feedback from the security directorate
> which
> also mentions the privacy issues.   I will add text to the document
> reflecting
> these concerns.
>
>
>  -Larry Blunk
>

Again, thanks for taking into account this review.  I hope it has helped
improve the work.

Eliot

---

From: Larry Blunk <[email-masked]>
Date: Fri, 24 Sep 2010 11:39:20 -0400

On 09/13/2010 05:41 AM, Eliot Lear wrote:
> This draft is not yet ready for publication, but will require at least 
> a review of the issues mentioned below.
>
> Major Issues:
>
>     * there is substantial "feature creep" in an attempt to continue
>       to use the same collector, while extending capabilities.
>
> developed IPFIX and PSAMP.  In particular, consistent terminology 
> would be nice.

     Eliot, there is currently some work going on to define an XML
format for archiving BGP routing information.   There is a draft
at http://tools.ietf.org/html/draft-cheng-grow-bgp-xml-00 (although
it is currently expired).    While the GROW WG has yet to adopt this
draft, it seems this would be the likely base of a new clean specification.

>       information to identify their changes.

    Unfortunately,  I don't think there is a way around this.   This
is one of the issues that is resolved by the XML work.

>    1. Section 3. There are several 32-bit timestamp values, which will
>       mean that a wrap will occur in 2038.  For most *protocols* this
>       is not a problem because one can manage with wrap conditions. 
>       Researchers tend to want to do longitudinal studies, and as
>       such, it may prove difficult to use conventional wrapping
>       mechanisms.   (The 32bit value also varies from the POSIX time_t
>       definition; a nit to be sure, but an annoying one).
>

>       providing much clearer guidance as to when one should be used by
>       an exporter.  This problem replays itself throughout the

>       is done on BGP.  That might prove necessary anyway becasue there
>       may be insufficient length information to ignore a single table
>       entry.
>

>       good example of how to specify something sufficiently is the MRT
>       header, where all fields are defined and explained.  For
>       with format specified in Figures 3-5?  the use of records versus
>       messages isn't clear.  In part this is due to inconsistent or
>       poorly defined use of terminology (record versus message) A
>       diagram or example should be included in the text that says:
>

>       indicate start and end collection times (e.g., it may be useful
>       to know when someone thought they were collecting routing
>       updates but had in fact none), perhaps a bit more discussion and
>       guidance should be given to implementors.
>

   Agree.

>       as could be possible with IGP information).  A fuller review is

     I have received additional feedback from the security directorate which
also mentions the privacy issues.   I will add text to the document 
reflecting
these concerns.

  -Larry Blunk