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 <dcrocker@bbiw.net>


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