Subject: RE: [Isis-wg] TE TLVs/Sub-TLVs

From: Satish Dattatri <[email-masked]>
Date: Fri, 9 Mar 2001 11:23:33 -0800

Hi,

By removing the 'L' in the sub-TLV it would cause headache for
implementations (other than cisco for now) not knowing a particular 
*reserved* sub-TLV's length. An implementation will now have to 
skip the rest of the data in TLV after hitting a unknown type.
This may not be desirable.

But by making the length of all sub-TLV types well-known and 
constant (no more *reserved* types), then the 'L' in the sub-TLVs 
can be removed and it becomes sub-TV ;-).
Multiple values now will be in multiple sub-TV's (for ex. IP V4 interface
addresses).

Satish

-----Original Message-----
From: Odak, John [mailto:[email-masked]]
Sent: Friday, March 09, 2001 10:34 AM
To: [email-masked]'; [email-masked]'
Subject: [Isis-wg] TE TLVs/Sub-TLVs

TE Authors,

Please forgive the lateness of these comments on the TE draft
(draft-ietf-isis-traffic-02.txt), but I only recently started looking at it
- and ISIS itself for that matter - and I have a few somewhat obvious
comments about the TLVs/sub-TLVs that you've specified. Again, please
forgive this post if these issues have already been discussed and resolved.

Specific comments:

- The Extended IP Reachability TLV (type 135) has a one-octet control
information field that uses 1 bit to indicate the existence of sub-TLVs.
This is not necessary because the enclosing TLV already has a length field
that will indicate whether sub-TLVs are present.

- The Extended IP Reachability TLV (type 135) has a one-octet control
information field that sets aside 6 bits for the IPv4 prefix length when
only 5 are required. One of the bits should be freed for possible future or
experimental use.

- The Extended IP Reachability TLV (type 135) potentially has a one-octet
field to indicate the total length of any sub TLVs. This is not necessary
because the enclosing TLV already has a length field that will indicate the
total length of any sub-TLVs.

- The Extended IS Reachability TLV (type 22) has a one-octet field to
indicate the total length of any sub TLVs. This is not necessary because the
enclosing TLV already has a length field that will indicate the total length
of any sub-TLVs.

General comments and issues:

- The Extended IS Reachability and  Extended IP Reachability TLVs are
inconsistent in the manner in which they specify the presence of sub-TLVs.
Since both definitions are from the same document, and in fact are only one
page apart, shouldn't they look a little more like each other?

- All of the sub-TLVs have been defined in terms of the Type-Length-Value
encoding format, but none has a variable length. This seems to be a real
waste of the relatively small 254 bytes of potential value space.

- Why are the sub-TLVs referred to as sub? Aren't they just TLVs? It looks
like there's still plenty of open space in the main Type range to
accommodate them, and many others for that matter. In a future enhancement,
will we have sub-sub-TLVs? It would seem that a more general and consistent
method for specifying, grouping, and encoding information might be called
for - ASN.1/BER comes to mind.

I realize that many vendors have already implemented this draft - my company
being one of them (I think they'll flog me for this posting), and that some
of the comments, while they will not add much functional value, will require
rework, and in the case of the general comments, possibly quite a lot of
rework. But since the document is still a draft and is introducing sub-TLVs,
it might be nice if it also established a framework that could be copied and
built upon instead of just something that can be made to work.

John Odak
[email-masked]

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Fri, 09 Mar 2001 14:44:02 -0500

I realize this has already been answered, but I think it needs to
be stated more emphatically.  Implementations are REQUIRED to ignore
TLVs they don't recognize.  For this reason, the length field is
NECESSARY.

I assume this is also true for sub-TLVs (is it stated in the draft
that unrecognized sub-TLVs are to be ignored?)

Jeff