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

["Acee Lindem (acee)" <[e-mail]>]

Hi Shraddha, 

On 9/29/15, 1:07 AM, "Shraddha Hegde" <[e-mail]> wrote:

>Acee,
>
>Pls see inline...
>
>Rgds
>Shraddha
>
>-----Original Message-----
>From: Acee Lindem (acee) [mailto:[e-mail]]
>Sent: Monday, September 28, 2015 7:02 PM
>To: Shraddha Hegde <[e-mail]>; OSPF WG List <[e-mail]>
>Cc: Pushpasis Sarkar <[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 Shraddha, 
>
>On 9/28/15, 1:13 AM, "Shraddha Hegde" <[e-mail]> wrote:
>
>>Acee,
>>
>>Thanks for picking up the draft for adoption.
>>
>>I believe this draft is very useful in automating the link upgrade
>>process and software upgrade process in overlay deployments and hence
>>support WG adoption as co-author.
>>
>>I would like to  take this opportunity to discuss  few of the points
>>raised during Prague meeting.
>>
>>1. Whether to keep the "Link overload" advertisement at area level or
>>at link level.
>>
>>In controller based deployments, it's useful to advertise the impending
>>maintenance of the link to the controller so that controller can take
>>Special actions based on the information. The use case is described in
>>sec 5.2 in  the draft.
>>The draft advocates increasing the metric to usable high metric on both
>>ends of the link. This is for backwards compatibility and to avoid need
>>of flag Day upgrade on all nodes.
>
>I’m not sure why anyone would even consider using a mechanism other than
>the metric to divert IP routed traffic. I don’t think we need to discuss
>this any further as it only dilutes the discussion of the real questions.
><Shraddha> Agree that it's sufficient to use the metric alone for ip
>routed traffic. The area level information flooding is needed for TE and
>controller based applications.
>                      The LSPs are not brought down  if there is usable
>metric on the link. We want to keep the metric (or TE metric) usable
>until traffic is diverted which is the whole     purpose of the draft.
>                      "Link overload" information is used as a
>characteristic of the link ("like color")  and flood across area. Ingress
>node (or controller) uses this information to re-compute
>                       And move the LSP to a different path.
>
>>
>> Controller cannot assign special meaning to the metric  for ex: Metric
>>XXXX means the link going for maintenance and take different actions
>>based on metric.
>
>Why does the controller care whether the link is out of service due to
>maintenance or some other reason? In any case, the link is unavailable
>and TE traffic should be diverted.
><Shraddha> The metric set on the link is still a usable metric (0xffff)
>for OSPF and (0xfffffffe) for TE metric.  The metric needs to be usable
>metric otherwise the whole process becomes disruptive.

You still didn’t answer my question. Why would the action for TE LSPs not
always be to divert the traffic when the TE metric on one of the component
links is 0xfffffffe. You still have not convinced me that the additional
link attribute provides any value add beyond setting the metric to 0xffff
and TE Metric to 0xfffffffe.


Thanks,
Acee





>
>> 
>>
>>For a completely automated upgrade process, controller would need a
>>fine grained and specific information that the link is going for
>>maintenance so that the services that use the particular link find a
>>different path forcefully while keeping the entire process
>>non-disruptive.
>
>In a completely automated upgrade process, the controller would be
>orchestrating the link maintenance and wouldn’t require the router to
>tell them about it.
><Shraddha> My perspective is that the controller (via some mgmt.
>interface) configures the link to be replaced with  "overload config" and
>recomutation of LSPs
>                     (either at ingress or at controller) is triggered
>                      Via IGP/BGP-LS updates.
>                  
>                     Would like to hear more from others (especially
>operators) on this.
>
>>
>>
>>2. Use of high metric  on either side of the link  to divert the traffic.
>>
>>As I already mentioned before, draft advocates raising the reverse
>>metric to a high metric  but that is for backwards compatibility and to
>>avoid Need for flag-day upgrade. There were suggestions at the Prague
>>meeting to use lower bandwidth advertisements as well as removal of
>>Link characteristics to force the services on different path. These
>>mechanisms would be disruptive and defeats the purpose of the draft.
>
>There is no disagreement about using metric to divert traffic or why the
>reverse metric must be increased as well - no more discussion is
>necessary. 
><Shraddha>Ok good.
>
>
>>
>>3.  Backward compatibility
>>
>>"Link-overload"  is a new information attached to a link and is very
>>similar to a new constraint being added to the link.
>>This information is non-invasive in the sense that services that do not
>>want to look at the new constraint (link overload) May depend only on
>>the metric to take specific actions.
>>
>>Whereas services that have specialized requirement of providing
>>non-disruptive upgrades can do so by processing the new constraint.
>>
>>Section 4 in the draft talks about backwards compatibility.
>>I'll add more clarifications in the coming days.
>
>I think one point that would be good to explain is why OSPF stub router
>alone isn’t enough to support link maintenance.
><Shraddha> sure will add that.
>
>Thanks,
>Acee
>
>
>
>>
>>Rgds
>>Shraddha
>>
>>
>>-----Original Message-----
>>From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem
>>(acee)
>>Sent: Saturday, September 26, 2015 6:05 AM
>>To: OSPF WG List <[e-mail]>
>>Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
>>
>>In Prague, there was consensus in the room that this use case was not
>>covered by existing mechanisms and that it was a problem the WG should
>>solve. There were differing opinions as to the exact solution but that
>>should not preclude OSPF WG adoption.
>>
>>Please indicate your support (or concerns) for adopting this as a WG
>>Document.
>>
>>
>>Thanks,
>>Acee
>>
>>
>>_______________________________________________
>>OSPF mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ospf
>