Subject: Use of the U-bit for TLV encoding in LDP

From: "Michael H. O'Meara" <[email-masked]>
Date: Fri, 23 Mar 2001 11:23:28 -0500

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
***************************

---

From: Eric Gray <[email-masked]>
Date: Mon, 26 Mar 2001 11:58:14 -0500

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