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