[email protected]
[Top] [All Lists]

Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt

Subject: Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt
From: Naiming Shen
Date: Mon, 16 May 2005 10:58:01 -0700
Hi Alia,

Alia Atlas said the following on 05/16/2005 10:21 AM:

One concern is what precisely is gained by this extension. It seems to be removing the overhead of the additional LDP sessions & adding in the assumption that the LDP labels are allocated per-platform.
Correct. Also I added one section on why we use this approach vs.
use targeted ldp session in the new version, there is more benefits
than you mentioned above.

The below concerns are timing issues and implementation details. But any
pre-setup scheme always have timing issues.

There are also timing issues - such as what is the delay in obtaining
the new information & the effect of using the old. For instance, does a
neighbor N, on receiving a label withdraw from its neighbor R, send an
immediate label release or wait until all routers that N has forwarded
R's label to have released it?
The implementation and configuration deal with those timing issues.
A router can be configured to send immediately, or wait for a fixed
time, or applying some backoff throttling scheme, etc. this is not
much different from any other routing/label updates.

Another is what does S do when it detects that the LDP session to N is
down? Say there is a single link from S to N which has an untargeted
LDP session on it. When the link fails, if it's POS, MPLSCP will also
go down - triggering the session to be torn down. At the same time,
traffic may be forwarded, using labels learned from N, to N's neighbor
R. When/how are those labels invalidated?
It's also a local policy and configuration issue. One can keep using this
until the new route/ldp converge, one can sets up a max time to use the
rerouted tunnel, etc. This is not much different from the RSVP based
MPLS FRR, your neighbor is down, you learned the next-nexthop lable from
this neighbor for FRR(actually the reason you use this label is because
this neighbor is down), and how to invalidate those labels.

- Naiming


At 11:55 AM 5/16/2005, 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]
Rtgwg mailing list
[email protected]

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