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

[Naiming Shen <[e-mail]>]

Hi Alia,

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.

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.

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