[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:23:06 -0800
Curtis Villamizar wrote:
In message <[email protected]>
Naiming Shen writes:


We need to arrive at a method that is simpler and easier to use than RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get from an advanced IPFRR method is that it "isn't MPLS", and that's not sufficient IMHO.

It does not have to be "MPLS" if you consider the IP TE mechanism though

- Naiming

True.  But the IP TE is so similar to MPLS TE that the objection to
MPLS TE (which I personally think is FUD) involves the effort to
manage it.  If you configure MPLS TE for zero bandwidth then the main
difference is the forwarding.  An autoconfig for MPLS TE to set up a
tunnel to all IGP nodes (for example) would eliminate any management
overhead.  If IP FRR were considering such solutions, then that would
seem to me to make more sense than IP TE (why reinvent the wheel).

As I mentioned in the previous email, IP TE is really for the backbone
IP tunnels. And IP TE not only handles the IPFRR, it does the
IP multicast FRR also, and optionally it can handle LDP and RSVP related
MPLS LSPs, since I don't imagine anyone would say they only want
pure MPLS solution FRR, no IP solution can be tolerated ;-)

On the other hand I will be happy to see a simpler solution
even if it can not do IP multicast FRR.

- Naiming


Rtgwg mailing list
[email protected]

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