[email protected]
[Top] [All Lists]

Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-no

Subject: Re: the shen-mpls-nnhop Was:Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt
From: Naiming Shen
Date: Tue, 17 May 2005 10:21:29 -0700
Hi Loa,

Loa Andersson said the following on 05/17/2005 04:07 AM:
I checked this (thanks for the pointer) I actually forgotten
that the IPR discussion was realted to this document.

The -01 version has also dated so I guess it would be a good
idea to post version -02.

Will do soon.

What I see happening in the April -04 discussion is that the
issues from Seoul was not at all discussed (much less solved).
And further issues added (mostly the IPR, which now seems to
be solved).

I also saw very little support for the draft as such.

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.

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.

- Naiming


Even though it is
not fuly clear that

Naiming Shen wrote:


Check out the MPLS mailing list archive April 2004 with
subject of "discussion on nexthop fast-reroute drafts".
I posted the mail first on the list asking for two drafts,


to be adopted as the working group document in mpls-wg.
there were some syntax comments and some IPR dicussions
followed. the IPR issue should be fixed and we also
posted version-1 drafts after that. I can post the
new versions and start the discussion again.

- Naiming

Loa Andersson said the following on 05/16/2005 04:03 AM:


could you give me the pointer to "the last time" you are
refereing to. I find "the latest" in the reference to this
from the Seoul meeting. There were two question posed, do
we want to take LDP there and will it actually achieve
what the authors claim. Both questions were left for
further discussion on the MPLS mailing list. As far as
I remember this discussion has not taken place.


Naiming Shen wrote:


Last time the issue was with the wording of IPR statement in the
previous version of NNHOP LDP draft, we plan to refresh the
document in the mpls wg soon.

- Naiming

Loa Andersson said the following on 05/02/2005 12:55 AM:


actually the Naimings draft did not go anywhere when discussed in the
MPLS wg, this change to LDP would have to be taken up in the mpls again.

2. Explicit tunnels are needed, which means that targeted LDP sessions are necessary to have this support LDP traffic.

Yes. In the case of node protection we could also using Naiming's scheme of next-next hop LDP advertisement.

Rtgwg mailing list
[email protected]

Rtgwg mailing list
[email protected]

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