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

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

Hi Shraddha, 
This was two and there were, at least, two responses. Please refer to the
archive: https://mailarchive.ietf.org/arch/search/?email_list=ospf

Thanks,
Acee

On 9/28/15, 10:56 PM, "OSPF on behalf of Shraddha Hegde"
<[e-mail] on behalf of [e-mail]> wrote:

>Resending to mailing list as I didn't see it delivered in last posting...
>
>Rgds
>Shraddha
>
>-----Original Message-----
>From: Shraddha Hegde
>Sent: Monday, September 28, 2015 10:43 AM
>To: 'Acee Lindem (acee)' <[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
>
>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.
>
> 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. 
>
>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.
>
>
>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.
>
>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.
>
>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
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf