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

From: "Odak, John" <[email-masked]>
Date: Fri, 9 Mar 2001 13:33:43 -0500

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

---

From: Henk Smit <[email-masked]>
Date: Fri, 9 Mar 2001 22:25:26 +0100 (MET)

Hello John,

> that will indicate whether sub-TLVs are present.

  As others have pointed out, what happens if you put multiple IP prefixes
 in one TLV135 ? What comes after you have decyphered the first IP prefix ?
 Some sub-TLVs or the next IP prefix ?

> only 5 are required. One of the bits should be freed for possible future or

  IP prefixes have a length between (and including) 0 bits (aka the default
 route) and 32 bits (aka host routes). That are 33 different values.
 Please enlighten us how to fit 33 values in 5 bits .... ;-)
 I think you are just of by one.

> total length of any sub-TLVs.

  Same thing as above. Don't forget you can put multiple IP prefixes in
 TLV135, all which might have sub-TLVs.

> enclosing TLV already has a length field that will indicate the total length

  Same thing.

> page apart, shouldn't they look a little more like each other?

  This is intentional, and you'll have to blame Tony Li for this.
 The assumption was that a router can have tens to hunderds of adjacencies.
 In the worst case maye thousands. But a router might advertise thousands,
 maybe even hundreds of thousands of IP prefixes. Therefor we think that
 conserving space in TLV135 is more important than conserving space in TLV22.
 Another reason is that sub-TLVs in TLV22 are common, while sub-TLVs in
 TLV135 are hardly seen today. (There are plans for IP prefix coloring, and
 for multicast tags).

> waste of the relatively small 254 bytes of potential value space.

  You don't know what sub-TLVs will exist in the future. So once your code
 encounters a sub-TLV it doesn't understand, the Length will allow you to
 skip it. This is a great help in the real world when ISP and enterprises
 want to migrate to newer version of the protocol without first upgrading
 all the software on all their routers.

> - Why are the sub-TLVs referred to as sub? Aren't they just TLVs?

  Because sub-TLVs are TLVs inside TLVs.
 Giving them a different name makes it easier to discuss them in discussions.

> It looks
> will we have sub-sub-TLVs?

  Maybe. That is up to the authors of new extensions that define new
 sub-TLVs. If they wanna use TLV encoding inside their sub-TLVs, that
 is fine with me. I guess those thingies will be called sub-sub-TLVs.

> It would seem that a more general and consistent

  The current encoding is all in the same spirit of the original ISO 10589.
 Using ASN.1 might be an improvement in itself, but it would also imply
 a big change in "style" of the protocol. I am not sure everybody likes
 this. And we wanna keep it simple. Maybe if people come up with a brand
 new routing protocol.

> rework. But since the document is still a draft

  The document is a draft document. That implies we can change the text.
 That does not necessarily imply that we wanna change the content itself
 (the protocol). After all, the TE extensions are not just experimental
 anymore. They are used in the real world.
 
> and is introducing sub-TLVs,

  IMHO the current draft is just that: a framework. It defines how
 sub-TLVs are used in TLV22 and TLV135. People that wanna experiment
 with new stuff can add any information they want to link or prefixes.
 Expanding this framework to other protocols is overkill IMHO, as many
 protocols have different needs.

  You might notice that all newer protocols nowadays make use of TLVs.
 See attributes in BGP for example.
 Hope this helps,

      henk.