Re: OSPF TLVs

[Kireeti Kompella <kireeti@juniper.net>]

On Thu, 6 May 2004, Naidu, Venkata wrote:

> Kireeti,
>
>   Good that you are listening to this :-)

Eventually -- sorry I wasn't paying attention.

>    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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Type             |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Value Current...                         |
>    .                                                               .
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                      Value Reserved...                        .
>    .                                                               .
>    .               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .               |                   Pad ... (0-3 octet)         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Adrain said: if there is "reserved space" inside the Value
>   field, that must be included in the Length field.
>
>   I said: In such an interal "reserved space" case, there must
>   be some way to know the boundary to parse and seperate the
>   "Current value" field and "Reserved value" field. If the Length
>   field signifies both "Currnet + Reserved" values then the only
>   way to know the boundary is by Type field.
>
>   Both of us agreed on:
>
>   1. Renaming "internal value padding" to "Reserved Value"

Thanks to Acee, I now know what document you're talking about -- for
some reason, I only have the latter part of this thread.

Looking at the GMPLS OSPF doc, I see the following issues:

a) Link Protection Type

   This should really have length 1 octet, and that's it.  On the
   other hand, having the Reserved field allows for future expansion,
   (and there are implementations) so I'd say, leave this as is.

b) Interface Switching Capability Descriptor

   Here there are two "reserved" fields, the one after encoding
   (which is just fine), and the one in the Switching
   Capability-specific information.  I suspect it's the latter that's
   the burning issue.

   My inclination is to remove the "padding" fields from the figures
   and text, and to make the following clarification:

  "The Switching Capability (Switching Cap) field contains one of the
   following values (the Length field in the table specifies the
   length in octets of the Switching Capability-specific Information
   field):

       Value     Switching Capability                     Length
       -----     --------------------                     ------
           1     Packet-Switch Capable-1 (PSC-1)               6
           2     Packet-Switch Capable-2 (PSC-2)               6
           3     Packet-Switch Capable-3 (PSC-3)               6
           4     Packet-Switch Capable-4 (PSC-4)               6
          51     Layer-2 Switch Capable  (L2SC)                0
         100     Time-Division-Multiplex Capable (TDM)         5
         150     Lambda-Switch Capable   (LSC)                 0
         200     Fiber-Switch Capable    (FSC)                 0 "

(BTW, looks like we forgot FSC ....)

Any objections to the above?  Any implementations that use different
values for the length?

>   Now please tell me, am I clear this time ? :)
>   If I am wrong, where am I ?

You are clear; not wrong.  I just didn't have context when I first
read this.

Kireeti.
-------