Clarification on object padding for Call-ID in RFC3474

["Rich Bradford \(rbradfor\)" <rbradfor@cisco.com>]

In RFC3474, section 4.1.1 describes the Call-ID.
The Call-ID has a variable-length field, the source LSR address toward
the end of the object as follows:

...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source LSR address                       |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local identifier  (continued)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the source LSR address length is defined its type:
      For Type=0x01, the source LSR address is 4 bytes
      For Type=0x02, the source LSR address is 16 bytes
      For Type=0x03, the source LSR address is 20 bytes
      For type=0x04, the source LSR address is 6 bytes
      For type=0x7f, the source LSR address has the length defined by
          the vendor

Since type=0x04 (and possibly type 0x7f) has a size that is not a
multiple of 4 bytes, the issue of padding and alignment is raised. Pad
bytes for objects are by default added to the end of an object and not
counted in the length (option A below). However, the diagram appears to
indicate 32-bit alignment of the Local identifier (Option B below).

So, for type=0x4, do we have:
A) Source LSR (6 bytes), Local Identifier (8 bytes), pad (2 bytes)
Or
B) Source LSR (6 bytes), pad (2 bytes), Local Identifier (8 bytes).

Thanks for your time,
 Rich