Subject: Re: [GROW] RFC 6396 on Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format

From: Claudio Jeker <[email-masked]>
Date: Tue, 1 Nov 2011 08:02:28 +0100

Ugh, it is unfortunate that a RFC was pushed that is incompatible with the
largest collection of MRT files. The RIPE RIS project dumps their data in
a different TABLE_DUMP_V2 format. Also unfortunate is that the example in
Apppendix A in the RFC itself is not compatible with the RFC -- appart
from having a badly encoded MP_REACH_NLRI attrubute in it (which I just
realized now).

The problem is that at least quagga does not follow the RFC in regards of
encoding the MP_REACH_NLRI. Instead of dumping the data only with the
nexthop len and nexthop information the full MP_REACH_NLRI is dumped.
AFAIK quagga is appart from OpenBGPD-current the only other bgp daemon
able to create TABLE_DUMP_V2 dumps and because of the RIPE RIS project
also probably the defacto standard. So people implementing MRT parsers
based on the RFC will be in for a surprise when looking at the most
commonly available MRT dumps.

-- 
:wq Claudio

On Mon, Oct 31, 2011 at 09:52:15PM -0700, [email-masked] wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
>         
>         RFC 6396
> 
>         Title:      Multi-Threaded Routing Toolkit (MRT) Routing 
>                     Information Export Format 
>         Author:     L. Blunk, M. Karir,
>                     C. Labovitz
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       October 2011
>         Mailbox:    [email-masked], 
>                     [email-masked], 
>                     [email-masked]
>         Pages:      33
>         Characters: 73982
>         Updates/Obsoletes/SeeAlso:   None
> 
>         I-D Tag:    draft-ietf-grow-mrt-17.txt
> 
>         URL:        http://www.rfc-editor.org/rfc/rfc6396.txt
> 
> This document describes the MRT format for routing information
> export.  This format was developed in concert with the Multi-threaded
> Routing Toolkit (MRT) from whence the format takes it name.  The
> format can be used to export routing protocol messages, state
> changes, and routing information base contents.  [STANDARDS-TRACK]
> 
> This document is a product of the Global Routing Operations Working Group of the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   http://www.ietf.org/mailman/listinfo/ietf-announce
>   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 1 Nov 2011 12:59:21 -0400

equally unfortunate that this discussion happened after the WGLC, IESG
CALL, IETF LC ... and ... auth48... etc.

how would you like to remedy this? (I bet the software will keep on
chugging, right? so what's the real impact here?)