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

[Terry Manderson <[e-mail]>]

Hi Dave,

Thanks for your careful review.

On 28/04/11 6:17 AM, "Dave CROCKER" <[e-mail]> wrote:

> 
> 
> Document:      draft-ietf-grow-geomrt-01
> 
> 
> 
> 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?

I have added a paragraph describing the utility to the introduction.

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

I have added a definitions section.


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

I have added a small table following the GEO_PEER_TABLE and peer entries
defining the label definitions.

> 
> 
> 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.


done.
> 
> 
>> 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.

Updated.

> 
> 
>>    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.

expanded acronyms.

> 
> 
>> 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?

It's actually superfluous to list types 1-6.

I have updated the table to be just Subtype 7 with a header that explains
that the number is a subtype number and the text is a subtype name.


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

They are just the Subtype number and name in the export format. They hold no
special 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.

Have updated the intro and abstract.

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

Indeed no documentation exists describing a BGP collector.
I have added a definition for BGP Collector.

> 
> 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.

I've provided some expanded information on a BGP Collector in its own
section.

> 
> 
>>    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.

Fixed.

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

fixed


A rfcdiff is attached for the new -02 from -01. Do these adequately address
the issues you raise?

(also noting the removal of the IANA considerations section as the primary
MRT draft no longer calls for an IANA registry, thus geomrt shouldn't
either.)

And I'm awaiting the shepherd's ack to post.

Cheers
Terry