[Isis-wg] draft-ietf-isis-traffic-01.txt

[Tony Przygienda]

"Christian E. Hopps" wrote:
> 
> Henk Smit <hsmit@cisco.com> writes:
> >   If you want to mark an IP prefix as external, we can do it via sub-TLVs.
> >  My collegues Naiming Shen has been working on tagging/coloring IP
> >  prefixes. Similar to OSPF tags or BGP communities. Maybe we can
> >  introduce some "well known" tags, to indicate that some prefixes
> >  were redistributed from outside into ISIS.
> 
> What about support of incomparable metrics (i.e, ospf's type 2 metric).
> The idea being you import the metric form the other protocol into the
> `external' metric and it takes precedence over the IGP metric (which is
> used to break ties).
> 
> You can add this as a new sub-TLV in another draft; however, then you
> run into transition issues.  Routing loops are easy to come by if you
> give the external metric precendence in the SPF and then some router
> ignores that sub-tlv.  By defining this in the main draft you at least
> eliminate trying to transition twice.
> 
> Since I don't have a lot of operational experience I'd like to ask: is
> an incomparable external metric perceived as a gratuitous addition?  I
> was under the impression that it was used just about anytime you wanted
> to import an EGP (or some aggregates of the EGP) into the IGP.

Christian, I thought that adding an external metric into 
135 would be a good thing to do since it's such a well-known "color"
to borrow Henk's view of the world.
However, from the customers of the protocol (those I checked with) 
I didn't hear any violent
uproar telling me that they couldn't live without so my interpretation
was taht we can let it pass that way and spend energy otherwise. Actually,
thinking deeper, it was just telling me that nobody re-distributes today
from/into ISIS heavily and doesn't intend to ;-) but as soon as they 
do the issue may arise.

If you really want an external
metric that is worse than any internal metric and interoperate with other
people without agreeing on coloring your implementation could
set the highest bit in the long-metric field considering 

If an IP prefix is advertised with a metric larger then
   MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be
   considered during the normal SPF computation. This will allow
   advertisment of an IP prefix for other purposes than building the
   normal IP routing table.


anything with 0x1000000 and above would be external. You'd just assume nobody
ever comes with an internal metric > 0x1000000. 

I know it's a hack and I wouldn't recommend it and 
 as I said I'd rather see the external bit with the
appropriate preference in SPF being spelled out but I leave it to the 
customers to push that one if it's necessary. 

		thanks 

		-- tony