Subject: Re: grow: draft-ietf-grow-mrt-01.txt

From: "Larry J. Blunk" <[email-masked]>
Date: Tue, 1 Nov 2005 11:35:02 -0500

On Sunday 30 October 2005 16:17, Pekka Savola wrote:
> On Mon, 31 Oct 2005, Geoff Huston wrote:
> > I'd suggest add it and ship it - 4 byte AS numbers are not in any doubt and
> > moving a draft on through the process is always (*) better than having it 
> > hang
> > around
> 
> While I don't doubt 4 byte AS numbers is going to go through in some 
> form, it is not 100% certain whether there won't be changes (such as a 
> different way to encode the numbers in the attributes) which might 
> require different approach in MRT format.
> 
> The MRT draft may or may not have sufficient abstraction that this is 
> not a problem (I haven't looked at the draft).

    Pekka,
        The MRT format does indeed leave the interpretation of the
attribute information as an application specific issue.     The source
and destination AS'es are encoded in the BGP4MP_MESSAGE and
BGP4MP_STATE_CHANGE messages (and the deprecated BGP_ types).
Since the deprecated types can be ignored, it would be relatively trivial
to create a couple new BGP4MP types which support 4-byte source and
destination AS'es.   Actually, I'm not sure if support for the BGP4MP_STATE_CHANGE
message is really needed given the new BGP4 draft radically redefines the state
machine and the state can be divined from the BGP messages anyway.

  -Larry

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: john heasley <[email-masked]>
Date: Tue, 1 Nov 2005 22:18:55 -0800

Thu, Oct 27, 2005 at 02:48:08PM -0400, Larry J. Blunk:
> 
>    A new MRT draft is now up.  Diffs can be found at --
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-grow-mrt-00.txt&url2=http://tools.ietf.org/id/draft-ietf-grow-mrt-01.txt
> 
>     This updated draft adds a new OSPF type (OSPF_ET) which includes
> both OSPFv3 (IPv6) and microsecond time resolution support.  This the microsecond
> support for OSPF was requested by Simon Leinen.

Is microsecond time resolution not of general interest, for all non-deprecated
types?  Why not just split the MRT message type space in half; any types with
the high bit set have a microsecond word following the header.

I'd still like to see a "magic number" message that includes some identifier
of the tool/collector which wrote the file.
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: "Larry J. Blunk" <[email-masked]>
Date: Fri, 4 Nov 2005 17:29:05 -0500

> the high bit set have a microsecond word following the header.

    The document already had support for microsecond timestamps for ISIS and
BGP.   With the addition of OSPF, the only thing left is RIP.

> of the tool/collector which wrote the file.

     Would this require an IANA registry for tool/collector magic numbers?
I'm worried that might push the document outside the scope of the GROW WG.

 -Larry

---

From: john heasley <[email-masked]>
Date: Mon, 7 Nov 2005 22:41:56 +0000

> BGP.   With the addition of OSPF, the only thing left is RIP.

what i'm suggesting is just define a cut-off message type number for the
header without microseconds.  For example, all the message types i've seen
have a type < 64, so anything >= 64 should just have the microsecond field
(or if the MSB of the type is 1, as I suggested above).

the draft should explicitly indicate whether microseconds are included in the
header's length field.

> I'm worried that might push the document outside the scope of the GROW WG.

no, what i had in mind was merely something to a) identify files and
b) point blame.  eg:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    magic number               |                0              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Length                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | string = "MRTDATA"
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      tool name                |                0              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Length                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | string = "zebra 0.93"
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+