Subject: RE: [Isis-wg] Lack of I/E bit in TLV 135

From: "Don Goodspeed" <[email-masked]>
Date: Fri, 9 May 2003 14:31:57 -0400 (EDT)

Ruth,

Presumably, the router injecting the external routes into ISIS
would either add to the metric to "poison" them, or one could
possibly use the newer admin tags to "color" them.

Of course, someone else might have a better suggestion...

-don

 --- On Fri 05/09, Ruth Civil < [email-masked] > wrote:
From: Ruth Civil [mailto: [email-masked]]
To: [email-masked]
Date: Fri, 09 May 2003 09:09:59 -0400
Subject: [Isis-wg] Lack of I/E bit in TLV 135

There was a quick exchange on this mailing list a couple of days ago<br>where someone asked about the lack of an I/E bit in the Extended IP<br>Reachability TLV (type 135). <br><br>The response was that it wasn't included because it was more or less<br>useless.  <br><br>What happens if an ISIS router using wide metrics needs to distinguish<br>between internal and external routes in order to apply different route<br>preferences to internal vs external routes ?<br><br>I believe there are some routers (most notably Juniper) which offer the<br>ability to configure both a preference (for internal routes) and an<br>external-preference (for external routes). What method could such<br>routers be using to distinguish between internal and external routes in<br>order to apply those different preferences (when wide metrics are being<br>used) ?  <br><br><br>- Ruth<br><br>-- <br>Ruth Civil<br>Routing development<br>ESN 6 395 1142<br>[email-masked]<br>________________________________
 _______________<br>Isis-wg mailing list<br>[email-masked]<br>https://www1.ietf.org/mailman/listinfo/isis-wg<br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Ruth Civil" <[email-masked]>
Date: Fri, 09 May 2003 15:34:05 -0400

> possibly use the newer admin tags to "color" them.

I understand the admin tags suggestion, but I'm not sure the "poisoning"
suggestion actually resolves the situation I had in mind. 

I was referring to the situation where ISIS has only one route (and that
route happens to be an external route) to a destination X, but it has no
means by which to know the route is external (due to the lack of an I/E
bit in TLV 135).  The network operator may wish to prefer an ISIS
Internal route to an OSPF one, but prefer the OSPF one to an External
ISIS route;  but if you cannot distinguish between the internal and
external ISIS routes then you can't do this.

If I'm correctly interpreting what you mean by "poisoning" here then
this would certainly cause ISIS itself to chose an internal route to
destination X if it had one. However, assuming ISIS didn't have an
internal route to X, "poisoning" still wouldn't provide the ability to
identify the chosen route to X as an External ISIS route when it was
submitted to the routing table. Alternatively, you may be proposing that
we make the assumption that ISIS routes with metrics larger than a
certain predetermined value are always external ones, and report them as
such when submitting them to the routing table, but this sounds a bit
iffy to me.

I guess what I'm hearing from the replies I've been getting here is that
the authors of RFC 2966 believed that the ability to enforce an order of
preference such as:  
Internal ISIS > Other Protocol > External ISIS 
was either unnecessary or unimportant.

This designer may not necessarily think it's particularly important
either, but may still be forced to investigate the viability of
implementing such a scheme ...

- Ruth

> There was a quick exchange on this mailing list a couple of days ago<br>where someone asked about the lack of an I/E bit in the Extended IP<br>Reachability TLV (type 135). <br><br>The response was that it wasn't included because it was more or less<br>useless.  <br><br>What happens if an ISIS router using wide metrics needs to distinguish<br>between internal and external routes in order to apply different route<br>preferences to internal vs external routes ?<br><br>I believe there are some routers (most notably Juniper) which offer the<br>ability to configure both a preference (for internal routes) and an<br>external-preference (for external routes). What method could such<br>routers be using to distinguish between internal and external routes in<br>order to apply those different preferences (when wide metrics are being<br>used) ?

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 10 May 2003 01:06:35 +0200

On Fri, May 09, 2003 at 03:34:05PM -0400, Ruth Civil wrote:
| Don Goodspeed wrote:
| > 
| > 
| > Presumably, the router injecting the external routes into ISIS
| > would either add to the metric to "poison" them, or one could
| > possibly use the newer admin tags to "color" them.
| 
| I understand the admin tags suggestion, but I'm not sure the "poisoning"
| suggestion actually resolves the situation I had in mind. 
| 
| I was referring to the situation where ISIS has only one route (and that
| route happens to be an external route) to a destination X, but it has no
| means by which to know the route is external (due to the lack of an I/E
| bit in TLV 135).  The network operator may wish to prefer an ISIS
| Internal route to an OSPF one, but prefer the OSPF one to an External
| ISIS route;  but if you cannot distinguish between the internal and
| external ISIS routes then you can't do this.

correct ... but i guess they main question is how IS-IS is really used today ?
the common way is to use it as some kind of topological discovery tool and
mostly it does just carry loopback and link adresses;

typically no customer reachability information is contained as there
are protocols that can deal much better with bulk routes;

if i just want to use it as a topo discovery tool and for bringing up the iBGP
mesh then the whole I/E information is not used at all as all loopbacks
are internal anyway;
 
| If I'm correctly interpreting what you mean by "poisoning" here then
| this would certainly cause ISIS itself to chose an internal route to
| destination X if it had one. However, assuming ISIS didn't have an
| internal route to X, "poisoning" still wouldn't provide the ability to
| identify the chosen route to X as an External ISIS route when it was
| submitted to the routing table. Alternatively, you may be proposing that
| we make the assumption that ISIS routes with metrics larger than a
| certain predetermined value are always external ones, and report them as
| such when submitting them to the routing table, but this sounds a bit
| iffy to me.

/hannes