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

From: Henk Smit <[email-masked]>
Date: Fri, 1 Oct 1999 17:29:52 +0200 (MET DST)

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

  I'm one of the authors of both drafts.
 I was planning on adjusting draft-ietf-isis-domain-wide-01.txt, but
 unfortunately I haven't found the time to do it yet.

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

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

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

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

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

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

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

  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.

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

---

From: Quaizar Vohra <[email-masked]>
Date: Fri, 1 Oct 1999 14:26:23 -0700 (PDT)

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

 >  You mean (L1 intra-area leaked into L2) ?
Sorry, that's a typo.

 >  was that if there is no difference, why maintain it in the new draft ?

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.

 >  I think L2->L1 inter-area routes should have the lowest preference.

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.

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

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

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

 >  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

---

From: Rajesh Saluja <[email-masked]>
Date: Mon, 04 Oct 1999 15:40:51 -0400

Folks,
I am surprised to know that there can be L1 external routes also.
I thought that only L2 routers can advertise the external routes.
If there are L1 external routes, then how does a router in L2
knows about the advertising router present in L1 domain for 
calculating the metric. I do not see equivalent of OSPF type 4
summary LSA in IISIS.
Also the domain-wide prefix distribution draft talks about 
the following types of routes.
- L1 intra-area
- L2->L1 inter-area
- L2->L1 external
- L2 intra-area
- L2 external
- L1->L2 inter-area
and each can be distinguished according to the table given
in the draft. 
 
Is there any proposal to have L1 external routes and redistribution
of such routes into L2? 

Thanks,
Rajesh

---

From: Quaizar Vohra <[email-masked]>
Date: Mon, 4 Oct 1999 13:41:20 -0700 (PDT)

In case of external routes with internal metric type, one can update
the advertised prefix when leaking the route from L1 into L2 to
account for the cost of path from L1/L2 router to the originating
router. 

With external metric type this is a problem.

Well domain-wide prefix distribution draft seems not to preclude
external routes from being originated in L1. Section 3.0 rule 1)
says "Only L1 intra-area prefixes and external prefixes are
redistributed from L1 into L2".

---

From: Henk Smit <[email-masked]>
Date: Tue, 5 Oct 1999 17:40:03 +0200 (MET DST)

> I thought that only L2 routers can advertise the external routes.

  That is what rfc1195 says.
 Real world is different.

  One of the things I like about ISIS is that fact that it is
 simple and elegant. One of the reasons for that is that almost
 all protocol rules are within a single area (L1 or L2 area).
 Communication between L1 and L2 is maybe not always well defined,
 but it is easy to understand. This will make multiple levels (L3/L8)
 easy to do when the time has come.

  It is simple to take external routes from L2 and put them into L1.
 Just put TLV130 into your L1 LSPs.
 In the past some customers had network which ran in one flat area,
 which was a L1 area. A problem was that they could not do redistibution
 into L1. Yup, they should have migrated to a L2 area. But it was
 easier to just put TLV130 into L1 LSPs. Heck, we could have even
 put the redistributed routes into TLV128 if we wanted to.

> calculating the metric. I do not see equivalent of OSPF type 4

  Knowing where the ASBR is is not necessary for external routes.
 It is only necessary when the external routes are advertised
 with external metrics.
 As you probably have noticed yourself:
        external route-type != external metric-type.

  Yet another reason not to do external metrics. They add more
 troubles then that they solve real issues.

> Is there any proposal to have L1 external routes and redistribution

  I have promised to adjust draft-ietf-isis-domain-wide-01.txt to
 be more specific about route preferences. I am sorry that I have
 not found the time yet to do so.

        Henk.

---

From: Quaizar Vohra <[email-masked]>
Date: Tue, 5 Oct 1999 12:57:16 -0700 (PDT)

> 
 > Let's steer the recent threads a little bit here:
 > 
 >   1. draft-ietf-isis-domain-wide  solves one single problem for deployments that don't have the need to migrate towards
 >      TE extensions or don't want a "flag-day" solution but wnat to preserve 1195 compatibility.  So discussion about TE
 >      draft and this draft are orthogonal.
 >   2. I'm attaching the last version of the domain-wide draft to this mail that Henk didn't post yet so people can get on
 >      the same page. This is _not_ an official draft but a floating version between authors that was stable now for a
 >      while. Route preferences are clearly stated  Henk, please submit the new version ASAP. Thank you.
 >   3. I'm against using bit 8 in draft-ietf-isis-domain-wide since
this will break 1195.

	It breaks rfc 1195 as much as setting the I/E bit in TLV 128. 

 >   4. the numbering discussion is getting very confusing and I definitely got suspicious after a 9th and higher type of
 >      routes type started to show up. There are 2 levels of 2 TLVs (128 and 130) with 2 bit combinations (I/E = 0 or
 >      1) so maximum number of different route types 2^3 = 8 and from there encoding forces you to not differentiate
 >      things anymore!  I would strongly suggest to align the terminology to something saying  Level:TLV Type:Bit  like
 >      written in the attached draft to clarify the discussion, otherwise we'll name the same bit combinations with many
 >      different names (and if we do, let's update the table in the draft so one can translate easily).  With preferences,
 >      Henk was pretty much on the point except that I think that the fact was missed that L2,128,Internal routes MUST be
 >      preffered over anything level 1 external (of course only of interest for L1L2 and L2-only routers), otherwise we
 >      have external metric types overriding the internal ones and that has to lead to routing loops. I'd suggest to refer
 >      to the figure specifying the prefernce across the 8 types and let's discuss it from there. Route preference is
 >      absolutely critical (as are the 3 rules) so let's get that one
 > nailed clearly.

Well if one starts distinguishing routes which are leaked down, i.e.
from L2 to L1, you end up getting 4 more types of routes. The domain
wide draft tries to create the leaking down distinction by
screwing  external vs internal route distinction. Usage of 8th bit
does that more cleanly by not obliterating old semantics.

The route preference I had come up with was exactly in agreement to
what you are saying, that internal routes be preferred over external 
routes.

Quaizar

 >   5. critique on OSPF does not contribute to the quality of the discussions on this list :-)
 > 
 > --
 >         thanks
 > 
 >         --- tony
 > 
 > 
 > 
 > 
 > Network Working Group                                                 Tony Li
 > INTERNET DRAFT                                               Juniper Networks
 > 
 >                                                               Tony Przygienda
 >                                                                     Bell Labs
 > 
 >                                                                     Henk Smit
 >                                                                 Cisco Systems
 >                                                                    April 1999
 > 
 > 
 >          Domain-wide Prefix Distribution with Multi-Level IS-IS
 > 
 >                   <draft-ietf-isis-domain-wide-01.txt>
 > 
 > 
 > Status
 > 
 >    This document is an Internet-Draft and is in full conformance with
 >    all provisions of Section 10 of RFC2026.
 > 
 >    Internet-Drafts are working documents of the Internet Engineering
 >    Task Force (IETF), its areas, and its working groups.  Note that
 >    other groups may also distribute working documents as Internet-
 >    Drafts.
 > 
 >    Internet-Drafts are draft documents valid for a maximum of six months
 >    and may be updated, replaced, or obsoleted by other documents at any
 >    time.  It is inappropriate to use Internet- Drafts as reference
 >    material or to cite them other than as "work in progress."
 > 
 >    The list of current Internet-Drafts can be accessed at
 >    http://www.ietf.org/ietf/1id-abstracts.txt
 > 
 >    The list of Internet-Draft Shadow Directories can be accessed at
 >    http://www.ietf.org/shadow.html.
 > 
 > 
 > 1.0 Abstract
 > 
 >    This document describes extensions to the IS-IS protocol to support
 >    optimal routing within a multi-level domain.  The IS-IS protocol is
 >    specified in ISO 10589 [1], with extensions for supporting IPv4
 >    specified in RFC 1195 [2].
 > 
 >    This document extends the semantics presented in RFC 1195 so that a
 >    routing domain running with both Level 1 and Level 2 Intermediate
 >    Systems (IS) [routers] can distribute IP prefixes between Level 1 and
 >    Level 2 and vice versa.  This distribution requires certain
 >    restrictions to insure that persistent forwarding loops do not form.
 >    The goal of this domain-wide prefix distribution is to increase the
 >    granularity of the routing information within the domain.
 > 
 > 
 > 2.0 Introduction
 > 
 >    An IS-IS routing domain (a.k.a., an autonomous system running IS-IS)
 >    can be partitioned into multiple level 1 (L1) areas, and a level 2
 >    (L2) connected subset of the topology that interconnects all of the
 >    L1 areas.  Within each L1 area, all routers exchange link state
 >    information.  L2 routers also exchange L2 link state information to
 >    compute routes between areas.
 > 
 >    RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are
 >    used to transport IPv4 routing information in IS-IS.  RFC 1195 also
 >    specifies the semantics and procedures for interactions between
 >    levels.  Specifically, routers in a L1 area will exchange information
 >    within the L1 area.  For IP destinations not found in the prefixes in
 >    the L1 database, the L1 router should forward packets to the nearest
 >    router that is in both L1 and L2 (i.e., an L1L2 router) with the
 >    'attach' bit set in its L1 Link State Protocol Data Unit (LSP).
 > 
 >    Also per RFC 1195, an L1L2 router should be manually configured with
 >    a set of prefixes that summarize the IP prefixes found in that L1
 >    area.  These summaries are injected into L2.  RFC 1195 specifies no
 >    further interactions between L1 and L2 for IPv4 prefixes.
 > 
 > 
 > 2.1 Motivations for domain-wide prefix distribution
 > 
 >    The mechanisms specified in RFC 1195 are appropriate in many
 >    situations, and lead to excellent scalability properties.  However,
 >    in certain circumstances, the domain administrator may wish to
 >    sacrifice some amount of scalability and distribute more specific
 >    information than is described by RFC 1195.  This section discusses
 >    the various reasons why the domain administrator may wish to make
 >    such a tradeoff.
 > 
 >    One major reason for distributing more prefix information is to
 >    improve the quality of the resulting routes.  A well know property of
 >    prefix summarization or any abstraction mechanism is that it
 >    necessarily results in a loss of information.  This loss of
 >    information in turn results in the computation of a route based upon
 >    less information, which will frequently result in routes that are not
 >    optimal.
 > 
 >    A simple example can serve to demonstrate this adequately.  Suppose
 >    that a L1 area has two L1L2 routers that both advertise a single
 >    summary of all prefixes within the L1 area.  To reach a destination
 >    inside the L1 area, any other L2 router is going to compute the
 >    shortest path to one of the two L1L2 routers for that area.  Suppose,
 >    for example, that both of the L1L2 routers are equidistant from the
 >    L2 source, and that the L2 source arbitrarily selects one L1L2
 >    router.  This router may not be the optimal router when viewed from
 >    the L1 topology.  In fact, it may be the case that the path from the
 >    selected L1L2 router to the destination router may traverse the L1L2
 >    router that was not selected.  If more detailed topological
 >    information or more detailed metric information was available to the
 >    L2 source router, it could make a more optimal route computation.
 > 
 >    This situation is symmetric in that an L1 router has no information
 >    about prefixes in L2 or within a different L1 area.  In using the
 >    nearest L1L2 router, that L1L2 is effectively injecting a default
 >    route without metric information into the L1 area.  The route
 >    computation that the L1 router performs is similarly suboptimal.
 > 
 >    Besides the optimality of the routes computed, there two other
 >    significant drivers for the domain wide distribution of prefix
 >    information.
 > 
 >    When a router learns multiple possible paths to external destinations
 >    via BGP, it will select only one of those routes to be installed in
 >    the forwarding table.  One of the factors in the BGP route selection
 >    is the IGP cost to the BGP next hop address.  Many ISP networks
 >    depend on this technique, which is known as "shortest exit routing".
 >    If a L1 router does not know the exact IGP metric to all BGP speakers
 >    in other L1 areas, it cannot do effective shortest exit routing.
 > 
 >    The third driver is the current practice of using the IGP (IS-IS)
 >    metric as part of the BGP Multi-Exit Discriminator (MED).  The value
 >    in the MED is advertised to other domains and is used to inform other
 >    domains of the optimal entry point into the current domain.  Current
 >    practice is to take the IS-IS metric and insert it as the MED value.
 >    This tends to cause external traffic to enter the domain at the point
 >    closest to the exit router.  Note that the receiving domain may,
 >    based upon policy, choose to ignore the MED that is advertised.
 >    However, current practice is to distribute the IGP metric in this way
 >    in order to optimize routing wherever possible.  This is possible in
 >    current networks that only are a single area, but becomes problematic
 >    if hierarchy is to be installed into the network.  This is again
 >    because the loss of end-to-end metric information means that the MED
 >    value will not reflect the true distance across the advertising
 >    domain.  Full distribution of prefix information within the domain
 >    would alleviate this problem as it would allow accurate computation
 >    of the IS-IS metric across the domain, resulting in an accurate value
 >    presented in the MED.
 > 
 > 
 > 2.2 Scalability
 > 
 >    The disadvantage to performing the domain-wide prefix distribution
 >    described above is that it has an impact to the scalability of IS-IS.
 >    Areas within IS-IS help scalability in that LSPs are contained within
 >    a single area.  This limits the size of the link state database, that
 >    in turn limits the complexity of the shortest path computation.
 > 
 >    Further, the summarization of the prefix information aids scalability
 >    in that the abstraction of the prefix information removes the sheer
 >    number of data items to be transported and the number of routes to be
 >    computed.
 > 
 >    It should be noted quite strongly that the distribution of prefixes
 >    on a domain wide basis impacts the scalability of IS-IS in the second
 >    respect.  It will increase the number of prefixes throughout the
 >    domain.  This will result in increased memory consumption,
 >    transmission requirements and computation requirements throughout the
 >    domain.
 > 
 >    It must also be noted that the domain-wide distribution of prefixes
 >    has no effect whatsoever on the first aspect of scalability, namely
 >    the existence of areas and the limitation of the distribution of the
 >    link state database.
 > 
 >    Thus, the net result is that the introduction of domain-wide prefix
 >    distribution into a formerly flat, single area network is a clear
 >    benefit to the scalability of that network.  However, it is a
 >    compromise and does not provide the maximum scalability available
 >    with IS-IS.  Domains that choose to make use of this facility should
 >    be aware of the tradeoff that they are making between scalability and
 >    optimality and provision and monitor their networks accordingly.
 >    Normal provisioning guidelines that would apply to a fully
 >    hierarchical deployment of IS-IS will not apply to this type of
 >    configuration.
 > 
 > 
 > 3.0 New semantics for external type metrics
 > 
 >    RFC 1195 defines two TLVs for carrying IP prefixes.  TLV 128 is
 >    defined to carry 'internal' prefixes and TLV 130 is defined to carry
 >    'external' prefixes.  The original intent of RFC 1195 was to carry
 >    intra-domain routes within the internal prefix TLV and inter-domain
 >    routes or intra-domain routes from alternate IGPs in an external
 >    prefix TLV.  Interestingly, TLV type 130 is not documented to exist
 >    in Level 1 LSPs.
 > 
 >    In addition to this distinction, RFC 1195 provides for a bit in each
 >    of these TLVs that distinguishes between an internal metric type and
 >    an external metric type.  Similarly, the clear intent was that the
 >    internal metric type should reflect a total metric that is the sum of
 >    the metrics to the advertising router plus the metric to the prefix.
 >    Further, for an external metric type, the total metric should simply
 >    be the metric advertised to the prefix, not including the total
 >    metric necessary to reach the exit router.  Prefixes with internal
 >    metrics are always preferred over external metrics, regardless of the
 >    value of the metrics.
 > 
 >    It should be noted that the combination of an internal prefix with an
 >    external metric type is not obviously useful, and is not allowed by
 >    RFC 1195.
 > 
 >    It should also be noted that as of this writing, the author knows of
 >    no deployed implementations that make use of either the external
 >    prefix or the external metric type.  The implication is that this
 >    proposal is free to redefine the semantics of the external metric
 >    type bit without conflicting with existing protocol deployment.
 > 
 >    An essential property when redistributing prefixes between levels is
 >    to insure that no persistent loops form in the distribution of
 >    information (i.e., a routing loop), as this would lead to the
 >    indefinite propagation of the information, even in the event that the
 >    information was no longer originated by some system in the domain.
 >    Further, a routing loop is likely to form a forwarding loop, where
 >    actual traffic traverses the network in a cycle in the topology.
 >    Forwarding loops are known to consume large amounts of resources and
 >    are to be avoided.
 > 
 > 
 > 3.1 Proposed semantics for inter-area routes
 > 
 >    To provide the above properties, this proposal defines the following
 >    syntax and semantics. The encoding is being extended compared to
 >    RFC1195 and is almost symmetric.
 > 
 >    An intra-area route is a route computed based on a prefix advertised
 >    by some IS-IS router in the area.  Thus, a prefix advertised in the
 >    L1 link state database may become a L1 intra-area route within the
 >    area of the advertiser.  Similarly, a prefix advertised in the L2
 >    link state database may become a L2 intra-area route within L2.
 >    Prefixes associated with an intra-area route are also said to be
 >    intra-area prefixes. These types of prefixes are being encoded in the
 >    same way as in RFC1195 within TLV 128 using internal metric types.
 > 
 >    An inter-area route is a route computed based on a prefix advertised
 >    by an IS-IS router not in the local area.  Inter-area routes exist
 >    either in L2, in which case they are L1->L2 inter-area routes, or in
 >    L1, in which case they are L2->L1 inter-area routes.  Prefixes
 >    associated with an inter-area route area also said to be inter-area
 >    prefixes. Such prefixes are encoded within L1 within TLV 128 using
 >    external metric type which is an extension to RFC 1195. Within L2
 >    these prefixes are indistinguishable from L2 intra-area routes and
 >    are therefore encoded within TLV 128 with internal metrics.
 > 
 >    External prefixes are reserved for prefixes originating outside of
 >    the IS-IS system, usually learned from another routing protocol. To
 >    allow for leaking of routes originating outside the ISIS domain
 >    within L1, TLV 130 is allowed in L1 with both internal and external
 >    metric types.  Observe that introducing externals in L1 makes sense
 >    since those can be leaked into L2 and into other L1 areas.
 > 
 >    The following tables describe all types of prefixes now defined
 >    within IS-IS and how they are encoded:
 > 
 >          Level-1 LSPs       |  Internal TLV (128)  | External TLV (130)
 >      ----------------------------------------------------------------------
 >      Internal metric-type   |   L1 intra-area      |   external           |
 >      ----------------------------------------------------------------------
 >      External metric-type   |   L2->L1 inter-area  |   external           |
 >      ----------------------------------------------------------------------
 > 
 > 
 >          Level-2 LSPs       |  Internal TLV (128)  | External TLV (130)
 >      ----------------------------------------------------------------------
 >      Internal metric-type   |   L2 intra-area  or  |   external           |
 >                             |   L1->L2 inter-area  |                      |
 >      ----------------------------------------------------------------------
 >      External metric-type   |   should not exist   |   external           |
 >      ----------------------------------------------------------------------
 > 
 >    Based on these definitions and encodings, this proposal defines the
 >    following redistribution rules:
 > 
 >    1) Only L1 intra-area prefixes and external prefixes are
 >    redistributed from L1 into L2.
 > 
 >    2) All prefixes can be redistributed from L2 into L1 and become
 >    L2->L1 inter-area routes.  All prefixes can be redistributed from L2
 >    into L1 and become L2->L1 inter-area routes.  A L2 prefix must not be
 >    redistributed into a L1 area if that same prefix exists as L1 intra
 >    area route or L1 external route to prevent routing loops.
 > 
 >    3) Within L1, an intra-area prefix is preferred over an inter-area
 >    prefix, regardless of the comparison of the metrics.
 > 
 >    Based on these rules, we first observe that this proposal is free
 >    from routing loops.  No prefix can be redistributed from L2 to L1 and
 >    back into L2, because the route first becomes an L1 inter-area prefix
 >    by rule (2) and by rule (1) cannot be redistributed into L2.
 >    Similarly, a prefix redistributed from L1 to L2 becomes an L2 inter-
 >    area prefix by rule (1) but will not be redistributed into the
 >    original L1 area by rule (2).
 > 
 >    Even when following all the indicated rules, there is the possibility
 >    of a transient routing loop when the original prefix is withdrawn and
 >    the inter-area prefix is selected.  However, all link state protocols
 >    are subject to transient routing loops, so this is no worse than the
 >    status quo.
 > 
 >    Note that this proposal is not radically different than the current
 >    semantics for RFC 1195: internal metric types are always preferred
 >    over externals, so rule (3) is an extension that allows external
 >    metric types in internal prefix TLVs.  It does not introduce a new
 >    comparison between internal and external metric values. Expressed in
 >    a more abstract way by introducing a relationship denoted by '>' that
 >    stands for 'is preffered over', all the possible routes can be
 >    ordered unambiguosly, starting with intra-area L1 route and ending
 >    with external L2 route with external metric.  The routes in the
 >    following figures are denoted in the notation <level:tlv:value of I/E
 >    bit>.
 > 
 > 
 >        <-- more preffered ---
 > 
 >    L1:128:I>L2:128:I>L1:128:E>L1:130:I>L2:130:I>L1:130:E>L2:130:E
 > 
 >        --- less preffered -->
 > 
 > 
 >    Rule (2) asserts that a route cannot override an already present,
 >    more preffered route in a L1 area when being leaked into it.
 > 
 > 
 > 3.2 Transition issues
 > 
 >    Because no implementations currently make use of the external metric
 >    type, the deployment of prefixes with an external metric type is
 >    somewhat problematic.  There is the possibility that the new type of
 >    advertisement may result in software instability in systems that do
 >    not deal with even the original semantics correctly.  Further, there
 >    is a danger that haphazard deployment of systems supporting this
 >    proposal and legacy systems would have an unfortunate interaction.
 >    It is required, for any L1 area that should perform the mutual
 >    redistribution described in this proposal, that the L1L2 systems be
 >    updated first.  If these systems operate correctly, this is
 >    sufficient to ensure that there are no persistent routing loops. In
 >    case where not all L1L2 systems are being upgraded, persistent
 >    routing loops are possible. Consider the following figure that gives
 >    an example of such a looping scenario with a setup where (A) has been
 >    upgraded and (B) has not.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >             route through L2
 >             to 1/8 at cost 200
 >                  |
 >                  |     +-- L2 link cost 1 --+
 >                  |     |                    |
 >                  |    computes 1/8          |
 >                  |    at 64 through (B)     |
 >                 [1]    |                    |
 >                  V     V                    ^
 >               +--+--------+           +-----+-----+
 >               | new style |           | old style |
 >           (A) | L1/L2     |           | L1/L2     | (B)
 >               | leaks 1/8 |           | leaks up  |
 >               | at 63 Ext |           | at 63 Ext |
 >               +----+------+           +-------+---+
 >                    V                          ^
 >                    |                          |
 >                    |                    computes L1 route
 >                    |                    1/8 at cost 128
 >                    |                          |
 >                    +---- L1 link with cost 1 -+
 > 
 > 
 >    Originally a prefix 1/8 in L2 with a cost of 200 is being computed by
 >    upgraded L1L2 router (A) as best route towards 1/8 through interface
 >    1. The prefix leaks at maximum cost of 63 (and with the I/E bit being
 >    set) into L1 domain and is used by L1L2 router (B) (which has not
 >    been upgraded) to compute best route to 1/8 at cost 128 in L1. We
 >    assume that (B) is not masking the I/E bit out but is using it as
 >    part of the metric, however the scenario holds as well in case (B)
 >    believes the metric to be 63.  This L1 route will be obviously
 >    preferred by (B) to a computed L2 route. Assuming that (B) leaks 1/8
 >    into L2 domain again, (A) will use it for another L2 computation that
 >    ends up with a shorter L2 route to 1/8 through (B) and probably leaks
 >    it again into L1.  Hence, a routing and forwarding loop has been
 >    formed.
 > 
 >    As described in the previous section, rule (2) must be followed to
 >    prevent looping when this extension is deployed using L1 routers
 >    understanding the semantics of the L1 inter-area route mixed with L1
 >    routers that treat all routes within 128 TLV as intra-area. The
 >    following example visualizes a forwarding loop encountered in a
 >    scenario where (A) leaks an L1 inter-area route despite the fact that
 >    (D) advertises the same route as L1 intra-area.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >                            route through L2 to
 >                            1/8 at cost 200
 >                                 /
 >                                /
 >                               v
 >                         +============+
 >                         | L1/L2      |   routing table for 1/8
 >                         | leaking    |   (top is active route)
 >                     (A) | 1/8 down   |       L1            at 131 active
 >                         | with cost  |       L2            at 200
 >                         | of 63 as   |       L1 inter-area at 127
 >                         | inter-area |
 >                         +====+====+-=+
 >                              |     \
 >                              |      \
 >                              |       \ cost 1
 >                              |        \
 >                      cost 1  |       +-+--+ routing table
 >                              |   (C) | L1 |  inter-area L1 at 128 active
 >                              |       +---++  L1            at 130
 >                              |            \
 >                              |             \
 >                              |            path with
 >                              |            total cost
 >       routing table      +---+-+          of 130
 >        inter-area L1     | L1  | (B)           \
 >            at 128 active +---+-+                \
 >        L1  at 131            |                   \
 >                              |                    \
 >                              |                   +-+--+
 >                              +- path with -------+ L1 | advertises
 >                                 total cost       +----+ 1/8 as L1
 >                                 of 131             (D)  attached
 >                                                         prefix
 > 
 >    (A) is an upgraded L1L2 router and leaks into L1 a prefix 1/8 that it
 >    computed through L2 at the maximum cost of 127 (or expressed
 >    differently, as inter-area with cost 63) which violates rule (2).
 >    Router (B), (C), (D) are all purely RFC1195 compliant routers so they
 >    perceive the leaked prefix as internal L1. At the same time, (D)
 >    advertises the same prefix 1/8 as L1 directly attached subnet into
 >    L1. To distinguish the different copies, the leaked prefix is shown
 >    as inter-area L1.  (B) computes the inter-area L1 route at a cost of
 >    127+1 and prefers it to the one through (D) since such a router has a
 >    cost of 131 and (B) does not understand that L1 intra-area routes
 >    should be always preffered over L1 inter-area routes. Therefore (B)
 >    forwards a packet to 1/8 towards (A).  (A) cannot prefer the inter-
 >    area L1 route since it could not really forward using it but has to
 >    use L2 to get the packet into the L2 backbone.  However, it must
 >    prefer L1 computed to (D) over L2 route.  Hence, (A) forwards the
 >    packet towards (C). (C) has the L1 inter-area as preferred (since it
 >    looks to it like a cheaper L1 intra-area route to 1/8 than the L1
 >    route through (D)) and forwards the packet back to (A).
 > 
 >    Finally, it should be obvious that if a deployment uses L1 external
 >    routes in an area that still contains strictly RFC1195 compliant
 >    routers, forwarding loops can be easily formed. Routers that are able
 >    to interpret TLV 130 in L1 may try to forward towards the announcer
 >    of such external routes whereas RFC1195 compliant routers will always
 >    forward towards the closest, connected L2 capable router.
 > 
 > 
 > 4.0 Comparisons with other proposals
 > 
 >    Another proposal is currently being discussed which is similar to
 >    this one in nature.
 > 
 >    In [3], a new TLV is proposed to transport IP prefix information.
 >    Because this is a new TLV, it is somewhat harder to deploy, requiring
 >    that all systems understand the new TLV before it can become
 >    effective.  For this reason, this proposal provides an alternative
 >    that can be deployed sooner.  There is no effective semantic
 >    difference between the two proposals.  In [3], a bit is defined to
 >    mark a prefix as 'up' or 'down'.  This is essentially the same
 >    semantics as is proposed here.
 > 
 > 5.0 Security Considerations
 > 
 >    This document raises no new security issues for IS-IS.
 > 
 > 6.0 References
 > 
 >    [1] ISO 10589, "Intermediate System to Intermediate System Intra-
 >    Domain Routeing Exchange Protocol for use in Conjunction with the
 >    Protocol for Providing the Connectionless-mode Network Service (ISO
 >    8473)" [Also republished as RFC 1142]
 > 
 >    [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual
 >    environments", R.W. Callon, Dec. 1990
 > 
 >    [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering",
 >    draft-ietf-isis-traffic-00.txt, work in progress
 > 
 > 7.0 Authors' Addresses
 > 
 >    Tony Li
 >    Juniper Networks, Inc.
 >    385 Ravendale Dr.
 >    Mountain View, CA 94043
 >    Email: [email-masked]
 >    Fax: +1 650 526 8001
 >    Voice: +1 650 526 8006
 > 
 >    Tony Przygienda
 >    Bell Labs, Lucent Technologies
 >    101 Crawfords Corner Road
 >    Holmdel, NJ 07733-3030
 >    Email: [email-masked]
 > 
 >    Henk Smit
 >    Cisco Systems, Inc.
 >    210 West Tasman Drive
 >    San Jose, CA 95134
 >    Email: [email-masked]
 >    Voice: +31 20 342 3736
 > 
 > 
 > 
 > 
 >

---

From: Rajesh Saluja <[email-masked]>
Date: Wed, 06 Oct 1999 11:36:07 -0400

>      draft and this draft are orthogonal.

For my understanding, can you verify if the following sentences 
are correct for domain-wide draft:

1. It needs changes only in L1L2 router. There is no change in L1
router implementation from RFC1195.

2. External routes are allowed in L1 domain. Which means that L1
routers can advertise external reachability information.

3. The external routes can only have internal metric type. 

4. In the given proposal, we can not distinguish 
between L1 externals from L2->L1 externals ( both will be 130:L1:I ) 
between L2 externals from L1->L2 externals (both will be 130:L2:I).

If 3 is correct, then why does the preference suggested in proposal
talks about L1:130:I and L1:130:E and same for L2.

If 3 is not correct (i.e. external routes in L1 domain can still have
internal
and external metric types) then it means that L1 routers should have the
capability to prefer internal metric types to external metric types and
according to RFC1195, they do not have this capability ( 3.10.1 )

Thanks,
Rajesh

---

From: Rajesh Saluja <[email-masked]>
Date: Wed, 06 Oct 1999 16:15:03 -0400

Tony Przygienda wrote:

> L1 routers in 1195 don't have 130 TLVs. 130s are exclusively L2 in 1195. That's why you cannot mix L1 areas when updating!

Tony,
Thanks for your response. I just went through the draft that
you sent out on mailing list yesterday and it says that 
" If a deployment uses L1 external routes in an area that still
contains strictly RFC 1195 compliant routers, forwarding loops 
can easily be formed ".

This means that deployment of domain-wide draft needs changes in
the RFC1195 compliant routers. Only the L1 routers which understand
TLV 130 and accordingly understand internal/external routes and 
metric types need no upgrade. Is this correct?
Other than Cisco routers, are there other routers which support 
externals in L1?

This RFC1195 noncompliant behavior is not mentioned in any spec.
I thought that the one of the goals of this draft was not to
upgrade RFC 1195 compliant L1 routers which is not true anymore.

Thanks,
Rajesh