[email protected]
[Top] [All Lists]

Re: questions on draft-bryant-ipfrr-tunnels-01.txt

Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Naiming Shen
Date: Mon, 22 Nov 2004 14:33:09 -0800
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 ;-)

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.

Cheers,
- Naiming

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




_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>