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

[Alia Atlas <[e-mail]>]

Hi Naiming,

At 01:58 PM 5/16/2005, Naiming Shen wrote:
>Alia Atlas said the following on 05/16/2005 10:21 AM:
>>Naiming,
>>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.

>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 
fronts).

Alia

>thanks.
>- Naiming
>
>>Alia
>>At 11:55 AM 5/16/2005, Naiming Shen wrote:
>>
>>>Loa,
>>>
>>>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,
>>>
>>>draft-shen-nhop-fastreroute-00.txt
>>>draft-shen-mpls-ldp-nnhop-label-00.txt
>>>
>>>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.
>>>
>>>thanks.
>>>- Naiming
>>>
>>>Loa Andersson said the following on 05/16/2005 04:03 AM:
>>>
>>>>Naiming,
>>>>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.
>>>>/Loa
>>>>Naiming Shen wrote:
>>>>
>>>>>Loa,
>>>>>
>>>>>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.
>>>>>
>>>>>thanks.
>>>>>- Naiming
>>>>>
>>>>>Loa Andersson said the following on 05/02/2005 12:55 AM:
>>>>>
>>>>>>Mike,
>>>>>>
>>>>>>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.
>>>>>>
>>>>>>/Loa
>>>>>>
>>>>>>>
>>>>>>>>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
>>>>>>[e-mail]
>>>>>>https://www1.ietf.org/mailman/listinfo/rtgwg
>>>>>
>>>>>
>>>
>>>_______________________________________________
>>>Rtgwg mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/rtgwg



_______________________________________________
Rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg