The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Mike,

    The two TLVs you mention are used in link hello messages
and must be understood by any compliant LDP implementation.
Hence, the U bit must be clear (=0).  Since the U bit must be
clear, the F bit is without meaning and should be clear (=0) as
well (this would be the correct setting in any case).

    This could be considered an over-sight, but it should not be
an important one.  The U and F bits are added in order to allow
for compatibility with future LDP extensions and it was NEVER
intended that any LDP implementation should be allowed to not
understand TLVs defined in this version and in this specification.
You can verify this simply by looking for the string "|1|" which
would be present in the specification if any of the TLV formats
specified a "U bit" value of '1'.

    I believe the oversight occurred because these bit values
were (in earlier iterations) previously included in the TLV
type number and were moved to the ASCII art formats.  As
there are no 'pictures' of the format for the TLVs you point
out, this didn't happen for these TLVs.

--
Eric Gray

"Michael H. O'Meara" wrote:

> Hello all,
>         Section 3.3 of RFC 3036, the LDP Specification, states the
> following about the usage of the U-bit in TLV encoding:
>
>    U bit
>       Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
>       (=0), a notification must be returned to the message originator
>       and the entire message must be ignored; if U is set (=1), the
>       unknown TLV is silently ignored and the rest of the message is
>       processed as if the unknown TLV did not exist.  The sections
>       following that define TLVs specify a value for the U-bit.
>
> The RFC goes on to specify the value of the U-bit for most TLVs. However,
> no value is specified for certain optional TLVs, such as the Configuration
> Sequence TLV and Transport Address TLVs that are optional in Hello
> messages. Is it safe to assume, then, that the value for the U-bit in
> these optional TLVs is left to the discretion of those implementing the
> RFC? While an expected value for the U-bit is obvious for certain of these
> TLVs (as silently ignoring a Transport Address TLV, for example, could
> lead to some difficulty in establishing an LDP session TCP connection),
> there seems to be some leeway, and thus the potential for occasional
> interoperability problems, for some of the other optional TLVs. If I am
> missing something in the RFC, or making problems where there are none,
> please point me in the right direction.
>
>                                 Thanks in advance,
>                                         Mike
>
> ***************************
> Michael O'Meara
> Technician
> MPLS Consortium
> InterOperability Lab
> University of New Hampshire
> ***************************