Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

[Shraddha Hegde <[e-mail]>]

Acee,

I am not sure if I am able to convey what I mean by the "controller use case" in the previous mail thread. Here is another attempt to explain the use case.

With metric change there is no guarantee that LSP will move to a different path. If the current path satisfies all constraints of the LSP and there is no better path
Satisfying the constraints then the LSP would remain up and very much on the link that is going to be replaced. I mentioned in another mail thread, the high metric is 
Usable metric and does not mean "link down".

Link maintenance is a special scenario. The LSP MUST move out of the link. Controller can take special actions if it knows the link is in overload state
For Ex: Relax certain constraints of the LSP for the duration of maintenance and move the LSP on a different path.
All these activities should happen in a non- disruptive fashion for the service and that’s the reason the link metric cannot be changed to max-metric (0xffffffff)

If the "link overload" information remains at the link level, controller needs to take action based on metric alone.
It might work for most cases assuming there are better alternate paths satisfying same constraints but we cannot guarantee
LSPs will move from the link in all cases. If we consider a case when multiple links in the network go for maintenance/replacement simultaneously
then there is higher probability that alternate paths satisfying the constraints can't be found and controller needs to perform special actions to
move the LSPs around.

IMHO, "link overload" is a characteristic of the link just like color, bandwidth etc and it makes sense to flood it area wide just like other attributes of the link.

Rgds
Shraddha

-----Original Message-----
From: Pushpasis Sarkar 
Sent: Tuesday, September 29, 2015 8:27 PM
To: Acee Lindem (acee) <[e-mail]>
Cc: Shraddha Hegde <[e-mail]>; OSPF WG List <[e-mail]>; Hannes Gredler <[e-mail]>; Mohan Nanduri <[e-mail]>; Jalil, Luay <[e-mail]>
Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi Acee,




On 9/29/15, 8:15 PM, "Acee Lindem (acee)" <[e-mail]> wrote:


>I apologize if I offended you. I just wanted to avoid the circular discussions and repetition of information having no bearing on the issues raised.  
[Pushpasis] No no. You have not offended me in any ways. So we are good then. I was worried that I might have offended you instead. :)
>
>
>> [Pushpasis] Like mentioned already, and again in my opinion, this will help the controller deal with scenarios where it needs to distinguish between situations in which a link has been administratively put into ‘out-of-order’ from situations where the link has degraded to a ‘malfunctioning’ state and needs attention. Unfortunately I cannot come up with a use-cases how this distinction can be used (other than diverting service traffics away from the links). Perhaps some of the operators may throw more light.
>
>I’d like to hear from the operators (especially the authors Luay and Mohan).
[Pushpasis] Me too :)
> 
>
>> 
>> 
>> Hoping I have not failed to communicate once more. If you still feel so, please let me know. And I will refrain myself from answering on this thread further.
>
>I think we are communicating now - the main question is what does this link-maintenance condition needs to be flooded throughout the OSPF routing domain when it seems that link-local signaling would offer a much more straight-forward solution. The response so far has been, “For the controller use-case” without any explanation of why increasing the forward and reverse metrics isn’t enough (especially since you are doing this anyway for backward compatibility). Les Ginsberg raised the same point.
[Pushpasis] I will not further exaggerate my already-expressed reasoning as I do not have a definite use case in hand. Hoping some operators in the working group may have more solid use-cases for this.

Thanks and Regards,
-Pushpasis

>
>Thanks,
>Acee