Subject: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 20 Apr 2017 16:19:44 +0300

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 24 Apr 2017 09:55:33 +0000

Hi Alexander,

The objective of this draft is to re-route the traffic from the link that is expected to undergo maintenance
And the case of broadcast links  is explained in sec 5.2 which achieves the objective.

The case you described may be relevant for unplanned link-down events which is outside the scope of this draft.

Thanks
Shraddha

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 6:50 PM
To: [email-masked]; [email-masked]
Subject: draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

Thank you.

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 24 Apr 2017 13:03:17 +0300

Hi Shraddha,

For planned link maintenance there still could be traffic disruption. 
Even if router with overloaded link is detached from broadcast link, the 
latter still could be used by other routers on this one. If router with 
overloaded link was DR, traffic between other routers on broadcast link 
could be disrupted. Am I correct?

24.04.2017 12:55, Shraddha Hegde пишет:
> The case you described may be relevant for unplanned link-down events 
> which is outside the scope of this draft.
>
> Thanks
>
> Shraddha
>
> *From:*Alexander Okonnikov [mailto:[email-masked]]
> *Sent:* Thursday, April 20, 2017 6:50 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* draft-ietf-ospf-link-overload-06 - DR migration
>
> Hi authors,
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 25 Apr 2017 04:00:53 +0000

Yes. You are right.

This is a problem specific to BDR taking over the role of DR.
The problem you describe has been around for a while and I have seen people using
decent workarounds without requiring protocol changes to solve this problem.

Rgds
Shraddha

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Monday, April 24, 2017 3:33 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: draft-ietf-ospf-link-overload-06 - DR migration

Hi Shraddha,

For planned link maintenance there still could be traffic disruption. Even if router with overloaded link is detached from broadcast link, the latter still could be used by other routers on this one. If router with overloaded link was DR, traffic between other routers on broadcast link could be disrupted. Am I correct?

Thanks
Shraddha

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 6:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

Thank you.

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 25 Apr 2017 15:08:38 +0300

Hi Shraddha,

I thought that one of goals of the draft is to minimize manual 
intervention as a preparation for maintenance. My assumption is that 
workarounds do require some manual intervention. Are mentioned 
workarounds specific for particular implementation where BDR always 
generates Network LSA in addition to DR's Network LSA? Or is essence of 
workarounds in (manual) tuning of SPF delay timer?

Thank you.

25.04.2017 07:00, Shraddha Hegde пишет:
> *Sent:* Monday, April 24, 2017 3:33 PM
> *To:* Shraddha Hegde <[email-masked]>; 
> [email-masked]; [email-masked]
> *Subject:* Re: draft-ietf-ospf-link-overload-06 - DR migration
>
> Hi Shraddha,
>
> Even if router with overloaded link is detached from broadcast link, 
> the latter still could be used by other routers on this one. If router 
> with overloaded link was DR, traffic between other routers on 
> broadcast link could be disrupted. Am I correct?
>
>     The objective of this draft is to re-route the traffic from the
>     link that is expected to undergo maintenance
>
>     The case you described may be relevant for unplanned link-down
>     events which is outside the scope of this draft.
>
>     Thanks
>
>     Shraddha
>
>     *To:* [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>