[Isis-wg] Clarification needed on domain-wide prefix distribution

[Quaizar Vohra]

Folks,
	Here are some issues related to domain-wide prefix
distribution draft and TE draft I would like clarification on.

I did like to clarify the preference order among different types of
routes for inter-operability purpose. Here is one possible way to do
it which actually is enforced implicitly by both the drafts.

Here is a list of possible route types (assuming external routes with
internal metric type are the only ones supported).

1) L1 intra-area
2) L1 external (imported from other protocols)
3) L1 -> L2 inter-area (L2 intra-area leaked into L1)
4) L1 -> L2 external (L1 external leaked into L2).
5) L2 intra-area
6) L2 external 
7) L2 -> L1 inter-area (L2 intra-area leaked into L1)
8) L2 -> L1 external (L2 external leaaked into L1)

There is no way to distinguish between 7) and 8) in the domain-wide
draft. From TE draft one can't differentiate between 1) & 2), nor
between 3), 4), 5) & 6), nor between 7) and 8).
external routes.

Now if one notes rfc 1195, it recognizes a subset of the above
route types and treats them in the following order of 
decreasing preference :

1)
3) == 5) == 6)
9) L2 external routes with external metric type

Note that it treats L2 intra-area and L1->l2 inter-area and L2 external
routes with internal metric type equivalently, i.e. they have the same
preference and the lower metric wins.

If one follows the same philosophy, i.e. treating external routes with
internal metric type learnt in an area same as intra-area route, and
by the virtue of both the drafts we are forced with the following
order of decreasing preference.


1) == 2)
3) == 4) == 5) == 6) == 7) == 8) 

This said, I want the WG to consider the following :

We still want the external routes to be distinguishable so as
to allow filtering capcabilities when leaking routes from L2 to L1.
So it would be be nice if the TE draft could be updated to either
reserve a bit or add a subtlv to allow for this distinction.

Also I wonder if there is any reason for not considering reserved bit
(bit 8) of the default metric in the IP reachabilty TLV in rfc1195 for
the purpose of a downbit in the domain-wide prefix distribution
draft. This would have left things cleaner.

Also it would be nice to have external routes with external metric
types. One can imagine the following additional types of routes

9) L2 external with external metric type (rfc1195 supports this).
10) L2 -> L1 external with ext metric type
11) L1 external with external metric type
12) L1 -> L2 external with ext metric type

9) and 11) could still be supported with the existing domain wide 
prefix dist draft without any change. It would be nice if TE
draft could add capability for such a distinction.

10) and 12) cant be supported without loss of knowledge of the
distance to the exit router which originated the route as we do not
keep any metric in the IP prefix TLV which preserves the distance from
the exit router who originated the route, to the guy who's leaking the
route across levels.  OSPF deals with that in one fashion. We could
deal with it by introducing a subtlv which preserves this knowledge.

Anyway 10), 11) , 12) need not be supported till a need for them
is known. 9) is easy to support and in fact thats the only 
thing rfc1195 supports. 

Also it would make more sense to have the following order of 
decreasing preference of routes from implementation perspective.
One might further specify tie-breaking rules for routes with
same preference but different types.

1) L1-intra
2) L2-intra, L1->L2 inter-area, L2->L1 inter-area
3) L1-ext, L2-ext, L1->L2 ext, L2->L1 ext (all with internal metric
   type).
4) all external routes with external metric types.

This is incompatible with rfc1195 by not treating L2-intra and
L2-external routes with internal metric type equivalently.  But all
the deployed base I know of happens to violate rfc1195 on this issue.


Quaizar