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

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>]

Hi Arthi

Please see inline

Regards,

JL

>> >As I explained in my email to JP, it is still somewhat 
>unclear as to 
>> >what the ability to signal the desired method buys the 
>provider, and 
>> >exactly why or how that simplifies LSP management.
>>
>> Basically, as mentionned by JP, the signaling method used 
>will have a 
>> non negligeable impact on important features (Reoptimization, FRR, 
>> rerouting). For instance, if you use sitching or nesting, you will 
>> 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 
>re-optimzation even with the non-contiguous signaling methods. 
>It is just that with the non-contiguous signaling methods, one 
>can, if desired, also have the ability to do a local 
>re-optimization. But if you do not want this 'intermediate 
>re-optimization' behavior for certain LSPs, you may want to 
>signal that explicitly or configure it on the box.

Agree

>
>Crankback/Re-routing
>---------------------
>The crankback document actually provides a similar ability for 
>controlling re-routing at intermediate nodes by signaling this 
>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 ...