In message <[email protected]>
Naiming Shen writes:
> 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
You definitely have an advantage in providing FRR for IP multicast. I
question whether that is a requirement for anyone. FRR seems to be
popular among those doing VOIP which is unicase, and VPNs. The VPNs
are typically LDP. Often the VOIP resides within an LDP VPN. There
is existance proof that you can run VOIP over LDP over MPLS/TE quite
nicely and use MPLS FRR.
So far there hasn't been a lot of interest in multicast over MPLS
because those providers doing MPLS are not seeing a lot of multicast
traffic (and some don't offer native multicast) so they are fine with
offering multicast over IP with no TE or FRR.
Rtgwg mailing list