Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt)

>> What concerns me here is that this is a solution without
>> clear requirements.
> 
> 
> 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
> this service.
> 

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.

- Stewart

> 

_______________________________________________
Rtgwg mailing list
Rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg