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

[Henk Smit]

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