In message <[email protected]>
Naiming Shen writes:
> Hi Alia,
> Alia Atlas wrote:
> > Hi Naiming,
> > At 02:47 PM 11/22/2004, Naiming Shen wrote:
> >>> Sure. We can have a different protocol in the network solely for
> >>> resiliency to create those source-routed tunnels with the associated
> >>> complexity, but at least it wouldn't be MPLS :-)
> >> Well, the main purpose is to enable backbone IP tunnels with the
> >> capability of TE, IPFRR is just a side effect of that :-)
> > Coming full circle, I suppose. :-)
> The reason it seems comming to a full circle is that, I keep waiting for
> a simpler solution, and yet to see one ;-)
I think this work exists due to anti-MPLS sentiment and a need for
FRR. The alternative (IP FRR) may be proving to be problematic and
the argument that there is something hard about doing MPLS FRR seems
to be losing credibility )or maybe just more so when FRR is added to
the list of requirements).
> > If a network is already doing TE and is willing to do the configuration,
> > etc., then it makes sense to use TE Fast-Reroute. Whether the
> > forwarding path is MPLS or IP seems irrelevant to me in that piece of
> > the discussion.
> I thought that was relevant in this IPFRR discussion, otherwise there is
> no way the NFRR solution should be outside this discussion. In terms of
> configuration "complication", it's all relative thing. People need to
> do comparison for their network in order to reach some conclusion.
> Also, the NFRR or MPLS TE configuration is mostly implementation issue,
> majority of that can be automated just like the IPFRR approaches
> discussed in this working group.
> - Naiming
Yep. Agree completely. The requirement *not* to use MPLS may not be
based on any technical issue.
Anyway we may be either out of scope or committing herasy as far as
this WG is concerned.
Rtgwg mailing list