[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: Wed, 25 May 2005 13:30:25 -0700
Hi Alia,

Alia Atlas said the following on 05/17/2005 01:12 PM:
Hi Naiming,

At 01:58 PM 5/16/2005, Naiming Shen wrote:

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.

I'll be interested to read those.

Just announced at:
please take a look and let me know if the new section makes sense.

I forgot to reference the notvia-addr draft in it, will do in next version.
the rest of the comments seem to be LDP protocol specific, i think we could
do in MPLS group. Sorry about the late response from me.

- Naiming

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

The timing issues need to be understood & the ramifications considered. I disagree that all of these are implementation details - some of them have definite inter-operability impact.
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.

There is an inter-operability component here. Generally, a router can reuse a label once it has received label releases from all its upstream neighbors. If you claim that it is an implementation issue - does that mean the above assumption doesn't hold, may hold, or may sometimes hold?
It's a question of when a label can be re-used.

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.

This is somewhat different. With RSVP-TE FRR, the downstream label is also learned/confirmed via the backup signaling - indicating that the label is still valid.
I do not think that these are specifically blockers - but I do think
that they are some of the issues that need to be considered/discussed.
It's very easy to just pass up the extra label info, without thinking
through all of the ramifications.
Other aspects are - oh, the case where multiple neighbors N1 and N2 both
have a common neighbor R. What happens if the neighbors N1 and N2
report different labels for R?
If there is a need to use tunnels for backup and there are sufficiently
many that doing targeted LDP sessions is really not desirable, then this
draft might be useful - but I'm not fully convinced (on several of those

- 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>