How are the RIB entry BGP attributes represented according to RFC6396 (MRT Routing Information Export Format)

Question

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

Answer 1

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.

Answer 2

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