[apps-review] Apps Area Review of: draft-ietf-grow-geomrt-01

[Dave CROCKER <[e-mail]>]

Howdy.

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-geomrt-01


Title:         MRT BGP routing information export format with
                geo-location extensions


Reviewer:      D. Crocker <[e-mail]>


Review Date:   27 April 2011


Summary:

    This document provides a focused enhancement to an existing data 
specification for exchanges reports about BGP activity externally.  It adds 
geo-location information to the tables.


Major Issues:

    0) The specification generally appears reasonable and concise. The 
enhancement seems intuitively useful, although I strongly suggest the document 
make the types of utility explicit.  Why is it good to add this information to 
the table?

    1) The document presumes extensive background by the reader.  Instead it 
needs a bit of tutorial and it needs to define every term -- acronym or core 
vocabulary -- it uses, either directly or by citation

    2) The GEO_PEER_TABLE needs a column with text defining the meaning of each 
value, rather than relying on the labels' being intuitive.



Detailed comment:


>  MRT BGP routing information export format with geo-location extensions
>                      draft-ietf-grow-geomrt-01.txt
>
> Abstract
>
>    This document extends the Border Gateway Protocol (BGP) MRT export
>    format for routing information to include terrestrial coordinates.

Expand MRT so that the Abstract requires less background to understand and gives 
a basic sense of the purpose/benefit of this work.


> 2.  Introduction
>
>    Research is underway that analyzes the network behavior of routing
>    protocol transactions from routing information base snapshots in
>    relation to geographical coordinates.  Specifically the BGP routing

The first sentence is confusing.  Although I could make guess, I don't really 
know what it means.  I suggest less redundant vocabulary and possibly two 
sentences and probably more active sentence form.

In contrast, I find draft-ietf-grow-mrt's related sentence:

      "Researchers and engineers often wish to analyze network behavior by
    studying routing protocol transactions and routing information base
    snapshots."

to be reasonably clear.


>    protocol is the subject of study and the analysis has been
>    significantly aided by the availability and extension of the "MRT
>    format" [I-D.ietf-grow-mrt] originally defined in the MRT
>    Programmer's Guide [MRT PROG GUIDE].
>
>    This memo documents an extension to the "MRT format"
>    [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT
>    Subtype field.
>

Lots of acronym repetition, without any acronym definition.


> 3.  Geo-location aware MRT Routing Information Subtype
>
>    The additional Subtype is defined for the TABLE_DUMP_v format, which
>    extends the TABLE_DUMP_V2 type.
>
> 3.1.  GEO_PEER_TABLE
>
>    The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include
>    Geo-location information in the form of WGS84 [WGS 84] formatted
>    coordinates.  The MRT subtypes would be as follows.
>
>        1    PEER_INDEX_TABLE
>        2    RIB_IPV4_UNICAST
>        3    RIB_IPV4_MULTICAST
>        4    RIB_IPV6_UNICAST
>        5    RIB_IPV6_MULTICAST
>        6    RIB_GENERIC
>        7    GEO_PEER_TABLE

What does each of these value mean?

The labels might seem intuitive, but there should be explicit text defining 
their meaning.


>    The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
>    Its latitude and longitude in WGS84 [WGS 84] format, and a list of
>    indexed peers.

I'm guessing this is the single most important text in the document, since it 
specifies exactly what location info is being provided.  I suggest the Abstract 
and Introduction summarize this, along the lines of:

    ...to include terrestrial coordinates of the BGP collector.

On the other hand, I can't find a definition of what a BGP Collector is, in this 
or related documents.  (It's not in RFC 4271, for example.)  In looking over the 
vocabulary from RFC 4271, it does appear that there is no term for the system 
that receives BGP reports.  Clearly one is needed, but it needs to be defined 
explicitly, so please either provide definition text or cite it.0

In fact, it's probably a good idea to explain why this particular bit of 
information is useful.  A small segment of tutorial text would go a long way.

Depending on what the definition of a BGP Collector is, the usefulness might or 
might note be obvious, but it shouldn't be left to chance.


>    The format and function of the Collector BGP ID, Peer Count are as
>    defined by the TABLE_DUMP_V2 MRT PEER_INDEX_TABLE format.
>    [I-D.ietf-grow-mrt].
>
>    The Collector Latitude and Collector Longitude are the geographical
>    coordinates of the collector in WGS84 [WGS 84] datum decimal degrees
>    format stored as a single precision float in the 32 bits allocated to
>    the Collector Latitude and Collector Longitude.  The latitude and
>    longitude may be a Not A Number (NAN) for situations where the geo-

It's not required, but common practice is to capitalize normative terms, like MAY.


>    location of the collector is considered private.  The Collector
>    Latitude and Collector Longitude MUST NOT be a mix of WGS84 [WGS 84]
>    datum coordinate and NAN values.
>
>         0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector BGP ID                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector Latitude                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Collector Longitude                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Peer Count           |  Peer entries (variable)
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>    The format of the peer entries is shown below.  The Peer Type and the
>    Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT
>    [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format.  The order of the Peer
>    entries in GEO_PEER_TABLE MUST match the order and number as existing
>    in the PEER_INDEX_TABLE.
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Peer Type   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer BGP ID                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer Latitude                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Peer Longitude                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>    The Peer Latitude and Peer Longitude are the geographical coordinates
>    of the peer in WGS84 [WGS 84] datum decimal degrees format stored as
>    a single precision float in the 32 bits allocated to the Peer
>    Latitude and Peer Longitude.  The latitude and longitude may be a Not

MAY


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net