Alia Atlas wrote:
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 ;-)
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
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.
I do think that the complexity of the mechanism we select for an
advanced IPFRR method has to be bounded by a consideration of what
other potential solutions exist.
If a mechanism is more complicated to understand, manage, and
configure than RSVP-TE, then I think we need to seriously consider
where the benefit is.
I agree with finding the simpler solution approach, but I disagree that
the RSVP-TE or NFRR to be "complicated" solution though...
Since that's what I started with and a requirement for something simpler
for those not interested in TE, I do think of it as the upper bound on
the acceptable complexity. Whether that makes it "complicated" is a
matter of opinion.
Rtgwg mailing list