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

Hi,

I am probably joining the party quite late, so apologies in advance if the
following has already been discussed and discarded.

Why cant the following be done:

Set the metric of all transit links/connections on an “overloaded” router
to 0xffff in its Router LSAs. This will result this router to not be
included as a transit node in its neighbors SPF tree.  Stub links can still
be advertised with their normal metrics so that they are reachable even
when a router is “overloaded”.

This way you can mimic IS-IS OL bit.

Cheers, Manav

On Mon, Sep 28, 2015 at 10:43 AM, Shraddha Hegde <shraddha@juniper.net>
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.
>
>  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:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
> Sent: Saturday, September 26, 2015 6:05 AM
> To: OSPF WG List <ospf@ietf.org>
> 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
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>