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

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

Hi Henk,

Thanks for the info. Regarding the metric types,
as a new reader of the draft, I interpreted the new
Extended Reach as the successor to the old 128/130
and assumed (always dangerous! :-)) that the old
semantics applied to the new TLV unless otherwise
noted (and then wondered where the darn metric type info 
had hidden :-)). I wonder, since there is already some
text about how the new Extended Reachability differs 
from the old TLVs (e.g., wider metric, upDown bit, 
different prefix encoding), and given that there have 
been a few folks asking about the metric type, could 
perhaps a simple sentence about no differing metric type 
support be added?  No biggie since I now understand the 
intent, but it might help in the future.

>> and implementers could just 
>> assume that info supplied via the Extended IP Reachability TLV
>> should be treated as though it had comparable "internal" metrics.
>
>  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).

What I was trying to get at here is the question of what
the preference rules should be in an environment where there 
is no longer such a thing as a metric type (since the existing 
rules take the metric type into account, but the new Extended Reach 
has no metric type information). What I think was suggested
was to take the old preference rules, throw out
those that keyed off of external metric type, and
use those rules that only depended on internal metric type
as though the metric in the Extended Reach is
comparable (as though internal type). 

If I've read RFC2966 properly, it appears that the only 
key pieces of information in the preference rules are
the LSP Level, the UpDown bit, and the metric type
(other info, such as TLV type boils away)... yielding
something like the following:

Pref 1: L1 IntMet UD0 (128 or 130 a dont-care)
Pref 2: L2 IntMet UD0 (128 or 130 a dont-care)
Pref 3: L1 IntMet UD1 (128 or 130 a dont-care)
Pref 4: L1 ExtMet UD0 
Pref 5: L2 ExtMet UD0 
Pref 6: L1 ExtMet UD1 

where UD# is updown status 0 or 1, IntMet/ExtMet are
internal/external metric type.

Is it envisioned that the preference rules after
switching to the Extended Reach will be like the
first three, so something like
   Pref 1: L1 UD0 
   Pref 2: L2 UD0 
   Pref 3: L1 UD1 

or is something different planned?
Is there any documentation that discusses
what the preference rules should be when running
with the new Extended Metric TLV?

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 21:25:41 -0700 (PDT)

> I wonder, since there is already some

  OK, will do.

> comparable (as though internal type). 

  Yes. Everything the same order, just simplified by having less
 types of routes. 

> internal/external metric type.

  I think RFC2966 is very precise on that. See paragraph 3.2, called
 Order of preference for all types of IP routes in IS-IS.

--snip----

     Based on these assumptions, this document defines the following route
      preferences.

       1) L1 intra-area routes with internal metric
          L1 external routes with internal metric
       2) L2 intra-area routes with internal metric
          L2 external routes with internal metric
          L1->L2 inter-area routes with internal metric
          L1->L2 inter-area external routes with internal metric
       3) L2->L1 inter-area routes with internal metric
          L2->L1 inter-area external routes with internal metric
       4) L1 external routes with external metric
       5) L2 external routes with external metric
          L1->L2 inter-area external routes with external metric
       6) L2->L1 inter-area external routes with external metric

--snip----

  So that is very similar to what you describe.

> first three, so something like

  Correct. Otherwise you get routing loops.

> with the new Extended Metric TLV?

  I had thought it was clear. I will add some text in the upcoming
 version of the draft.

     henk.

---

From: David Hudek <[email-masked]>
Date: Thu, 07 Jun 2001 13:53:36 -0700

>  I had thought it was clear. I will add some text in the upcoming

Great, thanks...

It certainly is the reasonable pref order, and is implied
in several places, but I think that making it crystal clear with 
an explicit statement would be a GoodThing

Either stating them for the new Extended Reachability
universe, or a simple statement that the preference
rules in rfc2966 will apply using the interpretation that
routes learned via the Extended Reach must be treated
as though they had an internal metric type for the
purpose of preference calculations ?

Otherwise, someone could argue that the preference order
is unspecified, since none of the rules mentioned earlier
--snip----
     Based on these assumptions, this document defines the following
route
     preferences.
       1) L1 intra-area routes with internal metric
          L1 external routes with internal metric
       2) L2 intra-area routes with internal metric
          L2 external routes with internal metric
          L1->L2 inter-area routes with internal metric
          L1->L2 inter-area external routes with internal metric
       3) L2->L1 inter-area routes with internal metric
          L2->L1 inter-area external routes with internal metric
       4) L1 external routes with external metric
       5) L2 external routes with external metric
          L1->L2 inter-area external routes with external metric
       6) L2->L1 inter-area external routes with external metric
--snip----
actually apply, since none of them match an unspecified metric type
(all require either internal or external for a match), and
the Extended Reach currently has an unspecified metric type.

The ordering for Extended Reach is strongly implied by the 
first and fourth assumptions in the paragraph prior to the
above rule set, but after painful experiences with some other 
protocols where things were assumed or implied but not specified,
I suppose I've become paranoid :-)  

Thanks,
dave h