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

From: Jeff Parker <[email-masked]>
Date: Wed, 6 Jun 2001 09:46:59 -0400

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

Just to be clear about this, these metrics are quite different.
The worst metric for an internal reachability is preferred over
the best metric in external.  This could be visualized as an 
extra 9th bit that is set for external and cleared for internal. 
This would allow the two metrics to be mapped into a new
consistent value.  

Any route learned from another protocol (BGP, Static, RIP) gets 
an external: any route learned via the IGP gets an internalReach.
Of course, implementations have been known to import external
routes as Internal Reachability, but that was not the original
intention.  

There is an argument to be made that local policy should define
how metrics are mapped, and that since IS-IS is an IGP, we only
need to worry about local policy.  However, I like to have some
guidelines on interoperation between metric types.  It is bad
enough that we need to compare two types, with the 2 extra bits,
without adding an incomperable 3rd metric.  

- jeff parker

---

From: David Hudek <[email-masked]>
Date: Wed, 06 Jun 2001 14:24:03 -0700

Hi Jeff,

I think we probably agree?  ...but just want to drill down
to the detail to make sure.  I'm beginning implementation
soon and want to ensure I've got a reasonably accurate
understanding of the issues first (much easier to change what 
you haven't coded yet ;-) )

> Jeff Parker wrote:

I agree that the metrics (*if distinguished by a different metric
type*) are quite different, but I also believe they are not 
different only based on which TLV they arrive on, and if they
have the same metric type, then it doesn't matter if they're
internalReach or externalReach... at least, that's
my current understanding based on rfc1195 and some prior emails
on this list. Could we agree on one of the prior sentences if
it were changed to say: 
    The worst metric for an internal reachability is preferred over
    the best metric <add:"with external metric type"> in external
    <add:"reachability">.
  
    and, "External Reachability with internal metric type has
    the same preference as Internal Reachability."

I believe that the worst metric for an internal reachability would
not be preferred over a better metric in an external reachability
if that external reachability metric was of internal type (?)  I'm
basing that on my reading of the NOTE on page 29 of rfc1195,
where it says, if I'm interpreting it correctly :-), that
internal routes from Internal Reachability (presumably with internal
metric type since external metric type is illegal there) and external
routes from External Reachability with metric type internal,
are treated identically for the purpose of the order of preference
of routes, and the Dijkstra calc.

The terminology of all this can get quite confusing, with
the terms external and internal applying to both reachability 
as well as the metric type. Looking back, I wish they
could have used a different term for the metric type :-)

> routes as Internal Reachability, but that was not the original

Just curious... does anyone know why the original intent
was to separate routes into different reachability types like 
that (if it is indeed true that the only practical difference 
from a route calc point of view is the metric type, not the
reachability type) ?  Was it an aid to network managers in
wading through a bunch of show database output... help them
pick out which routes were from another protocol, based
on the reachability type?

> without adding an incomperable 3rd metric.

I'm not quite sure I understand the last part about 3rd metric?
As I understand it, today we have two reachability types and
two metric types (internal reach, external reach,
internal metric, external metric). With the new TE draft we now
have a new unnamed extended reachability type and no explicit
metric type... is that the third metric?  
And that's where some potential incompatabilities come in... 
if everyone agrees to treat the new extended one similarly to 
how they would treat the old internal reach with internal metrics, 
then we're fine, but if some folks continue with the external metric 
concept, encoding it in undocumented ways, then we'll have some
interworking problems. My motivation was just to nail it
down one way or the other... deprecate external metric type,
or continue with it but document how to encode it inside the
new extended reachability TLV so implementations will interwork. 

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