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

[Naiming Shen <[e-mail]>]

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

Just announced at:
http://www.ietf.org/internet-drafts/draft-shen-mpls-ldp-nnhop-label-02.txt,
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.

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