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

[Quaizar Vohra]

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

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.

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

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.

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

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.

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

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.


 > >
 > > 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.
 > 
 >   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.
 > 
 > _______________________________________________
 > Isis-wg mailing list  -  Isis-wg@external.juniper.net
 > http://external.juniper.net/mailman/listinfo/isis-wg