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

[Quaizar Vohra]

 > 
 > 
 > > Here is a list of possible route types (assuming external routes with
 > > internal metric type are the only ones supported).
 > 
 >   Why do you assume this ?
 >  RFC1195 specifies external routes with external metric type.
 >  Personally I don't think that is a very useful feature.
 >  As many of you know, our cisco IS-IS implementation never looked
 >  at the I/E bit. During the last several years, no customer has
 >  ever asked us to fix this. So I always assumed the I/E bit has
 >  limited use in real networks.
 > 
 >   Unfortunately (for me) one of our customers pushed recently to
 >  add a knob to recognize the I/E bit. For interoperability reasons.
 >  I am not too familiar with other IS-IS implementation, but I have
 >  been told that others either do recognize the I/E bit, or have
 >  knob to choose between recognizing and ignoring the I/E bit.

I have heard of OSPF deployments where type 2 routes are used. We
have had request from the customers requesting type 2 routes. I
personally feel that we should leave ISIS flexible to support this.

 > 
 > > 1) L1 intra-area
 > > 2) L1 external (imported from other protocols)
 > 
 >   So I think we must split this one in two.
 > 
 > > 3) L1 -> L2 inter-area (L2 intra-area leaked into L1)
 > 
 >   Guess this is a typo ?
 >  You mean (L1 intra-area leaked into L2) ?
 > 
Sorry, that's a typo.

 > > 4) L1 -> L2 external (L1 external leaked into L2).
 > 
 >   Yes, you could see this one as different from 3).
 >  But because RFC1195 does not specify L1 externals, RFC1195 does
 >  not specify whether L1 externals should be advertised into L2 as
 >  TLV128 or TLV130.
 >   FYI our cisco IOS advertises L1 externals into L2 as TLV128.
 > 
 >   I am sorry if someone does not like me mentioning how our cisco IOS
 >  does certain things that are not fully specified in rfc1195.
 >  But the goal of draft-ietf-isis-domain-wide-01.txt is to do something
 >  that is backwards compatible with the current installed base. So I
 >  think it is sometimes useful to describe current IOS behaviour.
 > 
 > 
 > > 5) L2 intra-area
 > > 6) L2 external 
 > 
 >   Again, I think we must split this one in two.
 > 
 > > 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.
 > 
 >   Agreed.
 > 
 > > From TE draft one can't differentiate between 1) & 2),
 > 
 >   Agreed.
 >  Note that rfc1195 says that there should be no difference in preference
 >  between IP prefixes advertised in TLV128 and TLV130. Our implementation
 >  does not even store the difference in the RIB. So Tony Li's first idea
 >  was that if there is no difference, why maintain it in the new draft ?
 >  I agree with him.

I personally disagree with rfc1195 on this preference order. One of
the reason is that if you are importing a route into ISIS from another
protocol, e.g. OSPF, you can come up with a scenario where the
imported route ends up getting preferred over the OSPF route.

I guess I need to be more clear :-)

Lets say you want to give higher preference to ISIS internal routes 
over OSPF internal routes. But you import OSPF routes into ISIS
preserving the metric (though it might be unclean to do so) you
might end up preferring the imported route simply because you
choose to give it the same preference as an ISIS internal route.

This causes pain when you are running ISIS and OSPF adjacently
with 2 or more routers on the boundary leaking routes either
ways. (I am no proponent of doing this :-) but I have seen
customers running into such situations and it would be clean
if the protocol helped in preventing such situations).

Our implementation had so far not given the same preference
to ISIS L2-intra routes as L2-external routes.
           

 > 
 > > nor between 3), 4), 5) & 6), nor between 7) and 8).
 > 
 >   Agreed.
 > 
 > > external routes.
 > 
 >   Can't parse this sentence. ;-)
 > 
 > > 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
 > 
 >   Agreed.
 >  I see you added a 9th route 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.
 > 
 >   Agreed.
 > 
 > > 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) 
 > 
 >   I don't agree here.
 >  I think L2->L1 inter-area routes should have the lowest preference.
 >  That means:
 > 
 >    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.
 > 
 >   We thought about that.
 >  Tony came up with the nice idea that the prefix lenght only needs
 >  6 bits, so we had two bits to play with.
 >  Having the up/down bit is clearly very useful.
 >  Now what to do with the second bit ?
 >  We thought about using it for either
 >  a) Internal/external route-type bit (like TLV128 vs TLV130)
 >  b) Internal/external metric-type bit (like the old I/E bit)
 >  c) as a flag to indicate the existence of sub-TLVs
 > 
 >  a) is specified in rfc1195, but not used. so why waste the bit on this ?
 >  b) is specified and used in rfc1195. but in real life nobody uses it.
 >     so why waste the bit on this one ?
 >  c) using the prefix notation from BGP in ISIS gives us a win in the
 >     number of bytes used per IP prefix. In rfc1195 we use 12 bytes per
 >     prefix. 256 fragments * 1492 - a little / 12 bytes per prefix
 >     means that the maximum number of IP routes advertised by a single
 >     router is something like 30K prefixes. With the BGP notation it
 >     would be something like 48K prefixes. Always including the sub-TLV
 >     byte would bring this down to 42K. Tony Li liked to keep the number
 >     of bytes per prefix low. Because a) and b) didn't make much sense\
 >     in our opinion I agree with him.
 > 
 > > 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.
 > 
 >   We thought about that.
 >  One of the main goals of draft-ietf-isis-domain-wide-01.txt is to
 >  be backwards compatible with current implementations running on
 >  L1-only routers. The "reserved bit" must not be set on transmision,
 >  and should be ignored on reception. But we feared that not all
 >  implementations could deal with this bit being set.
 > 

But wouldn't this be as worse as having the E bit set in TLV128
when rfc1195 says that it must be set to zero.

 >   Another reason is this:
 >  suppose you have a L2 prefix P, advertised by router A. Then two
 >  L1L2 routers B and C will leak it down into L1. Another L1-only
 >  router D will pick it up.
 >  P is advertised as external metric 5.
 >  The path-cost between A and B is 10. 
 >  The path-cost between A and C is 20.
 >  Suppose you could advertise the metric-type into the inter-area route.
 >  How are B and C going to advertise this into their L1 LSPs ?
 >  With the I/E bit set, and metric 5 ? Now D will not be able to see
 >  the real cost towards A.
 > 
 >   The reason we introduced L2->L1 interarea routes is so that L1-only
 >  routers know more about the cost of the L2 path. When external metrics
 >  are involved, the cost of the L2 path becomes less important. Thus
 >  L2->L1 inter-area routes become less important. So why even leak them ?
 > 

Yes, for external routes originated with external metric type it is 
not possible to preserve the path length to the originator in the L2
area when that route is leaked into L1. But if you were using internal
metric type then we can still preserve the path length to the originator.

 >   Yes, we could change draft-ietf-isis-domain-wide-01.txt to use bit 8,
 >  in stead of the I/E bit. If there are others on this list who also like
 >  to do this, let us know.
 > 
 > > 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).
 > 
 >   Agreed.
 > 
 > > 10) L2 -> L1 external with ext metric type
 > 
 >   Yes, this could be added.
 >  RFC1195 does not specify if a L1 external should be advertised into L2
 >  in TLV128 or TLV130. Yes, it would be useful to maintain this distinction
 >  between L1 and L2. Allas, unfortunately we can't maintain this distinction
 >  when doing L2 -> L1, as L2->L1 interara is always advertised into TLV128.
 > 
 >   Actually now that I think about it once more, this is a perfect reason
 >  to switch to your proposal to use bit 8 in stead of the I/E bit. If
 >  we use bit 8, we can do L2->L1 interarea routes in TLV128 and
TLV130.
 
Yes, by using bit 8 as the down bit, you can preserve the
external/internal semantics of a route.

 > 
 > > 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.
 > 
 >   Personally I don't like the idea of putting stuff in sub-TLVs that
 >  influences the basic SPF.

Well OSPF deals with this by originating ASBR summary LSAs. Personally,
I dont care about this too much for the time being. All I care is 
that we have the external metric type semantic still intact in the
protocol such that it can be utilized if required in future.

 > 
 > > 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. 
 > 
 >   Yes, 9) is easy to support if you use the trick from 10589.
 >  (multiply the external metric by 1024, and add the path cost).
 >  However it becomes a little more tricky when you mix TLV128/TLV130
 >  with TLV135.
 > 
 > > 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.
 > 
 >   I think L2->L1 should be the worst preference.
 >  Internal and external route-types should have the same preference.
 >  So I think the correct order would be:
 > 
 >  1) L1 intra-area, L1 external with internal metric
 >  2) L1 external with external metric
 >  3) L2 intra-area, L2 external with internal metric, L1->L2 inter-area
 >  4) L2 external with external metric
 >  5) L2->L1 inter-area
 > 
 >   This preference can be used on L1L2 routers, and then the L1-only
 >  routers with current implementations do not need to be upgraded.
 >  As this was one of the goals of draft-ietf-isis-domain-wide-01.txt,
 >  therefor I prefer the second scheme.

The reason I gave above about preferring internal routes over external
routes is true here too so I would like purely internal routes 
preferred over external routes, even if they are leaked from L2 to L1.
Also I would always prefer routes with internal metric type over
external metric type, even if they are imported from L2 into L1.

Actually I do tiebreaks to prefer L1 routes over L2 if the preference
orders is same for two different route types.

So the reasons for my order are :
1) Internal metric type should always be preferred over external
   metric no matter how the routes are leaked.
2) Routes learnt internally, within the ISIS domain should always
   be preferred over external rotes (to avoid the above situation
   I described).
3) Since we are doing this to allow for more optimal routing, I dont
   see why L2 intra-area routes leaked into L1 should not have same 
   preference as L1 intra-area routes leaked into L2.
4) L1 intra-area routes are preferred over L2 intra-area routes
   and all inter-area routes.
5) If there are routes of more than one type with equal preference, 
   best metric wins.
6) Among routes of equal minimal metric, one could either laod
   balance or apply tie-breaking rules (whichever happens to
   simplify the implementation), e.g. L1 wins over L2.

Note that the reasons are listed in decreasing order of decision
preference. 

I think this order as very clean. This might not be backward
compatible. I am not sure if this incompatibility is an
issue at all. Our deployments have given preference to internal
routes over external routes. I would like to think that
this statement, "Even if in the past you had given
equal preference to internal and external routes, lowering the
preference of external routes will not break things" holds true.

Anyways, I lack enough experience to say with certainity that
my suggested preference order is perfect. It may be far from 
perfect. But to me it intutively makes sense. 

So I will leave it to you guys to clean things :-).

Quaizar


 > 
 >   I can't remember why Tony Li decided to use the I/E bit, and not bit 8.
 >  Tony, can you refresh our memory ?
 > 
 >       Henk.
 > 
 >