RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi Arthi

Please see inline

Regards,

JL

>> >As I explained in my email to JP, it is still somewhat=20
>unclear as to=20
>> >what the ability to signal the desired method buys the=20
>provider, and=20
>> >exactly why or how that simplifies LSP management.
>>
>> Basically, as mentionned by JP, the signaling method used=20
>will have a=20
>> non negligeable impact on important features (Reoptimization, FRR,=20
>> rerouting). For instance, if you use sitching or nesting, you will=20
>> face FRR issues as regards ABR protection.
>----------> Let me try to explain this, if possible with a couple of
>examples:
>Re-optimization
>---------------
>Actually, nothing prevents you from having Head-end Control of=20
>re-optimzation even with the non-contiguous signaling methods.=20
>It is just that with the non-contiguous signaling methods, one=20
>can, if desired, also have the ability to do a local=20
>re-optimization. But if you do not want this 'intermediate=20
>re-optimization' behavior for certain LSPs, you may want to=20
>signal that explicitly or configure it on the box.

Agree

>
>Crankback/Re-routing
>---------------------
>The crankback document actually provides a similar ability for=20
>controlling re-routing at intermediate nodes by signaling this=20
>explicitly.

Agree,

And what about FRR: if I want FRR protection of ABRs with no impact on
backup length and recovery delay, I definitely need contiguous LSPs.
This is actually the only signaling mode allowing this service. Thus I
prefer to signal directly the signaling mode "Contiguous LSP", rather
than the required service, in order to avoid any misinterpretation of
this service ...