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

Shraddha -

The draft currently states that when overload is signaled that the neighbors on both ends of the link are supposed to advertise max-metric.  So it is not clear to me why you are arguing that you should not change the metric. Do you have a revision of the draft which no longer mandates changing the metric?

Also, you need to more clear as regards what you are trying to achieve. Do you want the link to be completely unusable - or simply the link of last resort?
If the former then bringing the adjacency down will suffice.
If the latter then max-metric is what you want.

Similar to Acee, I am not clear on what advantage signaling overload network wide gives you.

   Les

> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha Hegde
> Sent: Tuesday, September 29, 2015 10:06 AM
> To: Pushpasis Sarkar; Acee Lindem (acee)
> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
> Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> 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) <acee@cisco.com>
> Cc: Shraddha Hegde <shraddha@juniper.net>; OSPF WG List
> <ospf@ietf.org>; Hannes Gredler <hannes@gredler.at>; Mohan Nanduri
> <mnanduri@microsoft.com>; Jalil, Luay <luay.jalil@verizon.com>
> Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> Hi Acee,
> 
> 
> 
> 
> On 9/29/15, 8:15 PM, "Acee Lindem (acee)" <acee@cisco.com> 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
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf