Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt

From: David Hudek <[email-masked]>
Date: Tue, 05 Jun 2001 19:17:48 -0700

Hi all,

The latest ISIS TE draft I could find is the one mentioned in the 
subject. Assuming that's the latest, or that a later one has 
similar treatment (non-treatment) of external metric type, I'd like
to offer the following comments/suggestions.

First, let me say I'm no big fan of the external metric type, and 
it wouldn't bother me if it were to just fade away. It simplifies 
things nicely if all metrics are comparable. [Since no one has told 
me nay, I'm assuming that the previous "History of the External
Metric Type?" email is at least reasonably close to the actual state 
of affairs? If not, please let me know and perhaps the
rest of this comment will be filed under Rosanne Rosannadana
("nevermind..."  ;-))]

However, I'm more concerned with implementations' interoperability,
and so if it is going away, I'd like to see it do so in an orderly 
manner. If it's not going away, I'd like to see it defined in the 
relevant message. 

It's troubling to read of some folks just picking undocumented random
bits 
in the message to indicate metric type, while others do nothing and 
ignore it, and some talk of using an unspecified subTLV.

As I understand it, the draft rfc has an Extended IP Reachability TLV, 
which is intended to replace two of the original IP TLVs...
IP Internal Reachability (Type 128) and IP External Reachability
(Type 130) [the only really significant difference between the two being
that ExtReach could potentially use external non-comparable type
metrics,
while IntReach could not... and all reachability using
internal metric type, from either TLV, is treated similarly...
so the only distinguishing factor boils down to the
external metric type or not]

Besides other nice stuff, the new Extended TLV uses a wider metric. 
To my knowledge, no official subTLVs have been defined for it, and 
it intentionally makes no mention of the metric type. The rationale 
mentioned so far for this omission is that no one is using the 
non-comparable "external" metric type, and implementers could just 
assume that info supplied via the Extended IP Reachability TLV
should be treated as though it had comparable "internal" metrics.

However, that sort of advice has only been given via the mailing list 
and is not part of the (draft) rfc itself, where a future implementer 
could readily find it. Also, it is not clear that the rationale is 
correct, since at least one person posted to the list in the past that 
they intended to make use of some otherwise unused bit to indicate the
external metric type in their implementation. Others have mentioned 
using an undocumented subTLV type.

Can we decide if external metric type is *actually required*
(seems to be some disagreement?), and either:

    a) explicitly deprecate it in the TE spec.
       Some verbiage to the effect that the external metric
       type is no longer supported, and any metrics
       received via the Extended IP Reachability TLV
       MUST be treated as having comparable ("internal")
       metrics (is there anyone on the list who would
       strongly oppose such a thing?)

       OR

    b) explicitly specify a subTLV in which to convey the
       metric type. For a stake in the ground, how about
       something like the following (using least sig bit
       in the value as internal/external type, other bits
       sent as zero and ignored upon receipt), and since
       we only need one bit and it seems so wasteful to
       spend 3 octets to convey one bit's worth of data,
       possibly generalize the new subTLV into an
       "Extended Control Info" type for future general use 
       of the other bits if needed? :

       Extended Control Type SubTLV
          Sub-TLV Type:     1
          Sub-TLV Length:   1
	  Sub-TLV Values:   0 if metric is comparable (internal type)
                            1 if metric is non-comparable (external
type)

       If someone really really demanded symmetry with the
       old TLVs, one could use the second least sig bit
       to indicate internal or external reachability,
       but it's not clear that buys you anything?...
       (but for completeness, could use these values instead,
        with the upper 6 bits reserved, zeroed on send, ignored on
receipt)
          00 - metric is internal reach/comparable metric type
          01 - metric is internal reach/non-comparable metric type
(illegal?)
          10 - metric is external reach/comparable metric type
          11 - metric is external reach/non-comparable metric type)

If it's true that there's no real justification for external metric
type,
then I'd favor (a). If there are valid reasons for having it, then I'd 
favor something along the lines of (b) with things at least nailed down 
sufficiently for an implementation.

If this has been resolved after draft ver 02 or elsewhere, 
oops...  my bad!   and can you point me to it? 

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

---

From: Henk Smit <[email-masked]>
Date: Wed, 6 Jun 2001 16:21:11 -0700 (PDT)

> to offer the following comments/suggestions.

  Yes, version 02 is the lastest.
 I have been planning on releasing a 03 version for a long time.
 It will only have marginal changes (wording, not really semantics).
 RealSoonNow (sorry for the delay ....).

> it wouldn't bother me if it were to just fade away.

  If the whole world moves to TLV22 and TVL135, the old TLVs TLV128
 and TLV130 might go away. But I don't see that happening. So whatever
 we decide to do in the future, the fact will always remain that you
 will have to implement the old behaviour from RFC1195, for backwards
 compatability. No matter what.

> manner. If it's not going away, I'd like to see it defined in the 

  RFC1195 defines behaviour.
 I tried to clarify all route and metric types, and their preferences
 in RFC2966. I assume you read RFC2966. If not, please read it and
 tell us what parts you think are not clear. (I'm sorry if I messed
 up and blew the chance we had to clarify it).

> bits in the message to indicate metric type,
> while others do nothing and ignore it,

  Are you refering to the old cisco behaviour of picking bit-8 as
 the I/E bit, in stead of bit-7 ? That is clearly a bug, not picking
 random undocumented bits.

> and some talk of using an unspecified subTLV.

  This has been suggested to people who wanted I/E metric-type semantics
 in TLV135. That doesn't meant they implemented it, or their customers
 deployed it. I would assume that if anyone would implent something like
 this, they would try to document it before letting their customers
 deploy it on a grand scale.

> To my knowledge, no official subTLVs have been defined for it,

  Correct.

> and it intentionally makes no mention of the metric type. The rationale 
> non-comparable "external" metric type,

  Correct. Plus we didn't have a spare bit. Plus we (the draft authors)
 didn't like to add complexity with little gain. So far no one has been
 able to convince the working group that we absolutely need I/E metric-type.

> and implementers could just 

  No sure what you mean here ?
 TLV128/TLV130 are to be seen totally disjunct from TLV135.
 Networks should not be combining them. (Maybe they can be flooded
 in parallel while a network migrates from the old to the new TLVs,
 but you should *never* have some routers use the old metrics during
 SPF, and some other routers the new metrics).

> could readily find it.

  I tried to clarify all route-types and metric-types from RFC1195,
 plus "route leaking" in RFC2966. The TE-extensions TLVs are totally
 disjunct from that.

> Also, it is not clear that the rationale is 

  As long as they don't post a draft, and don't pass the requirements to
 turn the draft into an RFC (even an experimental rfc), they can not
 go tell their customers anything else but that they have implemented
 a proprietary extension. Nothing wrong with proprietary extensions, but
 customers might decide not to bother with the hassle.

> sufficiently for an implementation.

  When you write an ISIS implementation that is supposed to be compatible
 with RFC1195 and RFC2966, you better implement external metric. Sorry.
 When you implement the extensions from the te-draft, you can forget
 about I/E metrics. If you wanna be compatible with both, you better
 implement both algorithms. Not really rocket-science, IMHO, just a
 small matter of coding. :-)

   Hope this helps,

       henk.