What concerns me here is that this is a solution without
I think the needs start emerging, any important services
riding on top of IP/MPLS transport infrastructure needs
fast convergence services. It's not reasonable to assume
only RSVP-TE LSPs need fast reroute, and other
network transport does not. This nnhop-ldp draft is to
facilitate the LDP based MPLS network for FRR with
node protection. I have been talking to some providers
in the past year, there are certainly interests in
I think the interest that we are seeing in IPFRR for LDP
networks demonstrates the usefulness of this work. Sure
RSVP-TE FRR exists, but some customers have expressed
an interest in a solution that does not use RSVP.
That is not to say that we don't have potential applications,
e.g. the pwe3 multihop pw's or the not via frr. Neither of those
schemes have yet been adopted as working group documents.
It is even doubtful if the mh pw's are within charter.
If there is a need to add nnhop label retrievement for
LDP, that should be brought to the MPLS working group by the
working group or party that have that need as a requirement.
I plan to submit the new version and open the discussion in
MPLS working group soon. Thanks for the support.
In the mean time the answer is if you need to do FFR in MPLS
enabled IP networks you should use RSVP-TE.
The current FRR in MPLS ONLY allows the protection for RSVP-TE.
and as far as I know of, most of the MPLS enabled network today
is LDP based, they certainly need fast convergence/reroute too.
And this draft is one solution to facilitate that.
Strictly this draft facilitates the nnhop labels needed for the
LDP variant of the IPFRR work that is going on in the rdgwg, rather
than being a solution in its own right. It is however a useful
starting point in addressing the nnh label problem, and should
continue to be investigated.
Rtgwg mailing list