Subject: Re: [Isis-wg] History of the External Metric Type?

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

Hello Dave,

> Before embarking on an ISIS implementation, I've been perusing 
> the wg mail archives, and I want to make sure I understand the 
> current status of the (effectively deprecated?) 
> "external metric type" indication (or perhaps more clearly, 
> the non-comparable metric type indication).

  I don't think the internal/external metric-type has been
 totally deprecated. It is still in the spec. And in fact,
 I tried to clarify it a little in rfc2966.

> The following is my current understanding... please
> let me know if it's correct or if I've gone delusional  ;-)
> (and if the latter, what the real situation is, thanks :-) )
> 
> When the spec was first defined, it was thought that
> users might want to inject routes into ISIS from
> other sources, and those other routes might come in
> two flavors: 
>     a) those using metrics which are directly comparable
>        with the metrics used by ISIS, and 
>     b) those using metrics which are NOT comparable
>        with the metrics used by ISIS.
> The "metric type" indication was defined as a mechanism
> for distinguishing between these two types, with
> the comparable metrics being identified as 
> "internal metric type", and the non-comparable metrics
> being identified as "external metric type"
>
> Only the internal metric type was valid for IP Internal 
> Reachability information. Either internal or external
> metric type would be valid for IP External Reachability
> information. IP External Reachability info using
> internal metric type would be treated similarly
> to Internal Reachability info, but IP External Reachability
> info would be less preferred if it used external
> metric type instead.

  Correct.

> Then, the RealWorld(TM) intervened  :-)
> 
> In the dominant early implementation (presumably cisco's),
> the internal/external metric type field was accidentally ignored,
> and all IP Reachability was treated as having internal
> metric type. 

  Yes. But there were in fact three things wrong:
 1) older IOS ignored the internal/external-metric bit on receipt
 2) older IOS would not mask out the first two bits (reserved and
    I/E bit), so during SPF, it would just use the 8-bit value.
 3) when setting the I/E bit (doable via route-maps), it would set
    the wrong bit: it would set bit 8, in stead of bit 7.

  The result would be that if you would manually set the I/E bit,
 the metric would be increased by 128 (2^7). And when the receiving
 routers do their SPF computation, they would handle the prefix as
 if it had a way larger metric. By accident, the results would be
 pretty similar to what you would have gotten if you would have
 just given those prefixes lower preference because of the I/E bit.
 Lucky.

  Maybe if anyone is interested, cisco people can explain the current
 behaviour.

> No one complained.
> 
> It is presumed (known??) that this is because customers never 
> actually made use of the external metric type capability, rather 
> than because they did try to use it but then never noticed odd 
> but still workable routes chosen because of comparing what were 
> intended to be incomparable metrics. 

  IMHO relying on redistribution and detailled redistribution features
 in particular, often points towards a bad network design. (Again, this
 is just my opinion). Leaking all specific routes is often not necessary.
 And if it is, it should be *reachability* information, not necessarily
 *routing* information. Using typical redistribution would cause all
 traffic to go to the closest redistribution-points. If you make metrics
 be advertised between routing domains to force some "further-exit routing"
 behaviour, you are making life more complex than probably necessary.
 Also, leaking metrics between routing domains will make it more likely
 that routing instability in one domain will cause instability in the
 other domain.

  Plus ISPs (the typical users of Integrated IS-IS), often carry as
 much information in BGP as they can. So if you *have* to redistribute
 something from outside your network, they rather redistribute it into
 BGP, in stead of their IGP.

> As long as every interworking implementation calculated things
> in the same manner, loops were avoided, and things worked out
> in a manner satisfactory to the customers.
> 
> Subsequent implementations by others either also ignored the 
> external metric type, or provided a configurable knob to turn 
> its recognition on/off for compatibility purposes and everyone 
> was(is) just turning it off. So far there has apparently not been
> any hue and cry for the restoration of the capability, and
> as a practical matter everyone is fine with only using
> comparable metrics.

  FYI, about 2 years ago, there was one cisco customer that wanted the
 I/E metric bit to work. (Both for IP and CLNS routing). A knob
 was added to turn on the correct behaviour. (My excuses to the list
 for this vendor specific information).

> Given that IP External Reachability with internal metrics
> is treated similarly to IP Internal Reachability, and that
> IP External Reachability with external metrics is not actually used
> in practice, there no longer appears to be any significant difference
> between IP Internal/External Reachability, and so no longer
> any need for separate TLVs.

  Exactly.
 I have never really understood the need for both TLV128 and TLV130.

  This was also one of the reasons why we decided to not carry the
 I/E metric bit semantics forward into TLV135 (the new IP prefix TLV
 defined in the IS-IS TE extensions draft). (The most important
 reason was of course the fact that we had no bits left, and did not
 want to spend another byte per prefix).

> Given all that, and being practical folks, as new enhancements
> were proposed, they were(are) no longer explicitly including the
> capability of distinguishing between internal/external metric type.
> For instance, (if I'm reading it correctly) 
> the ISIS extensions for TE draft-rfc intentionally
> leaves out any internal/external metric type, as well as
> lumping together all IP Reachability into one (extended) type.
> Going forward, the net effect seems to be a deprecation of the 
> comparable/noncomparable metric idea, in favor of all IP reachability 
> info using a single comparable metric type.

  Correct.
 It remains to be seen how long the old TLV128/TLV130 will stay around.
 My guess is it will be a long time .....

> There exists the possibility for subTLVs in the IP Extended
> Reachability, 
> but so far no-one has publicly defined any subTLVs to revive the 
> internal/external (comparable/noncomparable) metric type distinction.
> 
> The above is my best guess as to the current state of
> affairs, treating what had been implied in some earlier emails
> as explicitly true. How far off am I ?  :-)

  You are correct.

> Assuming that the above isn't too far off the mark,
> assuming that implementations will not properly interwork if
> they calculate routes differently (and that they will calculate
> routes differently if one recognizes external metrics and
> treats them differently from internal, while another does not
> recognize external metrics or does but still treats them the same
> as internal),

  See my explication about how interpreting the metric field as a simple
 8-bit value in many cases gives a similar result as interpreting the
 I/E bit in the correct way.

> would it be reasonable for the external
> metric type to be "officially" deprecated and implementers
> strongly encouraged to ignore the external metric type if
> encountered (a "send yours as internal only, and ignore theirs"
> sort of deal), treating all as internal metric type ?

  I have no opinion on that.
  And by judging the (lack of) responses to your email, nobody else
 on this list seems to care in particular for one way or another.

  I'm afaid you'll have to implement the I/E bit semantics, even
 though none of your customers will use it. Sorry. :-)

      henk.

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