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

From: David Hudek <[email-masked]>
Date: Tue, 29 May 2001 19:19:45 -0700

Hi all,

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).

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.

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. 

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. 

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.

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.

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.

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 ?  :-)

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), 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 ?

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