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

[Rajesh Saluja]

Henk Smit wrote:
> 
> > 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.

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

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

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.


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


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