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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Shraddha -

> -----Original Message-----
> From: Shraddha Hegde [mailto:[e-mail]]
> Sent: Tuesday, September 29, 2015 8:05 PM
> To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Acee Lindem (acee)
> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
> Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> Les,
> 
> Pls see inline...
> 
> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> Sent: Wednesday, September 30, 2015 1:30 AM
> To: Shraddha Hegde <[e-mail]>; Pushpasis Sarkar
> <[e-mail]>; Acee Lindem (acee) <[e-mail]>
> Cc: Hannes Gredler <[e-mail]>; OSPF WG List <[e-mail]>;
> Mohan Nanduri <[e-mail]>; Jalil, Luay
> <[e-mail]>
> Subject: RE: 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.
> <Shraddha.> There is no change in the draft. Both end still advertise MAX-
> METRIC. This metric is usable metric it does not indicate link is out of service.
> 
> So it is not clear to me why you are arguing that you should not change the
> metric.
> <Shraddha> I am sorry if any of the discussions gave you impression that
> metric should not be changed. Metric is increased to MAX-METRIC. This
> metric is usable metric.
> 
> Do you have a revision of the draft which no longer mandates changing the
> metric?
> <Shraddha> Metric is very much changed. What I am trying to say is even if
> the metric is changed it's usable metric and hence does not mandate that the
> LSP
>                       Moves away from the link.
> 
> 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?
> <Shraddha> It's a link of last resort. We cannot make the link completely
> unusable until the traffic is moved on different path.
>  I thought it was clear in the draft. Will add more text to clarify this.
> 
> If the former then bringing the adjacency down will suffice.
> <Shraddha>Bringing adjacency down is not an option. We don't need this
> draft  if adjacency can be brought down before moving services away from
> the link.
> 
> If the latter then max-metric is what you want.
> <Shraddha>As I indicated before, max-metric can work in most common
> scenarios but not all. There could be cases where an alternate path cannot be
> found Satisfying the constraints so LSP remains on the link undergoing
> maintenance since the link is still a last resort link.

[Les:] Which seems to me to be exactly the definition of link of last resort i.e. in the absence of any other alternative use the link undergoing maintenance.
??

   Les


 Having additional
> information that the link is overloaded helps the controller in taking special
> actions like relaxing LSP constraints temporarily , setting up a new LSP and
> moving traffic away from the link. Once all the services have moved away
> from link it can go for replacement.
> 
> 
> Similar to Acee, I am not clear on what advantage signaling overload network
> wide gives you.
> <Shraddha> In my personal opinion, there are use cases requiring the link-
> overload information to be available to the LSP ingress or controller.
> 
>                        If the WG decides, these are not valid use-cases and we do not
> need area wide flooding of the information, I am willing to change the draft
>                         to carry the link overload TLV in hellos (LLS) or link local LSAs.
> 
>                        I would like to hear more opinions from the WG participants.
> 
>    Les
> 
> > -----Original Message-----
> > From: OSPF [mailto:[e-mail]] 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) <[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
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf