The RFC6396 specifies the header for RIB-entry mrt-records like this:

        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 Index            |
       |                         Originated Time                       |
       |      Attribute Length         |
       |                    BGP Attributes... (variable)

But the textual explanation (link) does not specify how and in which order the BGP Attributes have to appear. Assuming that they mean path attributes of the BGP-4 standard.

How and in which order are the BGP attributes to be represented to be consistent with RFC6396 (Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format)?


It turns out the attributes are encoded the same way RFC4271(BGP-4) specifies them. In a previous draft it was even explicitly stated but it got somehow dropped in the final version:

...the BGP path attribute length and attributes encoded as provided in a BGP Update message.

Each path attribute is therefore a triple <attribute type, attribute length, attribute value> of variable length and its exact layout/specs can be read at the corresponding RFC.


I'm guessing it grabs that info from the Update Message, which contains a 2 byte Path Attribute Section.

  • as this RFC is on standard-track I was hoping for another RFC or author comment on how to do it. Further is your answer in this wording wrong or at least misleading as an attribute is a triple <type,length,value> where the first two elements alone are 3-4 byte. (Not mentioning possible other listed attributes) – Sim Sep 24 '14 at 16:15
  • Wow, there are other ways to express the same. I was trying to help. – Luis Ramos Oct 10 '14 at 2:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.