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

From: Tony Li <[email-masked]>
Date: Tue, 5 Oct 1999 01:10:20 -0700

Next order of business:

There's been a request that the WG consider "IS-IS extensions for Traffic
Engineering" for publication as an Informational RFC.  

We would like to start a WG last call on this document.  Please comment by
Friday, Oct. 15, 1999, 12:01 Pacific Time.

Thanks,
Tony & Tony

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

---

From: Rajesh Saluja <[email-masked]>
Date: Tue, 05 Oct 1999 10:27:56 -0400

> Friday, Oct. 15, 1999, 12:01 Pacific Time.

I have few comments on the traffic engineering draft.

1. There is no support of I/E bit in the draft and 
Henk agrees that there may be some implementations which 
support I/E bit and it should be taken care.

2. The draft currently does not give a replacement for 
external IP reachability though it has extended IP reachability
TLV as a replacement of internal IP reachability. It will be 
nice if there is extended internal IP reachability TLV and
extended external IP reachability TLV.

3. Instead of having two solutions (traffic engineering
and domain wide) for route redistribution from L2 to L1,
won't it be nice to agree on a common solution? The traffic
engineering draft definitely does not address all types of
routes and preference order (as pointed out in earlier mails).
Probably using I/E bit in place of Up/Down bit and then using
domain-wide draft proposal, it is possible to reach a common
solution.

4. I find interoperability and implementation a big problem 
with this draft.If I understand correctly, a router 
supporting traffic engineering draft will calculate even 
the conventional routes using the new extended TLVs and new 
extended metric. Also the routers in the whole domain need
to be changed for consistent behavior. IMHO it will be 
really wise to add a section on "Transition issues" in this
draft.

5. It seems that the traffic engineering draft is trying to 
focus on lots of problems at the sametime namely extended metric,
route redistribution and traffic engineering. IMHO it can be cleaner
if it focusses only on traffic engineering extensions while working
peacefully with existing implementations.

Thanks,
Rajesh

---

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

Hi Rajesh,

> support I/E bit and it should be taken care.

  Nope, I didn't agree that we should have an I/E bit in the traffic
 engineering draft. Personally I don't like the idea of external metrics.
 An indication is that no customers use external metrics in their current
 designs.
  Either you add metrics, like you do with  internal metrics, or you give
 redistributed routes a metric of 0.
  Depending on fancy redistribution features points to bad network
 design anyway (IMHO).

  I do agree that if we are doing draft-ietf-isis-domain-wide-01.txt,
 then maybe we should use the reserved bit 8, in stead of the I/E
 bit 7, as the up/down bit. This would allow us to leak L2->L1 into
 both TLV128 and TLV130. If we (vendors and customers) decide this
 is worthwile to do, we got to hurry, because some customers are
 testing this currently for deployment in the near future.

  For draft-ietf-isis-traffic-01.txt, I don't want to add an I/E bit.
 There are no free bits available.
 I don't like to put a generic I/E bit in all metrics, like 10589 does,
 because it makes no sense to have an external metric on a link.

> extended external IP reachability TLV.

  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.

> domain-wide draft proposal, it is possible to reach a common

  Both drafts are trying to solve two different problems.
 If you want to solve existing (or new) problems in the TE draft,
 that is fine with me. Personally I prefer to have one type of
 IP prefix. The up/down bit is needed for route-leaking. It is
 enough to solve that problem. All other route preference stuff
 is IMHO overkill.
  I would hate to see ISIS get the same complexity as OSPF has.
 I already saw someone suggesting introducing sub-TLVs for ASBRs.
 Wonder when someone wants to introduce forwarding addresses. ;-)

  But the draft-ietf-isis-domain-wide-01.txt was done to solve
 one and only one problem. Some customer(s) wants to leak L2
 prefixes into L1, using the old-style TLVs. The reason is that
 they can not or do not want to upgrade SW or HW. By doing a small
 trick in draft-ietf-isis-domain-wide-01.txt on only the L1L2
 routers, we can do that. But we should not redefine other stuff.
 The goal is to keep L1-only routers behave the same way as they
 do today.
  Also please note that route-leaking into TLV128 or TLV130 is not
 optimal anyway, because the advertised path metric can be 63 at most.
 This solution is only useful if you have a relatively flat network
 where the diameter of a L1 area plus the diameter of your L2 backbone
 is below 63. I expect to see little deployment of
 draft-ietf-isis-domain-wide-01.txt. I will recommend my customers to
 go to the new TLVs if they want route-leaking.

  If you want to fix problems in rfc1195, we should do it with
 the new TLVs 22 and 135. The new TLVs are a framework that adds
 the possibility to add new stuff in the future via sub-TLVs.
 IMHO route-tagging and redistribution of externals is a seperate
 issue which can be solved in a seperate drafts.
 draft-ietf-isis-traffic-01.txt is intended as the frame-work.
 It was not my choice to add the TE specific stuff to this drafts,
 but because the TE requirements are the thing that pushed
 draft-ietf-isis-traffic-01.txt into existence, it makes sense
 to combine the basic framework of the new TLVs plus the TE
 specific sub-TLVs.

> peacefully with existing implementations.

  I don't understand your point.
 Existing implementations do not support the new TLVs that have
 the capability of sub-TLVs.
 Do you want to split draft-ietf-isis-traffic-01.txt into three
 parts, one with for the new TLVs 22 and 135, and another draft
 about the TE specific sub-TLVs and TLV 134 ? And a third draft
 about route-leaking ? See my point above.

      Henk.

---

From: Rajesh Saluja <[email-masked]>
Date: Tue, 05 Oct 1999 14:05:22 -0400

>  were redistributed from outside into ISIS.

Yes, it can be done via sub-TLVs also but using explicit TLV for
external routes (as in RFC 1195) is probably cleaner. 

>  enough to solve that problem. All other route preference stuff

Is up/down bit enough for route selection? Probably not.
It is enough for avoiding routing loops. But just relying on
up/down bit can result in choosing external route over interarea route.
It is probably necessary to define the preferences and also necessary
to identify the external routes as a part of this draft.

>  about route-leaking ? See my point above.

Any implementation supporting new TLVs will calculate the routes
based on only new TLVs with extended metric which means that
the a router supporting new TLV will not be able to coexist with
a router supporting old TLV. It means that traffic engineering
draft needs all routers to change at a time. Isn't it? or is there
any nice transition plan? 

Thank you very much for your answers.

-Rajesh

---

From: Quaizar Vohra <[email-masked]>
Date: Tue, 5 Oct 1999 11:54:21 -0700 (PDT)

>  testing this currently for deployment in the near future.

You have my vote on using the 8th bit. We have customers who will
be leaking external routes and want the capabiltity to tell external
routes from internal. Using bit 8 leaves everything clean. We dont
want customers coming to us and asking us to support something we
cant because of restictions in the domain-wide draft.

 >  enough to solve that problem. All other route preference stuff

Unfortunately, I see requirements for distinguishing external routes
from internal. Hence a lots of different types of routes and a
complicated set of preferences. But I agree that the issue
of preserving the external semantics can be addressed in a seperate
draft.

 >  Wonder when someone wants to introduce forwarding addresses. ;-)

I was the one who mentioned this in my previous mail. In no way did
I suggest that this should or must be done. I had just mentioned that
this can be done if needed. Currently I dont see a need and the fact
that TE draft allows for extensibilty is enough for me.

 > > really wise to add a section on "Transition issues" in this

I think that it would be clean to exlude up/down bit from the TE draft
and address the whole issue of route leaking in another draft.
We have customers who are going to run TE extensions with domain-wide
extensions and rfc1195. I think the transition and interoperabilty
issues are fairly obvious but might be worth mentioning and best
specified in a seperate draft.